Rete di inondazioni di trasmissione ARP e utilizzo elevato della CPU

Sperando che qualcuno qui possa avere un'idea del problema che stiamo affrontando. Attualmente abbiamo Cisco TAC che sta esaminando il caso, ma stanno lottando per trovare la causa principale.

Sebbene il titolo menzioni la trasmissione ARP e l'utilizzo elevato della CPU, non siamo sicuri se siano correlati o non correlati in questa fase.

Il numero originale è stato pubblicato nella community online di INE

Abbiamo ridotto la rete a un unico collegamento senza installazione di ridondanza, considerandola una topologia a stella.

I fatti:

• Utilizziamo switch 3750x, 4 in uno stack. Versione 15.0 (1) SE3. Cisco TAC non conferma alcun problema noto per bug cpu o ARP elevati per questa particolare versione.
• Nessun hub / switch non gestito collegato
• Stack Core ricaricato
• Non abbiamo una route predefinita "Ip route 0.0.0.0 0.0.0.0 f1 / 0". Utilizzo di OSPF per il routing.
• Vediamo grandi pacchetti di trasmissione da VLAN 1, VLAN 1 utilizzata per dispositivi desktop. Usiamo 192.168.0.0/20
• Cisco TAC ha affermato di non vedere nulla di sbagliato nell'utilizzo di / 20, a parte il fatto che avremmo un dominio di trasmissione di grandi dimensioni, ma dovrebbe comunque funzionare.
• Wifi, gestione, stampanti ecc. Sono tutti su VLAN diverse
• Lo spanning tree è stato verificato da persone qualificate Cisco TAC e CCNP / CCIE. Chiudiamo tutti i collegamenti ridondanti.
• La configurazione sul core è stata verificata Cisco TAC.
• Abbiamo il timeout ARP predefinito sulla maggior parte degli switch.
• Non implementiamo domande e risposte.
• Non sono stati aggiunti nuovi switch (almeno nessuno di cui siamo a conoscenza)
• Impossibile utilizzare l'ispezione arp dinamica sugli interruttori di bordo perché sono 2950
• Abbiamo usato le interfacce show | inc line | broadcast per capire da dove proviene il gran numero di broadcast, tuttavia sia Cisco TAC che altri 2 ingegneri (CCNP e CCIE) hanno confermato che si tratta di un comportamento normale dovuto a ciò che sta accadendo sulla rete (come in un gran numero di Mac Flap causando la trasmissione più grande). Abbiamo verificato che l'STP funzionava correttamente sugli interruttori di bordo.

Sintomi sulla rete e switch:

• Gran numero di alette MAC
• Elevato utilizzo della CPU per il processo di input ARP
• Enorme numero di pacchetti ARP, in rapido aumento e visibile
• Wiresharks mostra che centinaia di computer stanno inondando la rete con ARP Broadcast
• A scopo di test, abbiamo messo circa 80 macchine desktop diverse vlan, tuttavia abbiamo testato questo e non abbiamo fatto alcuna differenza visibile in cpu alto o input arp
• Hanno eseguito diversi AV / malware / spyware, ma nessun virus visibile sulla rete.
• sh mac count della tabella degli indirizzi, ci mostra circa 750 diversi indirizzi mac come previsto su 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

• Abbiamo potuto mostrare la tabella degli indirizzi mac su diversi switch e il core stesso (sul core, ad esempio, collegato direttamente dal desktop, il mio desktop) e possiamo vedere i diversi indirizzi hardware MAC registrati sull'interfaccia, anche se l'interfaccia ha un solo computer collegato a questo:

 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

• mostra l'utilizzo della piattaforma tcam

 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

Siamo ora in una fase in cui richiederemo enormi quantità di tempo di inattività per isolare ogni area alla volta, a meno che qualcun altro abbia qualche idea per identificare la causa o la causa principale di questo strano e bizzarro problema.

Aggiornare

Grazie @MikePennington e @RickyBeam per la risposta dettagliata. Proverò a rispondere a ciò che posso.

