Come posso diagnosticare un loop ponte (ethernet)?

Dato che lo spanning tree è fallito (o non hai alcun spanning tree) e ottieni un loop ethernet, qual è il modo migliore per diagnosticare dove si trova il problema?

Quale interruttore ?, quale cavo? e così via.

OK, quindi supponi di avere una topologia come:

          SW1
         /   \
        /     \
       /       \
PC A--SW2-----SW3--PC B

Per qualche motivo esiste un ciclo ponte, STP è disabilitato o qualcuno ha applicato un filtro nel posto sbagliato o simile.

PC A vuole comunicare con PC B. Per prima cosa ARP per MAC di PC B, la destinazione è una trasmissione con MAC ffff.ffff.ffff. Quindi il frame va su SW1 e SW3. SRC MAC è PC A. SW1 quindi inonda il frame verso SW3 e SW3 inonderà il frame proveniente da SW2 a SW1.

SW1 e SW3 hanno appreso il MAC del PC A quando è arrivato il primo frame. Quando il secondo arriva dalla direzione opposta, deve riapprenderlo. Poiché questi eventi si verificano così rapidamente e ripetutamente, vedrai i messaggi di registro lamentarsi del flapping MAC. Qualcosa come "MAC FLAP 0000.0000.0001 sta sbattendo tra Gi0 / 24 e Gi0 / 23". Questo è un buon segno che hai un ciclo.

Quello che potresti fare allora è provare a rintracciare questo MAC. Prova a cercare nella cache ARP di un dispositivo nella stessa sottorete e vedi quale IP ha questo dispositivo. Quindi con il MAC potresti provare a rintracciarlo con sh mac-address-table o con l'IP forse hai un elenco con tutti gli IP e dove sono connessi.

Se l'host riceve un indirizzo IP da un server DHCP, è possibile provare anche lì da dove proviene l'host. Se hai abilitato l'opzione 82 sarebbe di grande aiuto.

Altri segni sono che la CLI sarà molto lenta. Il carico della CPU sarà molto elevato. Gli switch fanno quasi tutto negli ASIC, quindi se uno switch ha un carico della CPU superiore al 50%, probabilmente non va bene. È necessario implementare il monitoraggio SNMP e controllare l'elevato carico della CPU. Cerca anche i messaggi flap MAC. Se gli interruttori hanno un loop, i LED probabilmente lampeggeranno come un matto.

Cose che potresti fare per proteggere dai loop:

• Abilita STP! (Duh)
• Monitoraggio SNMP del carico della CPU
• Abilita trap SNMP per determinati eventi come le modifiche della topologia STP
• Abilita il controllo della tempesta sulle porte per limitare la trasmissione
• Non estendere troppo le VLAN nella topologia L2
• Abilitare la sicurezza della porta e limitare il numero di indirizzi MAC per porta
• Abilitare Option82 se si esegue DHCP

Uno dei miei utenti ha recentemente preso in prestito uno switch desktop dalla scrivania di qualcuno. Al ritorno dell'interruttore, hanno inserito tutte le estremità Ethernet che si trovavano nelle vicinanze. Uno di questi cavi è andato alla rete e un altro era due estremità dello stesso cavo. Lo switch desktop è stato collegato alla rete e anche a se stesso. Lo switch non aveva STP, quindi le trasmissioni che provenivano dalla rete si avvolgevano sull'altro cavo in entrambe le direzioni. Naturalmente, ogni volta che viene ricevuta una trasmissione sulle porte in loop, questa viene replicata nella rete. Ha fatto impazzire HSRP e, a causa della cattiva progettazione, ha portato anche a fallimenti di adiacenza OSPF in tutto il campus.

La prima indicazione del problema è stata un macflap inoltrato alla mia e-mail. Questo ci ha portato immediatamente all'armadio elettrico corretto. Da lì, è stato un processo di eliminazione basato su LED delle porte, interfaccia pps e registri. Inutile dire che da allora ho cercato di nuovo l'intero campus. La migliore misura preventiva è probabilmente bpduguard. Da allora ho implementato la funzione ed è stato abbastanza semplice. Ottenere quel syslog errabile nella mia e-mail è a dir poco felice.

Con la maggior parte delle apparecchiature, la CPU si spara al 100% e l'unica cosa che puoi fare è interrompere le connessioni fisiche ridondanti. Una volta che la CPU si è calmata, è possibile ricollegare i collegamenti uno a uno e vedere quale ri-causa il loop.

Per i grandi chassis (come un 6500) ho dovuto estrarre tutte le lame e ricollegarle una alla volta. Una volta capito quale lama, ho dovuto estrarre tutti i singoli collegamenti (16 GBIC) e rimetterli in uno alla volta. Mai divertente.

Alcune apparecchiature più moderne hanno una CPU protetta che dovrebbe semplificare la gestione: è ancora possibile interagire con la scatola. A quel punto diventa possibile osservare i contatori di traffico e tali per determinare il collegamento difettoso.

