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