• Come accennato, 192.168.0.0/20 è un casino ereditato. Tuttavia, intendiamo dividerlo in futuro, ma sfortunatamente questo problema si è verificato prima che potessimo farlo. Personalmente concordo anche con la maggioranza, per cui il dominio di trasmissione è troppo grande.
• L'uso di Arpwatch è sicuramente qualcosa che possiamo provare, ma sospetto che diverse porte di accesso stiano registrando l'indirizzo mac anche se non appartiene a questa porta, la conclusione di arpwatch potrebbe non essere utile.
• Sono completamente d'accordo sul fatto di non essere sicuro al 100% di trovare tutti i collegamenti ridondanti e gli switch sconosciuti sulla rete, ma come meglio della nostra scoperta, questo è il caso fino a quando non troviamo ulteriori prove.
• È stata esaminata la sicurezza dei porti, purtroppo la direzione ha deciso di non utilizzarlo per vari motivi. La ragione comune è che spostiamo costantemente i computer (ambiente universitario).
• Abbiamo utilizzato spf-tree portfast insieme a spanning-tree bpduguard per impostazione predefinita su tutte le porte di accesso (macchine desktop).
• Al momento non utilizziamo switchport non negoziato sulla porta di accesso, ma non stiamo ottenendo alcun attacco di salto di Vlan che rimbalza su Vlan multitple.
• Darà una notifica alla tabella degli indirizzi mac e vedrà se riusciamo a trovare degli schemi.

"Dato che stai ottenendo un gran numero di flap MAC tra gli switchport, è difficile trovare dove si trovano i trasgressori (supponi di trovare due o tre indirizzi mac che inviano molti arp, ma gli indirizzi mac di origine continuano a sbattere tra le porte)."

• Abbiamo iniziato su questo, abbiamo scelto uno qualsiasi dei flap MAC e abbiamo proseguito attraverso lo switch principale fino alla distribuzione allo switch di accesso, ma quello che abbiamo scoperto è stato ancora una volta, l'interfaccia della porta di accesso registrava più indirizzi mac, quindi mac flaps; quindi torniamo al punto di partenza.
• Il controllo della tempesta è qualcosa che abbiamo preso in considerazione, ma temiamo che alcuni pacchetti legittimi vengano eliminati causando ulteriori problemi.
• Controllerà tre volte la configurazione di VMHost.
• @ytti gli indirizzi MAC inspiegabili sono dietro molte porte di accesso piuttosto che un individuo. Non sono stati trovati loop su queste interfacce. Gli indirizzi MAC esistono anche su altre interfacce, il che spiegherebbe un gran numero di flap MAC
• @RickyBeam sono d'accordo sul perché gli host inviano così tante richieste ARP; questo è uno dei problemi enigmatici. Il bridge wireless Rouge è interessante a cui non ho pensato, per quanto ne sappiamo, il wireless è su VLAN diverse; ma canaglia significherà ovviamente che potrebbe essere su VLAN1.
• @RickyBeam, non desidero davvero scollegare tutto perché questo causerà enormi quantità di downtime. Tuttavia, è qui che potrebbe essere diretto. Abbiamo server Linux ma non più di 3.
• @RickyBeam, puoi spiegare il sondaggio "in uso" del server DHCP?

In tutto il mondo (Cisco TAC, CCIE, CCNP) siamo d'accordo sul fatto che questa non è una configurazione dello switch, ma un host / dispositivo sta causando il problema.

Risolto.

Il problema è con SCCM 2012 SP1, un servizio chiamato: ConfigMrg Wake-Up Proxy . La "funzione" non esiste SCCM 2012 RTM.

Entro 4 ore dalla disattivazione all'interno della politica, abbiamo riscontrato un costante calo nell'utilizzo della CPU. Al termine di 4 ore, l'utilizzo di ARP era solo dell'1-2%!

In sintesi, questo servizio esegue lo spoofing dell'indirizzo MAC! Non riesco a credere a quanto caos abbia causato.

Di seguito è riportato un testo completo di Microsoft Technet poiché ritengo sia importante capire come ciò si collega al problema pubblicato.

Per chiunque sia interessato, di seguito sono riportati i dettagli tecnici.

