Come ho rotto (metà della) mia rete?

Sto cercando alcuni consigli post-evento, quindi questo evento non si ripeterà più.

Abbiamo un nucleo di rete di due switch Cisco 4500x, configurati per la ridondanza VSS. Da questi, abbiamo dispositivi iSCSI, il nostro centro di assistenza HP per il nostro vSphere, oltre a collegamenti aggregati ai nostri switch di accesso utente e una coppia di switch 4948e per dispositivi in ​​rame nella nostra sala server. Al di fuori dei 4948 abbiamo una coppia di switch 2960 per due collegamenti ISP e una coppia di ASA come firewall. Ridondanza abbastanza decente, ad eccezione di molti dispositivi che si collegano al 4948e hanno solo schede di rete singole - solo così tanto che possiamo fare.

Ci stiamo preparando a sostituire i nostri attuali switch di accesso utente (vecchi Extremes) con Meraki. Stiamo anche implementando AP Meraki per sostituire i nostri attuali Aruba. Parte del progetto wireless prevede la creazione di alcune nuove VLAN e sottoreti, per la gestione degli AP e il wireless ospite.

Avevamo due VLAN definite (20 e 40) sulla 4500x che non venivano utilizzate da nessuna parte - confermavano che le sottoreti erano vuote, nessuna porta le utilizzava, ecc. Sono entrato nella 4500x e ho emesso " no interface vlan 20", quindi lo ho ricostruito con la sottorete Volevo. L'ho quindi aggiunto alle due porte da 10 GB collegate al Meraki

switchport trunk allowed <previous list plus two VLANs above plus existing wireless VLAN>

Ho notato che le VLAN 20 e 40 sono state chiuse, quindi le ho emesse no shutdown. Ho perso l'accesso ai Meraki a quel punto, quindi mi sono reso conto di non aver aggiunto le VLAN all'interfaccia del canale della porta per quel collegamento.

La metà del nostro ambiente è diventata irraggiungibile a questo punto

Il nostro collegamento Internet è diventato estremamente debole. I nostri telefoni VoIP Avaya non sono stati in grado di connettersi o disconnettersi. Abbiamo un paio di dispositivi iSCSI collegati in rame che sono diventati non disponibili - nessuna interruzione per qualsiasi cosa rivolta agli utenti, ma i nostri backup e archivio di posta hanno avuto un impatto. Sono andato nella sala server e ho disconnesso i Meraki dal 4500x (scollegato entrambe le porte in fibra da 10 Gb) nel caso in cui avessi in qualche modo creato un loop - nessuna modifica. Ammetto di averlo semplicemente fissato per un po 'a quel punto.

Ho tirato su Orion e ho notato che anche uno dei nostri switch esterni (il Cat2960) e uno dei nostri ASA erano inattivi. Sembra che abbiamo avuto una sorta di perdita parziale della connettività LAN, ma anche la coppia ASA è collegata tra loro con il crossover e i loro uplink non sono diminuiti, quindi non hanno effettuato il failover su ciò che i nostri dispositivi interni potevano raggiungere. Ho chiuso l'ASA "inattivo" e Internet è diventato nuovamente raggiungibile.

Ho chiamato TAC e dopo un paio d'ore di wrestling con la tecnologia che ha continuato a eseguire il nitpicking di ogni configurazione di porta per ogni host inattivo che gli stavo mostrando sul 4500x, ho effettuato l'accesso a uno dei nostri switch 4948e e ho mostrato come non potesse eseguire il ping delle cose che erano direttamente collegati e funzionanti: uno dei nostri dispositivi iSCSI in rame basati su Windows, un'interfaccia iLO sul nostro bladecenter, ecc.

Aveva esaminato i registri e non aveva trovato nulla, ma a questo punto ha detto "Sembra un bug di spanning tree anche se non lo vedo nei registri", quindi abbiamo riavviato il 4948e e tutto direttamente gli host collegati sono tornati indietro, incluso il cabinet Avaya, quindi i nostri telefoni hanno ripreso a funzionare. Avevamo ancora problemi con i dispositivi collegati in fibra 4500x: percorsi morti, poiché era tutto ridondante. Voleva spegnerlo in modo sgraziato, ma questo ha tutti i nostri iSCSI da 10 Gbit, e ciò avrebbe reso il nostro ambiente vSphere (essenzialmente tutti i nostri server) una settimana negativa. L'ho convinto a fare un grazioso passaggio di ridondanza, che si è preso cura dei problemi rimanenti.

TL; DR: ho apportato una modifica abbastanza innocua al nostro core e ho causato un problema orribile. Ho fatto un errore di configurazione che avrebbe dovuto essere la causa di ciò, ad esempio se non avessi prima spento le VLAN e le avessi aggiunte al portchannel e poi alle porte, questo sarebbe stato evitato? La tecnologia Cisco non lo ha detto; ha detto, con tempi di attività di oltre un anno e vecchie versioni di IOS, situazioni come questa non sono sorprendenti.

4500x: software Cisco IOS, software IOS-XE, software switch Catalyst 4500 L3 (cat4500e-UNIVERSALK9-M), versione 03.04.05.SG SOFTWARE DI RILASCIO (fc1) ROM: 15.0 (1r) SG10

4948e: Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500e-IPBASEK9-M), Versione 15.0 (2) SG10, SOFTWARE DI RILASCIO (fc1) ROM: 12.2 (44r) SG11

Sembra che tu abbia creato una tempesta di trasmissione e l'unico modo per fermarlo è spegnere gli interruttori. Dopo averlo vissuto diverse volte, abbiamo adottato alcune delle migliori pratiche consigliate da Cisco:

• Dovresti avere solo una VLAN estesa a un singolo switch di accesso. Puoi avere tutte le VLAN che desideri su uno switch di accesso, ma le VLAN su qualsiasi switch di accesso non devono essere trunking a nessun altro switch di accesso, ma solo allo switch di distribuzione. Applicare ciò disabilitando manualmente tutte le altre VLAN su un trunk con il switchport trunk allowed vlan comando.
• Uno switch di distribuzione non dovrebbe avere alcuna interfaccia di accesso, ma solo interfacce del trunk di distribuzione.
• Non utilizzare VTP (impostare tutti gli switch in transparentmodalità).
• Le interfacce di accesso devono essere abilitate portfaste bpduguardabilitate. Puoi abilitarli a livello globale per tutte le tue interfacce di accesso e le tue interfacce trunk rimarranno inalterate. Se si collega accidentalmente uno switch a un'interfaccia di accesso, ciò causerà l'accesso all'interfaccia err-diablee la prevenzione di loop STP.
• Non collegare un interruttore di accesso a un altro interruttore di accesso. Collegare gli switch di accesso solo agli switch di distribuzione e solo sulle interfacce trunk.

Queste best practice prevengono quasi tutti i problemi di STP e isolano eventuali problemi che si verificano in un singolo switch di accesso.

Oltre agli eccellenti consigli di Ron Maupin sopra, ho anche trovato diversi post sul forum di Cisco su un potenziale grande errore che ho fatto nel processo. Ho aggiunto prima le VLAN alle interfacce delle porte fisiche, non l'interfaccia delle porte e dei canali di cui erano membri. Quest'ultimo è il modo corretto di farlo e potrei aver causato il problema.