Je cherche des conseils post-événement pour que cet événement ne se reproduise plus.
Nous avons un cœur de réseau de deux commutateurs Cisco 4500x, configurés pour la redondance VSS. Parmi ceux-ci, nous avons des périphériques iSCSI, notre HP bladecenter pour notre vSphere, ainsi que des liens agrégés vers nos commutateurs d'accès utilisateur, et une paire de commutateurs 4948e pour les périphériques en cuivre dans notre salle de serveurs. Sur les 4948, nous avons une paire de commutateurs 2960 pour deux liaisons ISP et une paire d'ASA comme pare-feu. Redondance assez décente, à l'exception de la plupart des périphériques qui se connectent au 4948e ne disposent que de cartes réseau uniques - autant que nous pouvons faire.
Nous nous préparons à remplacer nos commutateurs d'accès utilisateur actuels (anciens Extremes) par Meraki. Nous mettons également en œuvre des AP Meraki pour remplacer nos Arubas actuels. Une partie du projet sans fil consiste à créer de nouveaux VLAN et sous-réseaux, pour la gestion des points d'accès et les services sans fil invités.
Nous avions deux VLAN définis (20 et 40) sur le 4500x qui n'étaient utilisés nulle part - j'ai confirmé que les sous-réseaux étaient vides, aucun port ne les utilisait, etc. Je suis entré dans le 4500x et j'ai émis " no interface vlan 20", puis je l'ai reconstruit avec le sous-réseau Je voulais. Je l'ai ensuite ajouté aux deux ports 10 Go connectés au Meraki
switchport trunk allowed <previous list plus two VLANs above plus existing wireless VLAN>
J'ai remarqué que les 20 et 40 VLAN étaient fermés, alors je les ai émis no shutdown. J'ai perdu l'accès au Merakis à ce moment-là, j'ai donc réalisé que je n'avais pas ajouté les VLAN à l'interface du canal de port pour cette liaison.
La moitié de notre environnement est devenu inaccessible à ce stade
Notre lien Internet est devenu extrêmement floconneux. Nos téléphones VoIP Avaya ne pouvaient ni entrer ni sortir. Nous avons quelques appareils iSCSI connectés au cuivre qui sont devenus indisponibles - aucune interruption pour tout ce qui concerne l'utilisateur, mais nos sauvegardes et nos archives de courrier ont été affectées. Je suis allé dans la salle des serveurs et j'ai déconnecté le Merakis du 4500x (débranché les deux ports fibre 10 Gb) au cas où j'aurais en quelque sorte créé une boucle - pas de changement. J'avoue avoir simplement regardé cela pendant un moment à ce moment-là.
J'ai tiré Orion et j'ai remarqué que l'un de nos commutateurs externes (le Cat2960) et l'un de nos paires ASA étaient également en panne. Apparemment, nous avons eu une sorte de perte de connectivité LAN partielle, mais la paire ASA est également connectée par croisement, et leurs liaisons montantes ne sont pas descendues, elles n'ont donc pas basculé vers ce que nos périphériques internes pourraient atteindre. J'ai arrêté l'ASA "en panne" et Internet est redevenu accessible.
J'ai appelé TAC, et après quelques heures de lutte avec la technologie qui a continué à tatouer chaque configuration de port pour chaque hôte tombé en panne que je lui montrais sur le 4500x, je me suis connecté à l'un de nos commutateurs 4948e et j'ai montré comment il ne pouvait pas cingler les choses qui étaient directement connectés et en place - l'un de nos appareils iSCSI en cuivre basés sur Windows, une interface iLO sur notre bladecenter, etc.
Il avait regardé les journaux et n'avait rien trouvé, mais à ce stade, il a dit "ressemble à un bogue de spanning tree même si je ne vois pas cela dans les journaux", alors nous avons redémarré le 4948e et tout son directement -des hôtes connectés sont revenus, y compris l'armoire Avaya, donc nos téléphones ont recommencé à fonctionner. Nous avions encore des problèmes avec les périphériques connectés à la fibre 4500x - des chemins morts, car tout était redondant. Il voulait le redémarrer de manière disgracieuse, mais cela a tous nos iSCSI 10 Gbit, et cela aurait fait que notre environnement vSphere (essentiellement tous nos serveurs) a eu une mauvaise semaine. Je l'ai convaincu de faire une transition de redondance gracieuse, qui a résolu les problèmes restants.
TL; DR: J'ai apporté un changement assez inoffensif à notre cœur et causé un problème hideux. Ai-je fait une erreur de configuration qui aurait dû provoquer cela - par exemple, si je n'avais pas arrêté les VLAN en premier et les ai ajoutés au canal de port puis aux ports, cela aurait-il été évité? La technologie Cisco n'a pas dit cela; dit-il, avec des temps de fonctionnement supérieurs à un an et d'anciennes versions d'IOS, des situations comme celle-ci ne sont pas surprenantes.
4500x: logiciel Cisco IOS, logiciel IOS-XE, logiciel de commutation Catalyst 4500 L3 (cat4500e-UNIVERSALK9-M), version 03.04.05.SG RELEASE SOFTWARE (fc1) ROM: 15.0 (1r) SG10
4948e: logiciel Cisco IOS, logiciel de commutation Catalyst 4500 L3 (cat4500e-IPBASEK9-M), version 15.0 (2) SG10, LOGICIEL DE LIBÉRATION (fc1) ROM: 12.2 (44r) SG11
En plus des excellents conseils de Ron Maupin ci-dessus, j'ai également trouvé plusieurs messages sur le forum de Cisco sur une grosse erreur potentielle que j'ai commise dans le processus. J'ai d'abord ajouté les VLAN aux interfaces de port physique, pas l'interface de canal de port dont ils étaient membres. Ce dernier est la bonne façon de le faire, et j'ai peut-être causé le problème.
la source