Configuration Manager supporta due tecnologie Wake on Local Area Network (LAN) per riattivare i computer in modalità sospensione quando si desidera installare il software richiesto, come gli aggiornamenti software e le applicazioni: pacchetti di riattivazione tradizionali e comandi di accensione AMT.

A partire da Configuration Manager SP1, è possibile integrare il tradizionale metodo del pacchetto di riattivazione utilizzando le impostazioni del client proxy di riattivazione. Il proxy di riattivazione utilizza un protocollo peer-to-peer e computer scelti per verificare se gli altri computer della sottorete sono attivi e per riattivarli, se necessario. Quando il sito è configurato per Wake On LAN e i client sono configurati per il proxy di riattivazione, il processo funziona come segue:

1. I computer su cui è installato il client Configuration Manager SP1 e che non sono in modalità di sospensione nella sottorete verificano se altri computer nella sottorete sono attivi. Lo fanno inviandosi reciprocamente un comando ping TCP / IP ogni 5 secondi.

2. Se non ci sono risposte da altri computer, si presume che siano addormentati. I computer attivi diventano computer manager per la sottorete.

3. Poiché è possibile che un computer non risponda a causa di un motivo diverso da quello inattivo (ad esempio, è spento, rimosso dalla rete o l'impostazione del client di riattivazione proxy non è più applicata), i computer sono inviato un pacchetto di sveglia ogni giorno alle 14:00 ora locale. I computer che non rispondono non saranno più considerati addormentati e non verranno svegliati dal proxy di riattivazione.

Per supportare il proxy di riattivazione, almeno tre computer devono essere attivi per ogni sottorete. A tale scopo, tre computer sono scelti in modo non deterministico come computer di protezione per la sottorete. Ciò significa che rimangono svegli, nonostante qualsiasi politica di alimentazione configurata per dormire o ibernare dopo un periodo di inattività. I computer Guardian rispettano i comandi di arresto o riavvio, ad esempio, a seguito di attività di manutenzione. In questo caso, i restanti computer del guardiano riattivano un altro computer nella sottorete in modo che la sottorete continui ad avere tre computer del guardiano.

I computer manager chiedono allo switch di rete di reindirizzare il traffico di rete per i computer dormienti su se stessi.

Il reindirizzamento viene ottenuto dal computer manager che trasmette un frame Ethernet che utilizza l'indirizzo MAC del computer dormiente come indirizzo di origine. Questo fa sì che lo switch di rete si comporti come se il computer dormiente si fosse spostato sulla stessa porta su cui si trova il computer manager. Il computer manager invia inoltre pacchetti ARP per i computer in sospensione per mantenere la voce aggiornata nella cache ARP. Il computer manager risponderà anche alle richieste ARP per conto del computer dormiente e risponderà con l'indirizzo MAC del computer dormiente.

Durante questo processo, la mappatura da IP a MAC per il computer inattivo rimane invariata. Il proxy di riattivazione funziona informando lo switch di rete che una diversa scheda di rete sta utilizzando la porta registrata da un'altra scheda di rete. Tuttavia, questo comportamento è noto come flap MAC ed è insolito per le operazioni di rete standard. Alcuni strumenti di monitoraggio della rete cercano questo comportamento e possono presumere che qualcosa non vada. Di conseguenza, questi strumenti di monitoraggio possono generare avvisi o chiudere le porte quando si utilizza il proxy di riattivazione. Non utilizzare il proxy di riattivazione se gli strumenti e i servizi di monitoraggio della rete non consentono i flap MAC.

4. Quando un computer manager vede una nuova richiesta di connessione TCP per un computer inattivo e la richiesta è a una porta su cui era in ascolto il computer inattivo prima che si spegnesse, il computer manager invia un pacchetto di riattivazione al computer inattivo, quindi interrompe il reindirizzamento del traffico per questo computer.

5. Il computer dormiente riceve il pacchetto di sveglia e si sveglia. Il computer di invio ritenta automaticamente la connessione e questa volta il computer è attivo e può rispondere.

Rif: http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

Grazie per tutti coloro che hanno pubblicato qui e contribuito alla risoluzione dei problemi, molto apprezzati.

ARP / Broadcast storm

• Vediamo grandi pacchetti di trasmissione da VLAN 1, VLAN 1 utilizzata per dispositivi desktop. Usiamo 192.168.0.0/20 ...
• Wiresharks mostra che centinaia di computer stanno inondando la rete con ARP Broadcast ...

Il processo di input ARP è elevato, il che significa che lo switch sta impiegando molto tempo a elaborare gli ARP. Una causa molto comune di inondazioni ARP è un loop tra i tuoi switch. Se hai un loop, puoi anche ottenere i flap per Mac che hai menzionato sopra. Altre possibili cause di inondazioni ARP sono:

• Configurazioni errate dell'indirizzo IP
• Un attacco layer2, come lo spoofing arp

Elimina innanzitutto la possibilità di configurazioni errate o di un attacco layer2 sopra menzionato. Il modo più semplice per farlo è con arpwatch su una macchina linux (anche se devi usare un livecd su un laptop). Se hai una configurazione errata o un attacco layer2, arpwatch ti dà messaggi come questo in syslog, che elenca gli indirizzi mac che combattono sullo stesso indirizzo 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)

