ARP rozgłasza sieć powodziową i wysokie użycie procesora

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.

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.

Program Menedżer konfiguracji obsługuje dwie technologie wznawiania w sieci lokalnej (LAN) w celu wybudzania komputerów w trybie uśpienia, gdy chcesz zainstalować wymagane oprogramowanie, takie jak aktualizacje oprogramowania i aplikacje: tradycyjne pakiety wznawiania i polecenia włączania AMT.

Począwszy od programu Menedżer konfiguracji SP1, można uzupełnić tradycyjną metodę pakietu budzika, korzystając z ustawień klienta proxy budzenia. Serwer proxy wznawiania używa protokołu peer-to-peer i wybranych komputerów, aby sprawdzić, czy inne komputery w podsieci nie są aktywne, i w razie potrzeby je obudzić. Gdy witryna jest skonfigurowana do Wake On LAN, a klienci są skonfigurowani do wznawiania proxy, proces działa w następujący sposób:

1. Komputery, na których jest zainstalowany klient programu Menedżer konfiguracji SP1 i które nie śpią w podsieci, sprawdzają, czy inne komputery w podsieci nie są aktywne. Robią to, wysyłając sobie nawzajem polecenie ping TCP / IP co 5 sekund.

2. Jeśli nie ma odpowiedzi od innych komputerów, zakłada się, że śpią. Obudzone komputery stają się komputerami zarządzającymi dla podsieci.

3. Ponieważ możliwe jest, że komputer może nie odpowiedzieć z innego powodu niż śpi (na przykład jest wyłączony, usunięty z sieci lub ustawienie klienta budzenia proxy nie jest już stosowane), komputery są wysłałem pakiet pobudki codziennie o godzinie 14 czasu lokalnego. Komputery, które nie odpowiedzą, nie będą już zakładane, że śpią i nie zostaną obudzone przez serwer proxy wznawiania.

Aby obsługiwać serwer proxy wznawiania, co najmniej trzy komputery muszą być aktywne w każdej podsieci. Aby to osiągnąć, trzy komputery są niedeterministycznie wybrane jako komputery stróżujące dla podsieci. Oznacza to, że pozostają w stanie czuwania, pomimo skonfigurowanej polityki zasilania do uśpienia lub hibernacji po okresie bezczynności. Komputery Guardian honorują polecenia zamknięcia lub ponownego uruchomienia, na przykład w wyniku zadań konserwacyjnych. Jeśli tak się stanie, pozostałe komputery stróżujące budzą inny komputer w podsieci, aby podsieć nadal posiadała trzy komputery stróżujące.

Komputery menedżerów proszą przełącznik sieciowy o przekierowanie ruchu sieciowego dla uśpionych komputerów do siebie.

Przekierowanie jest osiągane przez komputer menedżera rozgłaszający ramkę Ethernet, która używa adresu MAC komputera sypialnego jako adresu źródłowego. To powoduje, że przełącznik sieciowy zachowuje się tak, jakby komputer uśpiony przeniósł się do tego samego portu, na którym znajduje się komputer menedżera. Komputer zarządzający wysyła również pakiety ARP dla komputerów uśpionych, aby zachować świeży wpis w pamięci podręcznej ARP. Komputer zarządzający odpowiada również na żądania ARP w imieniu komputera sypialnego i odpowiada adresem MAC komputera sypialnego.

Podczas tego procesu mapowanie IP-MAC dla uśpionego komputera pozostaje takie samo. Serwer proxy wznawiania działa, informując przełącznik sieciowy, że inna karta sieciowa korzysta z portu zarejestrowanego przez inną kartę sieciową. Jednak takie zachowanie jest znane jako klapa MAC i jest niezwykłe w przypadku standardowego działania sieci. Niektóre narzędzia do monitorowania sieci szukają tego zachowania i mogą założyć, że coś jest nie tak. W związku z tym te narzędzia monitorowania mogą generować alerty lub zamykać porty podczas korzystania z serwera proxy wznawiania. Nie używaj budzącego proxy, jeśli narzędzia i usługi monitorowania sieci nie pozwalają na klapy MAC.

4. Gdy komputer zarządzający widzi nowe żądanie połączenia TCP dla komputera uśpionego, a żądanie dotyczy portu, na którym komputer sypialny nasłuchiwał przed przejściem w tryb uśpienia, komputer menedżera wysyła pakiet pobudzający do komputera sypialnego, a następnie przestaje przekierowywać ruch dla tego komputera.

5. Komputer śpiący odbiera pakiet budzenia i budzi się. Komputer wysyłający automatycznie ponawia połączenie i tym razem komputer nie śpi i może odpowiedzieć.

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.

Burza ARP / Broadcast

• Widzimy duże pakiety emisji z sieci VLAN 1, VLAN 1 używanych na urządzeniach stacjonarnych. Używamy 192.168.0.0/20 ...
• Wiresharks pokazuje, że setki komputerów zalewają sieć 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:

• Błędne konfiguracje adresu IP
• Atak warstwy 2, taki jak fałszowanie arp

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.

• Duża liczba klap MAC
• Drzewo opinające zostało zweryfikowane przez osoby wykwalifikowane Cisco TAC i CCNP / CCIE. Zamykamy wszystkie zbędne linki.

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 ...

switchport mode access
switchport access vlan 1
!! switchport nonegotiate disables some Vlan-hopping attacks via Vlan1 -> another Vlan
switchport nonnegotiate
!! If no IP Phones are connected to your switches, then you could lower this
!!   Beware of people with VMWare / hubs under their desk, because 
!!   "maximum 3" could shutdown their ports if they have more than 3 macs
switchport port-security maximum 3
switchport port-security violation shutdown
switchport port-security aging time 5
switchport port-security aging type inactivity
switchport port-security
spanning-tree portfast
!! Ensure you don't have hidden STP loops because someone secretly cross-connected a 
!!   couple of desktop ports
spanning-tree bpduguard enable

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) ...

mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900

Po zakończeniu opcjonalnie wykonaj a, clear mac address-tableaby przyspieszyć leczenie z potencjalnie pełnego stołu CAM.

• 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 ...

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 ...

• Umieszczenie dowolnego użytkownika w Vlan1 jest zwykle złym pomysłem (rozumiem, że mogłeś odziedziczyć bałagan)
• Niezależnie od tego, co mówi TAC, 192.168.0.0/20 jest zbyt duży, aby zarządzać w jednej domenie przełączanej bez ryzyka ataków warstwy 2. Im większa jest twoja maska ​​podsieci, tym większe narażenie na ataki warstwy 2, ponieważ ARP jest protokołem nieuwierzytelnionym, a router musi przynajmniej odczytać prawidłowy ARP z tej podsieci.
• Kontrola burz na portach warstwy 2 jest zwykle dobrym pomysłem; Włączenie kontroli burzy w takiej sytuacji spowoduje jednak dobry ruch przy złym ruchu. Po wygojeniu sieci zastosuj pewne zasady kontroli burzy na portach brzegowych i łączach w górę.

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ą).

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ą.

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?