Wie habe ich (die Hälfte) meines Netzwerks zerstört?

Ich bin auf der Suche nach Ratschlägen nach der Veranstaltung, damit diese Veranstaltung nicht noch einmal stattfindet.

Wir haben einen Netzwerkkern aus zwei Cisco 4500x-Switches, die für VSS-Redundanz konfiguriert sind. Von diesen haben wir iSCSI-Geräte, unser HP Bladecenter für unsere vSphere, aggregierte Links zu unseren Benutzerzugriffsschaltern und ein Paar 4948e-Schalter für Kupfergeräte in unserem Serverraum. Von den 4948ern haben wir ein Paar 2960-Switches für zwei ISP-Verbindungen und ein Paar ASA als Firewalls. Ziemlich anständige Redundanz, außer dass viele Geräte, die mit dem 4948e verbunden sind, nur einzelne Netzwerkkarten haben - nur so viel können wir tun.

Wir bereiten uns darauf vor, unsere aktuellen Benutzerzugriffsschalter (alte Extreme) durch Meraki zu ersetzen. Wir implementieren auch Meraki-APs, um unsere aktuellen Arubas zu ersetzen. Ein Teil des drahtlosen Projekts besteht darin, einige neue VLANs und Subnetze für die AP-Verwaltung und die drahtlose Gastfunktion zu erstellen.

Wir hatten zwei definierte VLANs (20 und 40) auf dem 4500x, die nirgendwo verwendet wurden - bestätigt, dass die Subnetze leer waren, keine Ports sie verwendeten usw. Ich ging in das 4500x und gab " no interface vlan 20" aus und baute es dann mit dem Subnetz neu auf Ich wollte. Ich habe es dann zu den beiden 10-Gbit-Ports hinzugefügt, die mit dem Meraki verbunden sind

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

Ich habe festgestellt, dass die 20 und 40 VLANs heruntergefahren wurden, also habe ich sie ausgegeben no shutdown. Zu diesem Zeitpunkt verlor ich den Zugriff auf die Merakis und stellte fest, dass ich die VLANs nicht zur Port-Channel-Schnittstelle für diese Verbindung hinzugefügt hatte.

Die Hälfte unserer Umwelt war zu diesem Zeitpunkt nicht mehr erreichbar

Unsere Internetverbindung war extrem schlecht. Unsere Avaya VoIP-Telefone konnten sich nicht ein- oder auswählen. Wir haben ein paar kupferverbundene iSCSI-Geräte, die nicht mehr verfügbar waren - kein Ausfall für Benutzer, aber unsere Backups und unser E-Mail-Archiv waren betroffen. Ich ging in den Serverraum und trennte den Merakis vom 4500x (beide 10-Gbit-Glasfaseranschlüsse wurden getrennt), falls ich irgendwie eine Schleife erstellt hatte - keine Änderung. Ich gebe zu, an diesem Punkt einfach eine Weile darauf zu starren.

Ich zog Orion hoch und stellte fest, dass einer unserer externen Schalter (der Cat2960) und einer unserer ASA-Paare ebenfalls ausgefallen waren. Anscheinend hatten wir einen teilweisen LAN-Konnektivitätsverlust, aber das ASA-Paar ist auch mit Crossover miteinander verbunden, und ihre Uplinks gingen nicht aus, sodass sie nicht auf das umschalteten, was unsere internen Geräte erreichen konnten. Ich habe die ASA "down" heruntergefahren und das Internet wurde wieder erreichbar.

Ich rief TAC an und nachdem ich ein paar Stunden mit dem Techniker gerungen hatte, der immer wieder jede Portkonfiguration für jeden ausgefallenen Host auswählte, den ich ihm auf dem 4500x zeigte, loggte ich mich in einen unserer 4948e-Switches ein und zeigte, wie es nicht pingen konnte die direkt verbunden und aktiv waren - eines unserer Windows-basierten Kupfer-iSCSI-Geräte, eine iLO-Schnittstelle in unserem Bladecenter usw.