Quando vedi "infradito", devi rintracciare la fonte degli indirizzi mac e capire perché stanno combattendo sullo stesso IP.

• Gran numero di alette MAC
• Lo spanning tree è stato verificato da persone qualificate Cisco TAC e CCNP / CCIE. Chiudiamo tutti i collegamenti ridondanti.

Parlando come qualcuno che ha vissuto più volte di quanto vorrei ricordare, non dare per scontato che tu abbia trovato tutti i collegamenti ridondanti ... fai solo in modo che i tuoi switchport si comportino sempre.

Dal momento che stai ottenendo un gran numero di Mac Flap tra switchport, è difficile trovare dove si trovano i trasgressori (supponi di trovare due o tre indirizzi Mac che inviano molti arp, ma gli indirizzi Mac di origine continuano a sbattere tra le porte). Se non stai imponendo un limite rigido per gli indirizzi mac per porta edge, è molto difficile rintracciare questi problemi senza scollegare manualmente i cavi (che è ciò che vuoi evitare). I loop di switch causano un percorso inaspettato nella rete e potresti finire con centinaia di mac appresi in modo intermittente da quello che dovrebbe essere normalmente uno switchport desktop.

Il modo più semplice per rallentare i mac-mosse è con port-security. Su ogni switchport di accesso in Vlan 1 collegato a un singolo PC (senza switch downstream), configura i seguenti comandi a livello di interfaccia sui tuoi switch 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

Nella maggior parte dei casi di inondazioni mac / ARP, l'applicazione di questa configurazione a tutte le porte dello switch Edge (specialmente a quelle con portfast) ti riporterà in uno stato sano, perché la configurazione spegnerà qualsiasi porta che superi tre indirizzi mac e disabiliterà un segreto porta portfast in loop. Tre mac per porta è un numero che funziona bene nel mio ambiente desktop, ma potresti portarlo a 10 e probabilmente andrà bene. Dopo aver eseguito questa operazione, tutti i loop di livello 2 vengono interrotti, i mac flap rapidi cesseranno e ciò renderà la diagnosi molto più semplice.

Un'altra coppia di comandi globali che sono utili per rintracciare le porte associate a una tempesta di trasmissione (mac-move) e allagamenti (soglia) ...

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

Dopo aver terminato, opzionalmente eseguire una clear mac address-tableaccelerazione della guarigione da una tabella CAM potenzialmente completa.

• Abbiamo potuto mostrare la tabella degli indirizzi mac su diversi switch e core stesso (sul core, ad esempio, collegato direttamente dal desktop, il mio desktop) e possiamo vedere i diversi indirizzi hardware MAC registrati sull'interfaccia, anche se l'interfaccia ha solo un computer collegato a questo ...

L'intera risposta presuppone che il tuo 3750 non abbia un bug che causa il problema (ma hai detto che WireShark ha indicato i PC che stanno allagando). Ciò che ci stai mostrando è ovviamente sbagliato quando c'è solo un computer collegato a Gi1 / 1/3, a meno che quel PC non abbia qualcosa come VMWare su di esso.

