Mając nadzieję, że ktoś tutaj może mieć jakiś wgląd w problem, przed którym stoimy. Obecnie mamy Cisco TAC przyglądający się sprawie, ale starają się znaleźć podstawową przyczynę.
Chociaż w tytule wspomniano o transmisji ARP i wysokim zużyciu procesora, nie jesteśmy pewni, czy są one powiązane lub niezwiązane na tym etapie.
Oryginalny numer został opublikowany w społeczności internetowej INE
Obniżyliśmy sieć do jednego łącza bez konfiguracji redundancji, myśl o tym jak o topologii gwiazdy.
Fakty:
- Używamy przełączników 3750x, 4 w jednym stosie. Wersja 15.0 (1) SE3. Cisco TAC nie potwierdza znanych problemów z wysokimi procesorami lub błędami ARP w tej konkretnej wersji.
- Brak podłączonych koncentratorów / niezarządzanych przełączników
- Ponownie załadowano stos rdzenia
- Nie mamy domyślnej trasy „Ip route 0.0.0.0 0.0.0.0 f1 / 0”. Używanie protokołu OSPF do routingu.
- Widzimy duże pakiety emisji z sieci VLAN 1, VLAN 1 używanych na urządzeniach stacjonarnych. Używamy 192.168.0.0/20
- Cisco TAC powiedział, że nie widzą nic złego w korzystaniu z / 20, poza tym mielibyśmy dużą domenę rozgłoszeniową, ale powinniśmy nadal działać.
- Wi-Fi, zarządzanie, drukarki itp. Działają w różnych sieciach VLAN
- Drzewo opinające zostało zweryfikowane przez osoby wykwalifikowane Cisco TAC i CCNP / CCIE. Zamykamy wszystkie zbędne linki.
- Konfiguracja na rdzeniu została zweryfikowana przez Cisco TAC.
- Mamy domyślny limit czasu ARP na większości przełączników.
- Nie wdrażamy pytań i odpowiedzi.
- Nie dodano żadnych nowych przełączników (przynajmniej nie wiemy o nich)
- Nie można użyć dynamicznej kontroli arp na przełącznikach krawędzi, ponieważ są to 2950
- Użyliśmy interfejsów show | inc line |, aby dowiedzieć się, skąd pochodzi duża liczba transmisji, jednak zarówno Cisco TAC, jak i 2 innych inżynierów (CCNP i CCIE) potwierdziło, że jest to normalne zachowanie ze względu na to, co dzieje się w sieci (jak w przypadku dużej liczby klap mac powodując większą transmisję). Sprawdziliśmy, czy STP działa poprawnie na przełącznikach krawędziowych.
Objawy w sieci i przełącznikach:
- Duża liczba klap MAC
- Wysokie użycie procesora dla procesu wprowadzania ARP
- Ogromna liczba pakietów ARP, szybko rosnąca i widoczna
- Wiresharks pokazuje, że setki komputerów zalewają sieć ARP Broadcast
- Do celów testowych umieściliśmy około 80 komputerów stacjonarnych w różnych sieciach Vlan, jednak przetestowaliśmy to i nie zauważyliśmy żadnej różnicy w stosunku do wysokich wartości procesora lub arp
- Uruchomiłeś różne AV / złośliwe oprogramowanie / oprogramowanie szpiegujące, ale w sieci nie widać wirusów.
- sh tablica adresów mac, pokazuje nam około 750 różnych adresów mac zgodnie z oczekiwaniami na vlan 1.
#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
12 111438973 18587995 5995 44.47% 43.88% 43.96% 0 ARP Input
174 59541847 5198737 11453 22.39% 23.47% 23.62% 0 Hulc LED Process
221 7253246 6147816 1179 4.95% 4.25% 4.10% 0 IP Input
86 5459437 1100349 4961 1.59% 1.47% 1.54% 0 RedEarth Tx Mana
85 3448684 1453278 2373 1.27% 1.04% 1.07% 0 RedEarth I2C dri
- Poprzednio wyświetlałem tablicę adresów mac na różnych przełącznikach i samym rdzeniu (na rdzeniu, na przykład podłączonym bezpośrednio przez pulpit, mój pulpit), i możemy zobaczyć kilka różnych adresów sprzętowych MAC zarejestrowanych w interfejsie, nawet jeśli interfejs ten ma tylko jeden komputer podłączony do tego:
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 001c.c06c.d620 DYNAMIC Gi1/1/3
1 001c.c06c.d694 DYNAMIC Gi1/1/3
1 001c.c06c.d6ac DYNAMIC Gi1/1/3
1 001c.c06c.d6e3 DYNAMIC Gi1/1/3
1 001c.c06c.d78c DYNAMIC Gi1/1/3
1 001c.c06c.d7fc DYNAMIC Gi1/1/3
- pokaż wykorzystanie kamery na platformie
CAM Utilization for ASIC# 0 Max Used
Masks/Values Masks/values
Unicast mac addresses: 6364/6364 1165/1165
IPv4 IGMP groups + multicast routes: 1120/1120 1/1
IPv4 unicast directly-connected routes: 6144/6144 524/524
IPv4 unicast indirectly-connected routes: 2048/2048 77/77
IPv4 policy based routing aces: 452/452 12/12
IPv4 qos aces: 512/512 21/21
IPv4 security aces: 964/964 45/45
Jesteśmy teraz na etapie, w którym będziemy potrzebować ogromnej ilości przestojów, aby odizolować każdy obszar na raz, chyba że ktokolwiek inny ma jakieś pomysły na zidentyfikowanie źródła lub przyczyny tego dziwnego i dziwnego problemu.
Aktualizacja
Dziękuję @MikePennington i @RickyBeam za szczegółową odpowiedź. Spróbuję odpowiedzieć na to, co mogę.
- Jak wspomniano, 192.168.0.0/20 to odziedziczony bałagan. Jednak zamierzamy to rozdzielić w przyszłości, ale niestety ten problem pojawił się, zanim mogliśmy to zrobić. Osobiście zgadzam się również z większością, w której domena emisji jest zdecydowanie za duża.
- Korzystanie z Arpwatch jest zdecydowanie czymś, co możemy wypróbować, ale podejrzewam, że ponieważ kilka portów dostępu rejestruje adres mac, mimo że nie należy do tego portu, wniosek z arpwatch może nie być przydatny.
- Całkowicie zgadzam się z tym, że nie jestem w 100% pewien, że znajdę wszystkie nadmiarowe łącza i nieznane przełączniki w sieci, ale jak najlepiej z naszego ustalenia, dzieje się tak, dopóki nie znajdziemy dalszych dowodów.
- Sprawdzono bezpieczeństwo portów, niestety zarząd postanowił nie używać tego z różnych powodów. Częstym powodem jest ciągłe przenoszenie komputerów (środowisko uczelni).
- Domyślnie korzystaliśmy z portu spanning-tree w połączeniu z bpduguard z drzewa opinającego na wszystkich portach dostępowych (komputery stacjonarne).
- W tej chwili nie korzystamy z portu przełączającego bez negocjacji na porcie dostępowym, ale nie otrzymujemy żadnego skoku Vlana podskakującego na wielu Vlanach.
- Sprawi, że powiadomienie o tablicy adresów MAC sprawdzi, czy uda nam się znaleźć jakieś wzorce.
„Ponieważ między portami przełączników pojawia się duża liczba adresów MAC, trudno jest ustalić, gdzie znajdują się przestępcy (załóżmy, że znajdziesz dwa lub trzy adresy MAC, które wysyłają dużo plików ARP, ale źródłowe adresy MAC wciąż migają między portami)”.
- Zaczęliśmy od tego, wybraliśmy dowolne klapy MAC i kontynuowaliśmy naszą drogę przez wszystkie główne przełączniki do dystrybucji do przełącznika dostępu, ale okazało się, że ponownie, interfejs portu dostępowego przechwytuje wiele adresów mac, stąd klapy mac; wracając do punktu wyjścia.
- Kontrola burz jest czymś, co rozważaliśmy, ale obawiamy się, że niektóre z legalnych pakietów zostaną odrzucone, powodując dalszy problem.
- Potroi sprawdzi konfigurację VMHost.
- @ytti niewytłumaczalne adresy MAC znajdują się za wieloma portami dostępu, a nie za pojedynczymi osobami. Nie znalazłem żadnych pętli na tych interfejsach. Adresy MAC istnieją również w innych interfejsach, co wyjaśniałoby dużą liczbę klap MAC
- @RickyBeam Zgadzam się z tym, dlaczego gospodarze wysyłają tyle żądań ARP; jest to jeden z zagadkowych problemów. Bezprzewodowy most Rouge jest interesujący, o czym nie myślałem, o ile nam wiadomo, bezprzewodowy jest w innej sieci VLAN; ale łobuz będzie oczywiście oznaczać, że może to być na VLAN1.
- @RickyBeam, tak naprawdę nie chcę odłączać wszystkiego, ponieważ spowoduje to ogromne przestoje. Jednak właśnie tam może zmierzać. Mamy serwery Linux, ale nie więcej niż 3.
- @RickyBeam, czy możesz wyjaśnić sondowanie serwera DHCP w użyciu?
My (Cisco TAC, CCIEs, CCNP) globalnie zgadzamy się, że nie jest to konfiguracja przełącznika, ale problem powoduje host / urządzenie.
switchport port-security aging time 5
iswitchport port-security aging type inactivity
oznacza, że możesz przenosić stacje między portami po 5 minutach bezczynności lub jeśli ręcznie wyczyścisz wpis zabezpieczenia portu. Jednak ta konfiguracja zapobiega klapom mac między portami dostępu przełącznika, ponieważ porty nie mogą arbitralnie pozyskiwać tego samego adresu mac z innego portu.Odpowiedzi:
Rozwiązany.
Problem dotyczy SCCM 2012 SP1, usługi o nazwie: Proxy Wake-Up ConfigMrg . „Funkcja” nie istnieje SCCM 2012 RTM.
W ciągu 4 godzin od wyłączenia tej zasady w ramach polityki zaobserwowaliśmy stały spadek zużycia procesora. Gdy upłynęły 4 godziny, zużycie ARP wyniosło zaledwie 1-2%!
Podsumowując, usługa ta fałszuje adresy MAC! Nie mogę uwierzyć, jak wiele spustoszenia to spowodowało.
Poniżej znajduje się pełny tekst z Microsoft Technet, ponieważ uważam, że ważne jest, aby zrozumieć, w jaki sposób odnosi się to do opublikowanego problemu.
Dla każdego, kto jest zainteresowany, poniżej znajdują się szczegóły techniczne.
Ref: http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients
Bardzo dziękuję wszystkim, którzy napisali tutaj i pomagali w procesie rozwiązywania problemów.
źródło
Burza ARP / Broadcast
Proces wprowadzania ARP jest wysoki, co oznacza, że przełącznik spędza dużo czasu na przetwarzaniu ARP. Jedną z bardzo częstych przyczyn zalewania ARP jest pętla między przełącznikami. Jeśli masz pętlę, możesz także uzyskać klapy mac wspomniane powyżej. Inne możliwe przyczyny powodzi ARP to:
Najpierw wyeliminuj możliwość nieprawidłowej konfiguracji lub ataku warstwy 2 wspomnianego powyżej. Najprostszym sposobem na to jest z arpwatch na maszynie Linux (nawet jeśli trzeba używać LiveCD na laptopie). Jeśli masz błędną konfigurację lub atak warstwy 2, arpwatch wyświetla takie wiadomości w syslog, które zawierają adresy mac, które walczą o ten sam adres IP ...
Oct 20 10:31:13 tsunami arpwatch: flip flop 192.0.2.53 00:de:ad:85:85:ca (00:de:ad:3:d8:8e)
Kiedy zobaczysz „flip-flops”, musisz wyśledzić źródło adresów mac i dowiedzieć się, dlaczego walczą o to samo IP.
Mówiąc jak ktoś, kto przeszedł przez to więcej razy, niż chciałbym sobie przypomnieć, nie zakładaj, że znalazłeś wszystkie zbędne linki ... po prostu spraw, aby twoje przełączniki zachowywały się przez cały czas.
Ponieważ otrzymujesz dużą liczbę klap Mac między portami przełączników, trudno jest znaleźć, gdzie znajdują się przestępcy (załóżmy, że znajdziesz dwa lub trzy adresy Mac, które wysyłają dużo arps, ale źródłowe adresy mac ciągle flapują między portami). Jeśli nie wymuszasz twardego limitu adresów MAC na port krawędziowy, bardzo trudno jest wyśledzić te problemy bez ręcznego odłączania kabli (czego należy unikać). Pętle przełączników powodują nieoczekiwaną ścieżkę w sieci i możesz skończyć z setkami komputerów Mac uczonych z przerwami z tego, co zwykle powinno być pulpitowym przełącznikiem.
Najłatwiejszym sposobem spowolnienia ruchów mac jest użycie
port-security
. Na każdym porcie przełączania dostępu w Vlan 1, który jest podłączony do jednego komputera (bez przełącznika downstream), skonfiguruj następujące polecenia na poziomie interfejsu w przełącznikach cisco ...W większości przypadków zalewania komputerów Mac / ARP zastosowanie tej konfiguracji do wszystkich portów przełącznika krawędzi (szczególnie tych z portfastem) spowoduje powrót do normalnego stanu, ponieważ konfiguracja zamknie każdy port, który przekracza trzy adresy MAC, i potajemnie wyłączy zapętlony portfast. Trzy macs na port to liczba, która działa dobrze w moim środowisku pulpitu, ale możesz podnieść go do 10 i prawdopodobnie będzie dobrze. Po wykonaniu tej czynności wszystkie pętle warstwy 2 są zrywane, szybkie klapy mac przestają działać, co znacznie ułatwia diagnozę.
Kolejne kilka globalnych poleceń, które są przydatne do śledzenia portów związanych z burzą rozgłoszeniową (mac-move) i zalaniem (próg) ...
Po zakończeniu opcjonalnie wykonaj a,
clear mac address-table
aby przyspieszyć leczenie z potencjalnie pełnego stołu CAM.Cała odpowiedź zakłada, że twój 3750 nie ma błędu powodującego problem (ale powiedziałeś, że wireshark wskazał zalane komputery). To, co nam pokazujesz, jest oczywiście błędne, gdy do Gi1 / 1/3 jest podłączony tylko jeden komputer, chyba że na tym komputerze jest coś podobnego do VMWare.
Różne myśli
Opierając się na czacie, który przeprowadziliśmy, prawdopodobnie nie muszę wspominać o rzeczach oczywistych, ale zrobię to dla przyszłych gości ...
źródło
Prawdziwe pytanie brzmi: dlaczego hosty wysyłają tak wiele ARP w pierwszej kolejności. Dopóki nie zostanie udzielona odpowiedź, przełączniki będą nadal miały trudności z radzeniem sobie z burzą arp. Niezgodność maski sieci? Niski czas arp hosta? Jeden (lub więcej) hostów posiadających trasę „interfejsu”? Gdzieś bezprzewodowy most rouge? „darmowy arp” oszalał? Sondowanie „w użyciu” serwera DHCP? Nie brzmi to jak problem z przełącznikami lub warstwą 2; gospodarze robią złe rzeczy.
Moim procesem debugowania byłoby odłączenie wszystkiego i uważne obserwowanie, jak rzeczy są ponownie podłączane, jeden port na raz. (Wiem, że jest to wiele mil od ideału, ale w pewnym momencie musisz zmniejszyć straty i spróbować fizycznie odizolować wszelkie możliwe źródła). Następnie pracuję nad zrozumieniem, dlaczego wybrane porty generują wiele arp.
(Czy wiele z tych hostów to systemy Linux? Linux miał bardzo głupi system zarządzania pamięcią podręczną ARP. Fakt, że „ponownie zweryfikuje” wpis w kilka minut, jest zepsuty w mojej książce Jest to mniejszy problem w małych sieciach, ale A / 20 nie jest małą siecią).
źródło
To może, ale nie musi być związane z twoim problemem, ale pomyślałem, że może to być coś, co warto tam rzucić:
Obecnie mamy kilka zestawionych 3750x w niektórych naszych zdalnych witrynach, w większości z 15.0.2 (SE0 do 4, jest kilka błędów FRU z SE0, z których powoli migruję).
Podczas rutynowej aktualizacji IOS, od wersji 15.0.2 do 15.2-1 (najnowsza SE) zauważyliśmy dość znaczny wzrost procesora, średnio od około 30% do 60% i więcej w godzinach poza szczytem. Przejrzałem konfiguracje i dzienniki zmian IOS i współpracowałem z TAC firmy Cisco. Według TAC wydaje się, że są w punkcie, w którym uważają, że to jakiś błąd w IOS 15.2-1.
Gdy kontynuowaliśmy badanie wzrostu CPU, zaczęliśmy obserwować ogromne ilości ruchu ARP do tego stopnia, że nasze tabele ARP zapełniły się całkowicie i spowodowały niestabilność sieci. Tymczasowym krokiem było ręczne cofnięcie limitów czasu ARP od domyślnego (14400) do 300 w naszych sieciach głosowych i danych.
Po zmniejszeniu limitów czasu ARP byliśmy stabilni przez około kilka tygodni, po czym wróciliśmy do IOS 15.0.2-SE4 i usunęliśmy nasze domyślne limity czasu ARP. Nasze wykorzystanie procesora spadło do ~ 30%, a problemy z tablicą ARP nie występują.
źródło
arp timeout 240
na wszystkich interfejsach SVI / L3, które są skierowane do przełącznika.Prosty, ale może przeoczony; czy twoi klienci mają prawidłową bramę domyślną, czy nie robisz dużo arp proxy? Możesz rozważyć zanegowanie funkcji ip proxy arp na 3750?
źródło