Comment ai-je cassé (la moitié de) mon réseau?

11

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

mfinni
la source

Réponses:

5

Il semble que vous ayez créé une tempête de diffusion, et la seule façon de l'arrêter est d'éteindre les commutateurs. Après avoir vécu cela plusieurs fois, nous avons adopté certaines des meilleures pratiques recommandées par Cisco:

  • Vous ne devez avoir une extension VLAN qu’à un seul commutateur d’accès. Vous pouvez avoir autant de VLAN que vous le souhaitez sur un commutateur d'accès, mais les VLAN sur n'importe quel commutateur d'accès ne doivent pas être reliés à un autre commutateur d'accès, uniquement au commutateur de distribution. Appliquez cela en désactivant manuellement tous les autres VLAN sur un tronc avec la switchport trunk allowed vlan commande.
  • Un commutateur de distribution ne doit pas avoir d'interfaces d'accès, uniquement des interfaces de tronc de distribution.
  • N'utilisez pas VTP (mettez tous les commutateurs en transparentmode).
  • Vos interfaces d'accès devraient avoir portfastet être bpduguard activées. Vous pouvez les activer globalement pour toutes vos interfaces d'accès, et vos interfaces de ligne réseau resteront inchangées. Si vous connectez accidentellement un commutateur à une interface d'accès, cela entraînera l'entrée de l'interface err-diableet empêchera les boucles STP.
  • Ne connectez pas un commutateur d'accès à un autre commutateur d'accès. Connectez uniquement les commutateurs d'accès aux commutateurs de distribution, et uniquement sur les interfaces de jonction.

Ces meilleures pratiques empêcheront presque tous les problèmes STP et isoleront tous les problèmes qui surviennent à un seul commutateur d'accès.

Ron Maupin
la source
2
Ah oui. Un jour, j'espère travailler sur un réseau qui a assez d'argent, pas d'applications "bizarres" (c'est-à-dire L2), une communauté d'utilisateurs docile et un support de gestion suffisant pour suivre toutes les pratiques recommandées et de bon sens. Un jour.
Ron Trunk
1. La première suggestion sur les VLAN et les commutateurs d'accès, je ne suis pas sûr de comprendre.
mfinni
2. Notre "distribution" est vraisemblablement notre 4500x, qui est principalement constituée de troncs mais qui possède des connexions fibre iSCSI.
mfinni
3. Évitez VTP - considérera, ne pense pas que quoi que ce soit soit "transparent" aujourd'hui
mfinni
4. portfast et bdpuguard - examinera également cette suggestion
mfinni
3

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.

mfinni
la source
2
Vous pouvez le faire comme vous l'avez fait, si les interfaces membres sont en panne. En général, j'ai trouvé que je veux que les interfaces membres soient en panne, que je fasse toute la configuration, y compris le canal de port, puis, une fois que je le veux, mettre les choses en place.
Ron Maupin