Pensieri vari

Sulla base di una conversazione di chat che abbiamo avuto, probabilmente non devo menzionare l'ovvio, ma lo farò per il bene dei futuri visitatori ...

• Mettere qualsiasi utente in Vlan1 è normalmente una cattiva idea (capisco che potresti aver ereditato un casino)
• Indipendentemente da ciò che TAC ti dice, 192.168.0.0/20 è troppo grande per essere gestito in un singolo dominio commutato senza rischi di attacchi layer2. Più grande è la tua subnet mask, maggiore è la tua esposizione agli attacchi layer2 come questo perché ARP è un protocollo non autenticato e un router deve almeno leggere un ARP valido da quella subnet.
• Anche il controllo della tempesta sulle porte layer2 è di solito una buona idea; tuttavia, abilitando il controllo della tempesta in una situazione come questa, eliminerà il traffico buono con il traffico cattivo. Dopo che la rete è stata sanata, applica alcune politiche di controllo delle tempeste sulle tue porte e uplink.

La vera domanda è perché gli host inviano così tanti ARP in primo luogo. Fino a quando non viene fornita una risposta, gli interruttori continueranno ad avere difficoltà a gestire la tempesta di arp. Mancata corrispondenza della maschera di rete? Timer arp host bassi? Uno (o più) host con una route "interfaccia"? Un rouge bridge wireless da qualche parte? "arp gratuito" impazzito? Sondaggio "in uso" del server DHCP? Non sembra un problema con gli switch o con il layer 2; hai host che fanno cose cattive.

Il mio processo di debug sarebbe quello di scollegare tutto e guardare attentamente mentre le cose vengono ricollegate, una porta alla volta. (So ​​che è miglia dall'ideale, ma ad un certo punto devi tagliare le perdite e tentare di isolare fisicamente qualsiasi possibile sorgente) Quindi lavorerei per capire perché le porte selezionate stanno generando molti arp.

(Molti di questi host sarebbero sistemi linux? Linux ha avuto un sistema di gestione della cache ARP molto stupido. Il fatto che "riconverterà" una voce in pochi minuti, è rotto nel mio libro Tende ad essere meno un problema nelle piccole reti, ma un / 20 non è una piccola rete.)

Questo potrebbe essere o non essere correlato al tuo problema, tuttavia ho pensato che potesse essere qualcosa che vale la pena buttare lì:

Al momento abbiamo alcuni 3750x in pila in alcuni dei nostri siti remoti, per lo più in esecuzione 15.0.2 (da SE0 a 4, ci sono alcuni bug FRU con SE0 da cui sto lentamente migrando).

Durante un aggiornamento IOS di routine, passando da 15.0.2 a 15.2-1 (la SE più recente) abbiamo notato un aumento della CPU piuttosto significativo, da una media di circa il 30% al 60% e superiore durante i periodi non di punta. Ho esaminato le configurazioni e i log delle modifiche IOS e ho lavorato con il TAC di Cisco. Secondo TAC, sembrano essere nel punto in cui credono che si tratti di un bug IOS 15.2-1.

Mentre continuavamo a indagare sull'aumento della CPU, abbiamo iniziato a vedere enormi quantità di traffico ARP al punto in cui le nostre tabelle ARP si sono riempite completamente e hanno causato instabilità di rete. La stampella temporanea per questo era di riportare manualmente i nostri timeout ARP dal default (14400) a 300 sui nostri furgoni voce e dati.

Dopo aver ridotto i nostri timeout ARP, siamo rimasti stabili per circa una settimana, a quel punto siamo tornati a IOS 15.0.2-SE4 e rimosso i nostri timeout ARP non predefiniti. Il nostro utilizzo della CPU è tornato al 30% circa e i problemi della nostra tabella ARP sono inesistenti.

Semplicemente fallito ma forse trascurato; i tuoi clienti hanno un gateway predefinito valido, ma il tuo core sta facendo un sacco di arpe proxy? Potresti considerare di annullare la funzione arp proxy ip sul tuo 3750?