¿Cómo rompí (la mitad) de mi red?

Estoy buscando consejos posteriores al evento para que este evento no vuelva a suceder.

Tenemos un núcleo de red de dos conmutadores Cisco 4500x, configurados para la redundancia VSS. De ellos, tenemos dispositivos iSCSI, nuestro HP bladecenter para nuestro vSphere, más enlaces agregados a nuestros conmutadores de acceso de usuario y un par de conmutadores 4948e para dispositivos de cobre en nuestra sala de servidores. Fuera de los 4948 tenemos un par de conmutadores 2960 para dos enlaces ISP, y un par de ASA como firewalls. Redundancia bastante decente, excepto que muchos de los dispositivos que se conectan a la 4948e solo tienen NIC individuales, solo una cantidad que podemos hacer.

Nos estamos preparando para reemplazar nuestros conmutadores de acceso de usuario actuales (Extremes antiguos) con Meraki. También estamos implementando Meraki AP para reemplazar nuestros actuales Arubas. Parte del proyecto inalámbrico implica hacer algunas VLAN y subredes nuevas, para la administración de AP y la conexión inalámbrica de invitado.

Teníamos dos VLAN definidas (20 y 40) en el 4500x que no se usaban en ninguna parte: confirmamos que las subredes estaban vacías, no había puertos que las usaran, etc. Entré en el 4500x y emití " no interface vlan 20", y luego lo reconstruí con la subred Yo quería. Luego lo agregué a los dos puertos de 10 Gb que están conectados al Meraki

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

Me di cuenta de que las 20 y 40 VLAN estaban apagadas, así que las emití no shutdown. Perdí el acceso a Merakis en ese momento, así que me di cuenta de que no había agregado las VLAN a la interfaz del canal del puerto para ese enlace.

La mitad de nuestro entorno se volvió inalcanzable en este punto

Nuestro enlace de Internet se volvió extremadamente inestable. Nuestros teléfonos VoIP de Avaya no podían marcar dentro o fuera. Tenemos un par de dispositivos iSCSI conectados por cobre que no estuvieron disponibles, sin interrupciones por cualquier cosa que enfrentan los usuarios, pero nuestras copias de seguridad y el archivo de correo se vieron afectados. Entré en la sala de servidores y desconecté el Merakis del 4500x (desconecté los dos puertos de fibra de 10 Gb) en caso de que de alguna manera hubiera creado un bucle, sin cambios. Admito simplemente mirar esto por un momento en ese punto.

Detuve a Orion y noté que uno de nuestros interruptores externos (el Cat2960) y uno de nuestro par ASA también estaban inactivos. Al parecer, tuvimos algún tipo de pérdida parcial de conectividad LAN, pero el par ASA también está conectado entre sí, y sus enlaces ascendentes no se cayeron, por lo que no se trasladaron a lo que nuestros dispositivos internos podían alcanzar. Cerré el ASA "inactivo" y se volvió a acceder a Internet.

Llamé a TAC, y después de un par de horas luchando con el técnico que seguía seleccionando cada configuración de puerto para cada host caído que le mostraba en el 4500x, inicié sesión en uno de nuestros conmutadores 4948e y mostré cómo no podía hacer ping a las cosas. que estaban directamente conectados y en funcionamiento: uno de nuestros dispositivos iSCSI de cobre basados ​​en Windows, una interfaz iLO en nuestro centro Blade, etc.

Había examinado los registros y no encontró nada, pero en este punto dijo "Parece un error de árbol de expansión, incluso si no veo eso en los registros", por lo que reiniciamos el 4948e y todo directamente los hosts conectados volvieron a funcionar, incluido el gabinete Avaya, por lo que nuestros teléfonos comenzaron a funcionar nuevamente. Todavía teníamos problemas en los dispositivos conectados a la fibra 4500x: caminos muertos, ya que todo era redundante. Quería reiniciarlo sin gracia, pero esto tiene todo nuestro iSCSI de 10 Gbit, y eso habría hecho que nuestro entorno vSphere (esencialmente todos nuestros servidores) tuviera una mala semana. Lo convencí para que hiciera un elegante cambio de redundancia, que se ocupó de los problemas restantes.

TL; DR: Realicé un cambio bastante inocuo en nuestro núcleo y causé un problema horrible. ¿Cometí un error de configuración que debería haber sido predicho para causar esto? El técnico de Cisco no dijo eso; Dijo, con tiempos de funcionamiento de más de un año y versiones antiguas de iOS, situaciones como esta no son sorprendentes.

4500x: software Cisco IOS, software IOS-XE, software del conmutador Catalyst 4500 L3 (cat4500e-UNIVERSALK9-M), versión 03.04.05.SG SOFTWARE DE LIBERACIÓN (fc1) ROM: 15.0 (1r) SG10

4948e: software Cisco IOS, software del conmutador Catalyst 4500 L3 (cat4500e-IPBASEK9-M), versión 15.0 (2) SG10, ROM DE SOFTWARE DE LIBERACIÓN (fc1): 12.2 (44r) SG11

Parece que creó una tormenta de transmisión, y la única forma de detenerla es apagar los interruptores. Habiendo vivido esto varias veces, hemos adoptado algunas de las mejores prácticas recomendadas por Cisco:

• Solo debe tener una VLAN extendida a un solo conmutador de acceso. Puede tener tantas VLAN como desee en un conmutador de acceso, pero las VLAN de cualquier conmutador de acceso no deben conectarse a ningún otro conmutador de acceso, solo al conmutador de distribución. Haga cumplir esto deshabilitando manualmente todas las otras VLAN en una troncal con el switchport trunk allowed vlan comando.
• Un conmutador de distribución no debe tener interfaces de acceso, solo interfaces troncales de distribución.
• No use VTP (configure todos los interruptores en transparentmodo).
• Sus interfaces de acceso deberían tener portfasty estar bpduguard habilitadas. Puede habilitarlos globalmente para todas sus interfaces de acceso, y sus interfaces troncales no se verán afectadas. Si accidentalmente conecta un interruptor a una interfaz de acceso, esto hará que la interfaz entre err-diabley evite los bucles STP.
• No conecte un interruptor de acceso a otro interruptor de acceso. Solo conecte conmutadores de acceso a conmutadores de distribución, y solo en interfaces troncales.

Estas mejores prácticas evitarán casi todos los problemas de STP y aislarán cualquier problema que ocurra con un solo conmutador de acceso.

Además del excelente consejo anterior de Ron Maupin, también encontré varias publicaciones en el foro de Cisco sobre un gran error potencial que cometí en el proceso. Primero agregué las VLAN a las interfaces del puerto físico, no a la interfaz del canal del puerto del que eran miembros. Esta última es la forma correcta de hacerlo, y puedo haber causado el problema.