Er hatte die Protokolle durchgesehen und nichts gefunden, aber an diesem Punkt sagte er "Sieht aus wie ein Spanning-Tree-Fehler, auch wenn ich das nicht in den Protokollen sehe", also haben wir den 4948e und alle seine direkt neu gestartet -verbundene Hosts kamen sofort wieder hoch - einschließlich des Avaya-Schranks, sodass unsere Telefone wieder funktionierten. Wir hatten immer noch Probleme mit den 4500x-Geräten mit Glasfaserverbindung - tote Pfade, da alles redundant war. Er wollte es unanständig aus- und wieder einschalten, aber dies hat alle unsere 10-Gbit-iSCSI, und das hätte dazu geführt, dass unsere vSphere-Umgebung (im Wesentlichen alle unsere Server) eine schlechte Woche hatte. Ich überredete ihn zu einer ordnungsgemäßen Redundanzumschaltung, die sich um die verbleibenden Probleme kümmerte.

TL; DR: Ich habe eine ziemlich harmlose Änderung an unserem Kern vorgenommen und ein schreckliches Problem verursacht. Habe ich einen Konfigurationsfehler gemacht, von dem vorhergesagt werden sollte, dass er dies verursacht - wenn ich z. B. zuerst die VLANs nicht heruntergefahren und sie dem Portkanal und dann den Ports hinzugefügt hätte, wäre dies vermieden worden? Der Cisco-Techniker hat das nicht gesagt. Er sagte, mit einer Betriebszeit von über einem Jahr und alten IOS-Versionen seien solche Situationen nicht überraschend.

4500x: Cisco IOS-Software, IOS-XE-Software, Catalyst 4500 L3-Switch-Software (cat4500e-UNIVERSALK9-M), Version 03.04.05.SG RELEASE SOFTWARE (fc1) ROM: 15.0 (1r) SG10

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

Es hört sich so an, als hätten Sie einen Broadcast-Sturm ausgelöst. Der einzige Weg, dies zu stoppen, besteht darin, die Schalter auszuschalten. Nachdem wir dies mehrmals durchlebt haben, haben wir einige von Cisco empfohlene Best Practices übernommen:

• Sie sollten ein VLAN nur auf einen einzelnen Zugriffsschalter erweitern. Sie können auf einem Zugriffsschalter so viele VLANs haben, wie Sie möchten, aber die VLANs auf jedem Zugriffsschalter sollten nicht mit einem anderen Zugriffsschalter, sondern nur mit dem Verteilungsschalter verbunden werden. Erzwingen Sie dies, indem Sie alle anderen VLANs in einem Trunk mit dem switchport trunk allowed vlan Befehl manuell deaktivieren .
• Ein Verteilungs-Switch sollte keine Zugriffsschnittstellen enthalten, sondern nur Verteilungs-Trunk-Schnittstellen.
• Verwenden Sie kein VTP (stellen Sie alle Schalter auf transparentModus).
• Ihre Zugangsschnittstellen sollten aktiviert portfastund bpduguardaktiviert sein. Sie können diese global für alle Ihre Zugriffsschnittstellen aktivieren, und Ihre Amtsleitungsschnittstellen bleiben davon unberührt. Wenn Sie versehentlich einen Switch an eine Zugriffsschnittstelle anschließen, wird die Schnittstelle aktiviert err-diableund verhindert STP-Schleifen.
• Schließen Sie einen Zugangsschalter nicht an einen anderen Zugangsschalter an. Verbinden Sie Zugriffsschalter nur mit Verteilungsschaltern und nur über Amtsleitungsschnittstellen.

Diese Best Practices verhindern fast alle STP-Probleme und isolieren alle Probleme, die bei einem einzelnen Zugriffsschalter auftreten.

Zusätzlich zu den oben genannten hervorragenden Ratschlägen von Ron Maupin habe ich im Cisco-Forum mehrere Beiträge zu einem möglichen großen Fehler gefunden, den ich dabei gemacht habe. Ich habe die VLANs zuerst zu den physischen Portschnittstellen hinzugefügt, nicht zu der Port-Kanal-Schnittstelle, zu der sie gehörten. Letzteres ist der richtige Weg, und ich habe das Problem möglicherweise verursacht.