Di recente ho iniziato presso un'azienda in cui utilizzano i limiti di trasmissione su ciascuna porta. Se una porta supera il 5% della sua capacità durante le trasmissioni, lo switch la mette in ERRDISABLE.

 storm-control broadcast level 5.00  
 storm-control action shutdown

Questo è stato un salvavita quando un gruppo tende a collegare dispositivi che collegano le reti wireless alla LAN.

Anche se per la tua vera domanda, l'ho sempre trovato manuale.

per IOS:

Probabilmente avrai indirizzi MAC che si agitano tra le porte. Cerca MAC_MOVE_NOTIFICATION(o simili) errori in:

sh logg

Ora per trovare il porto:

sh int g0/1 controller

cercare fuori dall'ordinario Multicaste dai Broadcastnumeri. Eventuali collisioni sono un brutto segno.

Ultimo ma non meno importante, non puoi accedere, perché la CPU è sviluppata :)

sh proc cpu

Come sta andando l'interruttore qui? Se si tratta solo di uno switch L2, non desideri nulla superiore a ~ 10%

Nel caso in cui tu abbia non gestito, o l'equivalenza di non gestito (mancanza di dettagli di accesso, o conoscenza del sistema operativo degli switch, ecc.), Switch e un bridge bridge, descrivo come farei per trovare il loop manualmente. Questo affronta anche il fondo fondamentale della domanda originale, "non hai STP".

L'algoritmo di base per la localizzazione dei guasti di questo loop è simile a STP, tranne per il fatto che non si ha prontamente accesso all'invio di BPDU con ID porta al loro interno.

• Innanzitutto, collegare un dispositivo abilitato a scaricare / annusare i pacchetti a una porta in uno degli switch. Questo dispositivo è ora diventato il dispositivo principale dell'albero.
  • Se devi localizzare i guasti in più posizioni, ad es. In un "campus" o simili, puoi guadagnare potendo accedere in remoto con un client ssh portatile alla macchina di scarico dei pacchetti.
    • Personalmente userei il mio laptop Linux con una connessione Internet con tcpdump in uno schermo e lo utilizzerei ad esempio da ipad o telefono.
  • Se non riesci ad accedere da solo in remoto, usa un amico per monitorare visivamente tcpdump, che probabilmente si sta allagando alla velocità del collegamento, rendendo facile notare una differenza ogni volta che il percorso verso il dispositivo sorgente loop è disconnesso.
• Successivamente, dovrai essenzialmente ricreare un albero, a partire dal tuo interruttore di root.
  1. E poiché puoi avere lo scenario in cui hai più collegamenti ciclici che si alimentano nel tuo dispositivo radice, devi iniziare rimuovendo contemporaneamente tutte le porte connesse contemporaneamente.
  2. Ricollegare le porte una alla volta e se in qualsiasi momento riappare il pacchetto, seguire questa porta fino allo switch collegato nell'altra estremità.
  3. Ripeti il ​​passaggio 1, finché non trovi le porte in loop e non riesci a scorrere più in basso nella struttura manuale.
  4. Dopo aver risolto la situazione del loop in questo switch, tornare allo switch sopra nella struttura e riprendere il passaggio 2. Questa ricorsione continua fino a quando il cavo finale non è stato ricollegato nello switch root.

Questa è una ricerca manuale completamente esauriente per le porte ad anello.

In genere ci sarà solo una coppia di porte che sono in loop, il che significa che la ricerca esaustiva e sicura con la prima rimozione di tutte le porte connesse (link) e quindi ricollegarle una per una non è necessaria. Se solo una coppia di porte sull'albero è in loop, puoi trovarla semplicemente disconnettendo una porta alla volta.

Tuttavia, il metodo o l'algoritmo generale "a prova di fallo" diventa ciò che ho descritto sopra.

Ahia. Ma ok, posso pensare a due modi in cui andrei a questo ...

Bulbo oculare: se gli switch hanno indicatori di porta, dovresti essere in grado di vedere quali porte sono più attive. Quelli sono quelli per iniziare a guardare prima. Si spera che i cavi siano etichettati in modo da poter cercare il frutto appeso basso di trovare due porte occupate, su due interruttori con lo stesso cavo.

Monitoraggio SNMP: se disponi di statistiche di utilizzo SNMP (o simili), cerca lo switch più occupato e le porte più occupate. Quindi vai a guardare i cavi.

... se hai cavi senza etichetta, inizia a tracciare ed etichettare come parte del tuo controllo delle porte più trafficate.

Risponderò a questa domanda basandomi sulla comprensione che esiste un'interruzione completa per il dominio di livello 2 in questione e che non si ha accesso alla gestione perché le CPU sono tutte collegate.

Il modo migliore per risolvere un loop ponte è iniziare a scollegare i collegamenti verso l'alto fino a quando non scompare. Supponi di avere un livello di accesso con switch standard con tutti gli switch di accesso collegati in una coppia di switch di distribuzione. Vai al primo interruttore di accesso e scollega gli uplink, se i LED per gli switchport smettono di funzionare, non è quell'interruttore, ricollegalo e vai al successivo. Ripeti finché non raggiungi un interruttore in cui hai scollegato i collegamenti verso l'alto e i LED continuano a lampeggiare rapidamente, questo è l'interruttore con il loop.

Ora avvia il processo di scollegamento sulle porte dell'utente finale fino a quando i LED non si calmano, quando lo fanno, l'ultimo su di te scollegato è stata la porta del problema, traccia il cavo e castiga l'utente in modo appropriato.

Ad essere onesti, se ti connetti in remoto (o tramite cavo console) al dispositivo, noterai che è molto lento, ci sarà un ritardo dal momento in cui digiti alle lettere che appaiono sulla CLI.

Se si tratta di uno switch Cisco, 2 semplici devono guardare le statistiche dell'interfaccia, saranno costantemente al 100% (o 255/255). Nei miei anni in cui ho avuto a che fare con gli switch, non ho ancora visto una porta colpire legittimamente il 100% di utilizzo. Oltre a ciò, controlla l'utilizzo della CPU (di solito "mostra la cronologia della CPU di processo"), le interfacce in loop di solito colpiranno la tua CPU piuttosto forte a meno che tu non stia eseguendo uno switch di fascia alta.

Tuttavia, STP dovrebbe essere abilitato davvero!

Ho avuto questo problema si verifica su una rete all'altra estremità degli Stati Uniti e ho dovuto aiutare in remoto alcuni analisti di livello uno tramite telefono e il mio link debole al loro sito. Il problema è stato ulteriormente complicato dal fatto che avevano diversi marchi di switch che avevano lentamente aggiunto alla rete nel corso degli anni. Quando hanno spostato l'ufficio, hanno segnato dove andava ogni porta, quindi hanno ricollegato tutto allo stesso modo nel nuovo ufficio e hanno avviato tutto. Inutile dire che la manciata di interruttori che avevano un albero di spanning funzionante non convergevano allo stesso modo e avevano tutti i tipi di loop e problemi. Quando ho finito di sistemare, sono stati scoperti non meno di tre switch non gestiti collegati in loop con il resto dell'infrastruttura.

Il modo in cui sono stato in grado di rintracciare ciascuno degli switch non gestiti è stato usando uno strumento chiamato nedi (sugli switch che potevano essere gestiti ho abilitato lldp / cdp). Prima ho generato mappe con nedi. Quindi nelle aree in cui la mappa mostrava le connessioni da uno switch a un altro, quindi di nuovo allo stesso switch, ho fatto in modo che il tecnico di rete sul sito tracciasse manualmente la linea. O ho spento manualmente le interfacce coinvolte con il loop o ho fatto scollegare i cavi alla persona in loco. Alla fine sono riuscito a far funzionare la rete come dovrebbe, nonostante tutti i folli switch di marca.

Una cosa che si può fare qui è vedere quali macchine sono collegate allo switch usando i comandi show cdp neighboro show lldp neighbor.

Se il comando di protezione BPDU non viene utilizzato e qualcuno collega uno switch non autorizzato con priorità inferiore (o indirizzo mac precedente), il nuovo dispositivo verrà negoziato come root Spanning Tree che causerà sicuramente un problema.

Nella mia esperienza è sempre stato il cavo che ho appena collegato, o non chiuso, o aggiunto al canale della porta. Più difficile è quando qualcun altro lo ha fatto e non ha paura di farlo immediatamente.

La determinazione di un loop dipende davvero dalla marca di switch che hai. Ad esempio, su uno switch Extreme, posso eseguire elrp-client su una VLAN e lo switch invierà fondamentalmente un frame di trasmissione su tutte le porte per quella VLAN e vedrà se ritorna da una di esse, in tal caso, mi dice quale porta (e) il frame è stato ricevuto nuovamente, rivelando in tal modo i candidati loop.

Su un Cisco, puoi abilitare il controllo della tempesta, che è un po 'più uno strumento smussato poiché bloccherà sostanzialmente la porta per un periodo di tempo fino a quando lo stato non cancella (o cancelli lo stato errabile) - in generale, tuttavia, questo tipo di cosa è rilevante solo quando si utilizzano switch Cisco in una topologia mista di dispositivi che non eseguono lo spanning tree né inoltrano BPDU.

Senza dubbio l'approccio più rapido che ho trovato è il monitoraggio delle velocità di pacchetti / sec di interfacce. Un'interfaccia di visualizzazione rapida con il filtro CLI appropriato elencherà ciascuna interfaccia e la velocità di pacchetti / sec. Per trovare la fonte del loop, cerca l'unica interfaccia con un pazzo pacchetto alto / sec di frequenza INPUT. All'interno di un tipico ambiente aziendale, con profili di utilizzo tipici, funziona sempre e comunque senza errori. Su un 6500 con molte interfacce non ci vuole molto tempo per individuare l'origine ...

Durante il loop, per un gran numero di traffico broadcast (ad es. Richiesta ARP) alla stazione finale può anche aumentare il carico sulla CPU (ad esempio se si utilizza una scheda realtek a 100 Mbit / s economica che calcola un checksum sulla CPU). Come fisicamente possibile trovare un loop se il cavo è disconnesso, il collegamento ha perso immediatamente su 2 porte.