Fehlerbehebung für Layer-2-Loops bei Catalyst Switches der Serie 9000

Einleitung

In diesem Dokument wird beschrieben, wie Layer-2-Schleifen in Netzwerken, einschließlich Catalyst Switches der Serie 9000, identifiziert werden und wie Fehler in diesen behoben werden. 

Voraussetzungen

Es wird empfohlen, dass Sie Spanning-Tree-Protokollkonzepte verstehen. 

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Layer-2-Schleifen verursachen Chavok in einem LAN. Der daraus resultierende "Broadcast-Sturm" beeinträchtigt die Kommunikation in den betroffenen virtuellen LANs und beeinträchtigt sowohl die Endpunkte als auch die Netzwerkgeräte. Das Problem nimmt mit der Zeit zu, da der Layer-2-Datenverkehr über keinen Mechanismus wie Time-to-Live (TTL) verfügt, der dazu führt, dass ein Paket letztendlich im Netzwerk verbraucht wird. Looped-Datenverkehr wie Address Resolution Protocol (ARP) oder Dynamic Host Configuration Protocol (DHCP) durchläuft stattdessen eine endlose Schleife, bis die Schleife unterbrochen wird. Eine mit der Untersuchung einer aktiven Schleife beauftragte Person befindet sich in einer stressigen Lage.

Glücklicherweise gibt es bewährte Methoden zur Untersuchung und Fehlerbehebung von Layer-2-Schleifen. In diesem Dokument wird die von Generationen von TAC-Technikern angewandte Methodik beschrieben. 

Spanning-Tree: Wie werden Schleifen verhindert?

Diese einfache Topologie zeigt das Spanning-Tree-Protokoll in Aktion. Die folgenden Punkte gelten für diese Topologie:

• Alle Verbindungen in diesem Beispiel haben die gleiche Bandbreite.
• D/F steht für Designated (die Portrolle) Forwarding (der Portstatus).
• R/F steht für Root (die Portrolle) Forwarding (der Portstatus).
• A/B steht für Alternate (die Portrolle) Blocking (der Port-Zustand).
• Die Wahl der Root-Bridge erfolgte, wobei der identifizierte Switch als Root-Bridge ausgewählt wurde. Alle Schnittstellen auf der Root-Bridge haben die Rolle "designiert" und den Status "weitergeleitet".
• Der Root-Port für die Switches AAAA und BBB ist der Port, der jeden Switch direkt mit der Root-Bridge verbindet.
• Auf der Verbindung, die AAAA mit BBB verbindet, gehört der designierte Port aufgrund der Bridge-MAC zu AAAA. 
• Auf der Verbindung, die AAAA mit BBBB verbindet, gehört der blockierende Port aufgrund der Bridge-MAC zu BBBB.

Spanning-Tree ist in dieser Topologie konvergiert, sodass Schleifen verhindert werden.  Die grünen Pfeile zeigen an, wie ein von einem Client-PC übertragenes Broadcast-Paket auf den verbundenen Switches weitergeleitet wird. Der Blocking-Port des BBB verhindert, dass der vom Client übertragene Broadcast unbegrenzt zwischen den Geräten schleifen kann.

Wie entstehen Broadcast-Stürme auf Layer 2?

Es gibt viele Szenarien, in denen die durch Spanning-Tree ermöglichte Loop-Verhinderung einen Broadcast-Sturm nicht verhindert.  

Physische (Layer1-) Probleme im Netzwerk können zu unidirektionalen Verbindungen führen, wodurch Spanning-Tree-Lautsprecher am zuverlässigen Austausch von BPDUs gehindert werden. Der unzuverlässige Empfang oder die unzuverlässige Bereitstellung von BPDUs führen zu einer unerwünschten und unerwarteten Spanning-Tree-Konvergenz.

Beispiel 1:

In diesem Szenario unterbricht das BBBB den Empfang von BPDUs von der Root-Bridge an ihrem Root-Port. BBBB konvergiert als Reaktion auf diesen BPDU-Verlust. Der Root-Port ist kein gangbarer Pfad zum Root mehr, da er keine BPDUs mehr empfängt und zu einem designierten Port wird. Der blockierende Port empfängt weiterhin BPDUs von AAAA und wird zum Root-Port. Keine der Schnittstellen blockiert, sodass eine Schleife entsteht.

Unidirectional Link führt zu einer unerwarteten Konvergenz von Spanning-Tree

Beispiel 2:

Netzwerkunterbrechungen können auch auftreten, wenn Spanning Tree wie erwartet konvergiert wird.  Bestimmte Geräte, die mit dem Netzwerk verbunden sind, können Vektoren für Schleifen sein. Ein Hub oder ein ähnliches Gerät, das unerwartet mit dem Netzwerk verbunden wird, kann zu Broadcast-Stürmen führen.

Hub, der mit dem Netzwerk verbunden ist, führt zu Broadcast-Stürmen

Fehlerbehebung

Es gibt viele Möglichkeiten, wie Netzwerktechniker sich Layer-2-Schleifen und Broadcast-Stürmen nähern. Dieser Abschnitt beschreibt eine bewährte Methode, die in unzähligen TAC-Fällen und bei katastrophalen Ausfällen getestet wurde.

Diese Methode nutzt sehr einfache Befehle und vermeidet Datenpunkte wie STP (Spanning Tree Protocol)-Topologieänderungsbenachrichtigungen (TCNs), deren Verfolgung chaotisch sein kann. TCNs in einer Rapid STP (RSTP)-Topologie treten auf, wenn Nicht-Edge-Ports von BLOCKING zu FORWARDING wechseln. Der Loop selbst kann STP-Lautsprecher so stark belasten, dass sie nicht vorhersehbar an der Konvergenz teilnehmen können. Schnittstellen auf viktimisierten Switches werden WEITERGELEITET, wenn sie eingehende BPDUs aufgrund ihrer überlasteten Kontrollebene nicht ordnungsgemäß verarbeiten können. Die TCNs sind oft Symptome, die offenbaren, dass Geräte, die Opfer sind, aber nicht unbedingt an der Quelle des Loops.

Anstelle von STP-TCNs sind Schnittstelleneingangsraten ein gültiger und linearer Datenpunkt, der berücksichtigt werden muss.  Schnittstellen, die an der Schleife teilnehmen, weisen viel höhere Eingangsraten auf als erwartet. Die Produktionsraten sind weniger Besorgnis erregend, da diese nachgeschalteten Geräte selbst wahrscheinlich Opfer sind. Sie können auch eine hohe Broadcast- und Multicast-Rate an den betroffenen Schnittstellen beobachten und feststellen, dass die durchschnittliche Paketgröße unter den erwarteten Wert fällt.

Mit nur diesen Befehlen können Netzwerktechniker die meisten, wenn nicht alle Layer-2-Schleifen auf unkomplizierte Weise isolieren:

• show interfaces | include ist up|Eingaberate

• show cdp neighbors <Schnittstelle> ODER show lldp neighbors <Schnittstelle>
• show spanning-tree

Der Befehl "show interfaces" | include is up|input rate" mit der Pipe und Argumente liefern uns einen schnell verdaulichen Ausschnitt. Es zeigt uns alle unsere Schnittstellen, die derzeit 'up' sind, sowie ihre Eingangsraten. Für unsere Zwecke interessieren wir uns nur für die Inputraten. Schnittstellen mit unerwartet hohen Eingangsraten sind wahrscheinlich Opfer des Loops. Das Gerät, das an eine Schnittstelle mit unerwartet hoher Eingangsrate angeschlossen ist, liegt wahrscheinlich näher an der Quelle der Schleife.  Schnittstellen mit unerwartet hohen Ausgangsraten führen uns wahrscheinlich von der Quelle der Schleife weg.

ACCESS-SWITCH1#show interfaces | in is up|input rate
<snip>
GigabitEthernet1/0/1 is up, line protocol is up (connected) <----- Typical endpoint with a low input rate. This would not raise suspiscion.
  5 minute input rate 33000 bits/sec, 21 packets/sec
GigabitEthernet1/0/2 is up, line protocol is up (connected)
  5 minute input rate 24000 bits/sec, 11 packets/sec
<snip>
  5 minute input rate 0 bits/sec, 0 packets/sec            <----- This output represents interfaces that are down.
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
TwentyFiveGigE1/1/1 is up, line protocol is up (connected) <----- Twe1/1/1 in this scenario is high-bandwith uplink interface. We would expect uplinks to have a fair amount of traffic on input.
  5 minute input rate 2816922000 bits/sec, 2072252 packets/sec.    If we were troubleshooting a loop, pay special attention to this interface given the input rate.
TwentyFiveGigE1/1/2 is up, line protocol is up (connected)
    5 minute input rate 2926942401 bits/sec, 3043467 packets/sec <-- The same logic goes for this port. The input rate is relatively high but that is possibly function of its position in the network.
TwentyFiveGigE1/1/3 is up, line protocol is up (connected)
      5 minute input rate 0 bits/sec, 0 packets/sec
<snip>

• show cdp neighbors <Schnittstelle> ODER show lldp neighbors <Schnittstelle>

ACCESS-SWITCH1#show cdp neighbor twe1/1/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
ACCESS-SWITCH2           Twe 1/1/1         142              S I   C9300-48P Twe 1/1/4 <--- We confirm that the expected neighbor is attached to this interface.

Total cdp entries displayed : 1

• show spanning-tree

Verwenden Sie diesen Befehl, um zu erfahren, wie der lokale Switch die Konvergenz von Spanning Tree glaubt.  Beachten Sie die Unterschiede in den verschiedenen Varianten von Spanning Tree. Catalyst Switches führen standardmäßig Rapid-PVST aus, unterstützen jedoch PVST und MST.

ACCESS-SWITCH1#show spanning-tree  

VLAN0001                                  <----- Keep in mind that in per-vlan spanning-tree, each VLAN represents a unique instance of spanning-tree
  Spanning tree enabled protocol rstp
  Root ID    Priority    1
             Address     380e.4d77.4800
             Cost        2000
             Port        3 (TwentyFiveGigE1/0/3)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     b08b.d08d.6b80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gig1/0/1            Desg FWD 20000     128.1    P2p
Gig1/0/2            Desg FWD 20000     128.2    P2p
<snip>
Twe1/1/1            Root FWD 800       128.33   P2p
Twe1/1/2            Desg FWD 800       128.34   P2p
Twe1/1/3            Alt  BLK 800       128.35   P2p <---- This output corresponds with expectation. This step helps to populate STP information in your topology as you move from device to device

Diese einfache Methode vermeidet zeitaufwendige Paketerfassungen, macht Spanning-Tree-TCNs überflüssig und stellt das eigentliche Problem weiterhin in den Mittelpunkt der Untersuchung. Außerdem entfällt die Fehlerbehebung durch "rate and check".

Betrachten wir dieses Topologiediagramm:

Client-Broadcast-Pfad in konvergenter Topologie

Aufgrund der redundanten Verbindungen zwischen den Switches blockiert der Spanning-Tree mehrere Ports in dieser Topologie. In diesem Beispiel stellt die gelbe X-Grafik die blockierenden Ports dar. Die Weiterleitungs-Ports sind alle entweder designiert oder "root", abhängig vom Standort des lokalen Switches im Vergleich zur Root-Bridge.  Die grünen Pfeile stellen den normalen, erwarteten Broadcast-Datenverkehrsfluss dar, den ein Beispielclient in diesem Netzwerk senden würde.

Dieses Netzwerk ist zwar nicht sonderlich komplex, bietet jedoch aufgrund der vielen redundanten Verbindungen zahlreiche Möglichkeiten zur Bildung von Schleifen.  

Dieser Ausschnitt aus der größeren Topologie konzentriert sich auf die Spanning-Tree-Rollen/-Zustände des Access Switches, mit dem der Server eine Verbindung herstellt.

Spanning-Tree-Konvergenz

Stellen Sie sich eine unidirektionale Verbindung vor, die verhindert, dass der Downstream-Access-Switch BPDUs auf seinem Root-Port empfängt. Spanning-Tree wird als Reaktion darauf neu konvergiert, und es entsteht eine Layer-2-Schleife.

Der ehemalige Root-Port von ACCESS-C empfängt keine BPDUs mehr von DISTRO-B. Der Switch erkennt ihn nicht mehr als praktikablen Pfad zum Root-Netzwerk, sodass der Port mit der höchsten Priorität als ROOT/FORWARDING eingestuft wird. Der vorherige Root-Port wechselt zu DESIGNATED/FORWARDING. Diese Rekonvergenz führt zu einem Weiterleitungs-Loop.

Dieses Diagramm zeigt, wie sich die Schleife auf den Broadcast-Datenverkehr auswirkt, der von unserem Client gesendet wird.  Solange die Schleife nicht unterbrochen wird, wird der Schleifenverkehr unbegrenzt fortgesetzt, und es besteht die Möglichkeit, dass ein- und ausgehender Datenverkehr einen Switch an mehreren Schnittstellen beschädigt. Sie können mehrere rote Pfeile sehen, die die Richtung des schleifenförmigen Datenverkehrs darstellen. 

Das Problem nimmt weiter zu, da immer mehr Datenverkehr unendlich viele Schleifen durchläuft. Die Catalyst Switches der Serie 9000 nutzen standardmäßig einen robusten CoPP-Mechanismus (Control Plane Policing), bei einigen Produkten ist dies jedoch nicht der Fall. Bei Switches mit einer SVI (Local Switch Virtual Interface) in einem VLAN mit Schleife wird eine Kopie des Broadcast-Datenverkehrs innerhalb dieses VLAN an die CPU gesendet. Ohne CoPP kann dieser gesamte Datenverkehr die Switch-CPU unterbrechen. Dies verschlechtert die Situation tendenziell noch, da die Switches, die Opfer von Angriffen wurden, nicht wie erwartet am Spanning Tree teilnehmen können.

Methodik

Eine der ersten Herausforderungen bei der Fehlerbehebung besteht darin, den richtigen Ansatz zu finden.  Letztlich ist die Position, in der wir anfangen, nicht sonderlich wichtig.  Alle Geräte, die von der Schleife betroffen sind, werden schließlich zur Quelle der Schleife verfolgt.

In diesem Beispiel beginnen wir mit dem Switch, über den der betroffene Client eine Verbindung herstellt.

Ausgangspunkt - ACCESS-A - Direkt mit dem Client verbunden

Diese Methode macht den Anfangspunkt irrelevant.  Alle betroffenen Schnittstellen zeigen auf die Quelle des Problems. Wenn dieser Prozess verfolgt wird, gelangen Sie an die Quelle der Schleife bzw. Reflektion. In diesem Szenario stellt der betroffene Client eine Verbindung mit dem Switch ACCESS-A her. Hier fangen wir an. Der erste Schritt in diesem Prozess besteht darin, die Eingangsraten an allen aktiven Schnittstellen zu berücksichtigen.

• show interfaces | include ist up|Eingaberate

ACCESS-A#show interfaces | in is up|input rate

GigabitEthernet1/0/1 is up, line protocol is up (connected) 
  5 minute input rate 33000 bits/sec, 21 packets/sec          <--- This access port (downlink) has a small volume of traffic inbound. This does not raise suspiscion. 
<snip>
  5 minute input rate 0 bits/sec, 0 packets/sec            
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
TwentyFiveGigE1/1/1 is up, line protocol is up (connected)
  5 minute input rate 2816922000 bits/sec, 2672252 packets/sec <--- This port is an uplink. There is a fair amount of traffic inbound on this port, but also keep in mind that the uplink is expected to be busier.  
TwentyFiveGigE1/1/2 is up, line protocol is up (connected) <--- This is our other uplink on this switch. The input rate is zero, suggesting the other end of this link is not transmitting. This implies that the other end of the link successfully blocks.
    5 minute input rate 0 bits/sec, 0 packets/sec 

Die durchschnittliche Paketgröße wird berechnet, indem Bytes pro Sekunde durch Pakete pro Sekunde geteilt werden. In diesem Beispiel liegt die durchschnittliche Paketgröße bei etwa 132 Byte. Dies deutet auf ein hohes Volumen an kleinen Paketen hin, das den Durchschnitt verzerrt. Ein hohes Volumen an ARP kann beispielsweise die gleiche Verzerrung der erwarteten durchschnittlichen Paketgröße in einem Produktionsnetzwerk verursachen und deutet darauf hin, dass der Port durch den Broadcast-Sturm zum Opfer fällt.

Keiner der Downlinks zeigt ungewöhnliche Eingaberaten an. Der einzige potenziell betroffene Port ist der Root-Port - der Uplink zum Distribution Layer. Bevor wir zum nächsten Gerät übergehen, sollten Sie zunächst Spanning-Tree für den Switch in Betracht ziehen.

• Spanning Tree anzeigen 

ACCESS-A#show spanning-tree  <--- Without an argument, this command gives spanning-tree information for all VLANs with an active STP instance running. For this example, we assume VLAN 1 is consistent with all VLANs on the trunk.

VLAN0001                                  
  Spanning tree enabled protocol rstp
  Root ID    Priority    1
             Address     380e.4d77.4800
             Cost        2000
             Port        3 (TwentyFiveGigE1/1/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     b08b.d08d.6b80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gig1/0/1            Desg FWD 20000     128.1    P2p
Gig1/0/2            Desg FWD 20000     128.2    P2p
<snip>
Twe1/1/1            Root FWD 800       128.33   P2p
Twe1/1/2            Desg FWD 800       128.34   P2p

<snip>

An dieser Stelle ist es wichtig, dass Sie Ihr Netzwerk kennen und wissen, wie Spanning Tree konvergieren soll. Te1/1/1 ist der erwartete Root-Port. Twe1/1/2 stellt ebenfalls eine Verbindung zu einem Switch her und leitet den Datenverkehr weiter. Die Eingangsrate beträgt jedoch 0 Pakete/s, sodass wir wissen, dass das andere Ende der Verbindung erfolgreich blockiert wird. Spanning-Tree ist kein Problem. Jetzt bestätigen wir den Link-Peer am betroffenen Port.

• show cdp neighbor <Schnittstelle>

ACCESS-A#show cdp neighbors twentyFiveGigE 1/1/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
DISTRO-A         Twe 1/1/1        137        S I         C9300-48P Twe 1/0/3

Next-Hop Switch - DISTRO-A

DISTRO-A

Der nächste Schritt ist eine Wiederholung der vorherigen Aktivität auf dem Switch, der eine Verbindung zur verdächtigen Schnittstelle herstellt.  Führen Sie "Schnittstellen anzeigen" aus. | include is up|input rate" zur Identifizierung von Schnittstellen mit verdächtig hohen Eingangsraten.

• show interfaces | include ist up|Eingaberate

DISTRO-A#show interfaces | in is up|input rate       

  5 minute input rate 0 bits/sec, 0 packets/sec            
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
TwentyFiveGigE1/1/1 is up, line protocol is up (connected)
  5 minute input rate 4846092202 bits/sec, 4572251 packets/sec   <-- In this scenario, this input rate raises red flags. This is another situation where understanding normal baselines is helpful.
TwentyFiveGigE1/1/2 is up, line protocol is up (connected) 
  5 minute input rate 0 bits/sec, 0 packets/sec                  <-- The other end of this link is likely blocking.
TwentyFiveGigE1/1/3 is up, line protocol is up (connected) 
  5 minute input rate 146192134 bits/sec, 171252 packets/sec     <-- Fair amount of usage, though exponentially smaller that our 'suspect' link. Again, knowing expected baselines is helpful to identify when deviations occur. This is a downlink towards an access switch in this scenario, and does not raise red flags.
TwentyFiveGigE1/1/4 is up, line protocol is up (connected) 
  5 minute input rate 4938392202 bits/sec, 4723294 packets/sec   <-- This is along the same magnitude of input as Twe1/1/1. Often, interfaces impacted by the same broadcast storm shows similar activity. In our scenario, this interface raises red flags.
TwentyFiveGigE1/1/5 is up, line protocol is up (connected) 
  5 minute input rate 032182156 bits/sec, 104263 packets/sec     <-- Similar to Twe1/1/3, this interface is active but not at a suspicious level.

Bei DISTRO-A wurden zwei Schnittstellen gefunden, deren Eingangsraten höher waren als erwartet. Die Art der Schleifen bedeutet, dass es in der Regel mehrere Pfade zur Quelle gibt.  Beide Schnittstellen werden beachtet, aber zuerst wird Spanning-Tree auf etwas überprüft, das außerhalb des Normbereichs liegt.

• show spanning-tree 

DISTRO-A#show spanning-tree

VLAN0001                                  
  Spanning tree enabled protocol rstp
  Root ID    Priority    1
             Address     380e.4d77.4800
             Cost        2000
             Port        3 (TwentyFiveGigE1/1/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     c18b.a18d.5b76
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Twe1/1/1            Root FWD 800       128.33   P2p
Twe1/1/2            Desg FWD 800       128.34   P2p
Twe1/1/3            Desg FWD 800       128.35   P2p
Twe1/1/4            Desg FWD 800       128.36   P2p
Twe1/1/5            Desg FWD 800       128.37   P2p
<snip>

Wenn Sie sich die Position von DISTRO-A im Netzwerk anschauen, können Sie sehen, dass alle Ports an diesem Switch zur Weiterleitung erwartet werden. Es hat einen Root-Port (Twe1/1/1), der es direkt mit der Root-Brige verbindet. Alle Downlinks und Verbindungen zu anderen Switches werden zugewiesen und weitergeleitet. Dieser wird mit unserem Spanning-Tree-Output verfolgt.

Jetzt überprüfen wir die Peers auf unseren verdächtigen Schnittstellen und entscheiden, wie es weitergehen soll.  Beide Richtungen führen zu unserer Ankunft an der Quelle der Schleife.

• show cdp neighbors <Schnittstelle>

DISTRO-A#show cdp neighbors twentyFiveGigE 1/1/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
CORE             Twe 1/1/1       137        S I         C9500-48Y4C Twe 1/0/1

DISTRO-A#show cdp neighbors twentyFiveGigE 1/1/4
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
ACCESS-B         Twe 1/1/4        137        S I         C9300-48P Twe 1/1/1

Zunächst wollen wir uns die CORE-Technologie ansehen. In diesem Szenario wäre der Wechsel zu ACCESS-B jedoch genauso wichtig.

Next-Hop Switch - CORE

• show interfaces | include ist up|Eingaberate

CORE#show interfaces | in is up|input rate       
TwentyFiveGigE1/0/1 is up, line protocol is up (connected)     <--- Both active downlinks have comparably high input rates. It is not unexpected for core devices to have high interface activity. 
  5 minute input rate 4946092202 bits/sec, 4671352 packets/sec 
TwentyFiveGigE1/0/2 is up, line protocol is up (connected)
  5 minute input rate 4936092202 bits/sec, 4474252 packets/sec <--- It appears that both Twe1/0/1 and Twe1/0/2 are victimized. These are the only active downlinks, so this makes sense.
  <snip>
    5 minute input rate 0 bits/sec, 0 packets/sec            
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec

Da dieser Switch die Root-Bridge ist, erwarten wir, dass alle Schnittstellen weitergeleitet werden. Mit "show spanning-tree" schnell bestätigen.

CORE#show spanning-tree

VLAN0001
  Spanning tree enabled protocol rstp
  Root ID    Priority    1
             Address     380e.4d77.4800
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    1      (priority 0 sys-id-ext 1)
             Address     380e.4d77.4800
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Twe1/0/1            Desg FWD 800       128.25   P2p
Twe1/0/2            Desg FWD 800       128.26   P2p

Es gibt keine unerwarteten Eingangspfade für den Broadcast-Sturm. Nach den uns vorliegenden Informationen befindet sich der Loop stromabwärts des Cores. Jetzt überprüfen wir unsere Peers auf unseren Downlinks.

• CDP-Nachbarn anzeigen

CORE#show cdp neighbors twentyFiveGigE 1/0/1
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
DISTRO-A         Twe 1/0/1       144        S I         C9300-48P Twe 1/1/1

CORE#show cdp neighbors twentyFiveGigE 1/0/2
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
DISTRO-B         Twe 1/0/2        139        S I         C9300-48P Twe 1/1/1

Wir kommen gerade aus DISTRO-A. Wir können DISTRO-A erneut aufrufen und unsere andere Schnittstelle/den anderen Peer auf diesem Switch überprüfen, die/der als verdächtig markiert wurde, oder wir können zu DISTRO-B wechseln. Als Nächstes schauen wir uns DISTRO-B an.

Next-Hop Switch - DISTRO-B

DISTRO-B

                    

• show interfaces | include ist up|Eingaberate

DISTRO-B#show interfaces | in is up|input rate   
<snip>
  5 minute input rate 0 bits/sec, 0 packets/sec            
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
TwentyFiveGigE1/1/1 is up, line protocol is up (connected)
  5 minute input rate 4446192309 bits/sec, 4673252 packets/sec <--- Suspicious 
TwentyFiveGigE1/1/2 is up, line protocol is up (connected)
  5 minute input rate 4457101202 bits/sec, 4571365 packets/sec <--- Suspicious
TwentyFiveGigE1/1/3 is up, line protocol is up (connected)
  5 minute input rate 136192034 bits/sec, 170261 packets/sec  
TwentyFiveGigE1/1/4 is up, line protocol is up (connected)
  5 minute input rate 4936092202 bits/sec, 4474252 packets/sec <--- Suspicious
  

Jetzt werfen wir einen kurzen Blick auf Spanning-Tree, um sicherzustellen, dass die Dinge wie erwartet aussehen.

• show spanning-tree

DISTRO-B#show spanning-tree

  VLAN0001                                  
  Spanning tree enabled protocol rstp
  Root ID    Priority    1
             Address     380e.4d77.4800
             Cost        800
             Port        3 (TwentyFiveGigE1/1/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     b08b.d08d.6b80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

  Interface           Role Sts Cost      Prio.Nbr Type
  ------------------- ---- --- --------- -------- --------------------------------
  <snip>
  Twe1/1/1            Root FWD 800       128.33   P2p
  Twe1/1/2            Desg FWD 800       128.34   P2p
  Twe1/1/3            Desg FWD 800       128.33   P2p
  Twe1/1/3            Desg FWD 800       128.33   P2p
  Twe1/1/5            Alt  BLK 800       128.34   P2p
  

Spanning-Tree auf diesem Switch entspricht den Erwartungen, die wir in einem stabilen Netzwerk erfüllen. Wir können sehen, dass unser Root-Port wie erwartet konvergiert ist und dass unsere Verbindung zu DISTRO-B (Twe1/1/4)-Blöcken besteht. Unsere Schnittstellen für den Zugriff sind designiert/weiterleitend. 

Jetzt untersuchen wir unsere Peers auf den verdächtigen Schnittstellen.

• show cdp neighbors <Schnittstelle>

DISTRO-B#show cdp neighbors twentyFiveGigE 1/1/1
  Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                    S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                    D - Remote, C - CVTA, M - Two-port Mac Relay

  Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
  CORE             Twe 1/1/1         144        S I         C9500-48Y4C Twe 1/0/1

  DISTRO-B#show cdp neighbors twentyFiveGigE 1/1/2
  Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                    S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                    D - Remote, C - CVTA, M - Two-port Mac Relay

  Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
  ACCESS-C         Twe 1/1/2         139       S I         C9300-48P Twe 1/1/1

  DISTRO-B#show cdp neighbors twentyFiveGigE 1/1/5
  Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                    S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                    D - Remote, C - CVTA, M - Two-port Mac Relay

  Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
  DISTRO-A         Twe 1/1/5         132        S I         C9300-48P Twe 1/1/2

Wir sind gerade von CORE gekommen und haben DISTRO-A bereits besucht. Auf der Grundlage unserer bisherigen Erkenntnisse leitet uns die Logik zu ACCESS-C weiter.

ZUGRIFF C

ACCESS-C#show interfaces | in is up|input rate
  
GigabitEthernet1/0/1 is up, line protocol is up (connected) 
    5 minute input rate 43012 bits/sec, 34 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec            
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec
    5 minute input rate 0 bits/sec, 0 packets/sec
<snip>
TwentyFiveGigE1/1/1 is up, line protocol is up (connected)
    5 minute input rate 0 bits/sec, 0 packets/sec                <-- This interface has zero packets inbound. Normally this means the interface on the other end of the link is blocking. In this scenario we need to take a closer look since the upstream switch is a distribution switch.
TwentyFiveGigE1/1/2 is up, line protocol is up (connected)
    5 minute input rate 4834056103 bits/sec, 4461235 packets/sec <-- This interface has a suspicious input rate.
TwentyFiveGigE1/1/3 is up, line protocol is up (connected)
    5 minute input rate 4456091109 bits/sec, 4573242 packets/sec <-- This interface also has a suspicious input rate.

Dieser Schalter wird offensichtlich von der Schleife beeinflusst. Zwei Schnittstellen weisen auf Viktimisierung hin. Außerdem gibt es einen Uplink zum Distribution Layer, der unerwartet leise ist. Wir nehmen diese Beobachtungen zur Kenntnis und überprüfen Spanning-Tree als Nächstes, um festzustellen, ob etwas auffällt.

• show spanning-tree 

ACCESS-C#show spanning-tree

    VLAN0001                                  
    Spanning tree enabled protocol rstp
    Root ID    Priority    1
               Address     380e.4d77.4800
               Cost        1600
               Port        4 (TwentyFiveGigE1/1/2)
               Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

    Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
               Address     b08b.d08d.6b80
               Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
               Aging Time  300 sec

    Interface           Role Sts Cost      Prio.Nbr Type
    ------------------- ---- --- --------- -------- --------------------------------
    Gig1/0/1            Desg FWD  20000    128.01   P2P
    <snip>
    Twe1/1/1            Desg FWD 800       128.33   P2p
    Twe1/1/2            Root FWD 800       128.34   P2p
    Twe1/1/3            Alt  BLK 800       128.33   P2p

Auch hier lohnt es sich, Spanning-Tree-Prozesse und die Anforderungen an Ihr Netzwerk zu verstehen. Basierend auf dem vorherigen Diagramm, das die erwartete Spanning-Tree-Konvergenz zeigt, wird erwartet, dass ACCESS-C über zwei blockierende Ports verfügt. In der Ausgabe von show spanning-tree ist nur ein blockierender Port aufgelistet, was ein enormes rotes Flag darstellt. Da dies bei der Fehlerbehebung unauffällig sein kann, sollten wir uns ansehen, was bei diesem Switch noch als außergewöhnlich herausstellt.

Access-Switches in einem mehrstufigen Netzwerk haben in der Regel einen Root-Port und einen oder mehrere alternative Ports zum Root-Port. Die Downlinks von der Root-Bridge sind in der Regel 'designiert' und 'weiterleitend'. Twe1/1/1 wird als designierter Port angezeigt, d. h., er glaubt, näher an der Root-Bridge zu sein als sein Verbindungspartner. In unserem Diagramm sind keine Portnummern aufgeführt. Lassen Sie uns daher überprüfen, welche Geräte an welche Ports des verdächtigen Geräts angeschlossen sind.

• CDP-Nachbarn anzeigen

ACCESS-C#show cdp neighbors twentyFiveGigE 1/1/1
    Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                      S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                      D - Remote, C - CVTA, M - Two-port Mac Relay

    Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID. <--- There is no neighbor information listed for this interface. Very suspiscious. 
    
ACCESS-C#show cdp neighbors twentyFiveGigE 1/1/2
    Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                      S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                      D - Remote, C - CVTA, M - Two-port Mac Relay

    Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
    ACCESS-B         Twe 1/1/2         144        S I         C9300-48P Twe 1/1/3

ACCESS-C#show cdp neighbors twentyFiveGigE 1/1/3
    Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                      S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                      D - Remote, C - CVTA, M - Two-port Mac Relay

    Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
    DISTRO-A         Twe 1/1/3         137        S I         C9300-48P Twe 1/1/2

Für die Schnittstelle Twe1/1/1 ist kein Nachbar aufgeführt. Dies weist darauf hin, dass der vom Peer gesendete CDP-Frame nicht eintrifft (oder eintrifft und nicht verarbeitet werden kann), und schlägt in diesem Zusammenhang eine unidirektionale Verbindung vor. Derzeit liegen genügend Beweise vor, um die Verbindung zwischen DISTRO-B und ACCESS-C genauer zu untersuchen. 

Die Eingangsrate von Null an dieser Schnittstelle, während erwartet wird, dass das andere Ende basierend auf der Spanning-Tree-Ausgabe und der Schnittstellenausgangsrate weitergeleitet wird. Zusammen mit der unerwarteten STP-Konvergenz, bei der jedes Ende der Verbindung die Bezeichnung erhält, und dem Mangel an CDP-Informationen ist diese Verbindung unidirektional.

Der schnellste Weg, den Kreis in dieser Situation zu durchbrechen, wäre Twe1/1/1 auf ACCESS-A zu schließen.  Sobald Twe1/1/1 geschlossen ist, bricht die Schleife physisch ab. Sobald die Schleife physisch unterbrochen ist, beginnt der Broadcast-Sturm sofort abzuklingen.

Dies war ein vereinfachtes Szenario, veranschaulicht jedoch das Konzept. Verfolgen Sie die betroffenen Schnittstellen zur Quelle des Loops. 

Zusammenfassung

Dieses Szenario demonstrierte die grundlegende Methodik für eine schnelle und präzise Fehlerbehebung von Layer-2-Schleifen. Die Methode kann in folgenden Schritten zusammengefasst werden:

1. Auf einem betroffenen Gerät überprüfen leere Zähler die Eingangsraten an den aktiven Schnittstellen auf ungewöhnlich hohe Werte. Berücksichtigen Sie die durchschnittliche Größe der eingehenden Pakete - eine kleinere durchschnittliche Größe bedeutet eine größere Menge an kleinen Paketen (z. B. ARPs oder DHCP-Broadcasts) -, und überprüfen Sie die Broadcast-/Multicast-Eingangszähler, um festzustellen, ob ein hoher Prozentsatz von Broadcast-/Multicast-Datenverkehr im Vergleich zum gesamten eingehenden Datenverkehr vorliegt. Diese Schnittstellen sind potenziell am Loop beteiligt.

ACCESS-C#show interfaces | in is up|input rate

2. Bestimmen Sie die Peer-Geräte, die mit den verdächtigen Schnittstellen verbunden sind. Der Loop ist nach einer dieser Schnittstellen angeordnet.  Mehrere Pfade weisen auf die Schleife hin, aber alle Pfade führen schließlich zur Quelle.

ACCESS-C#show cdp neighbors twentyFiveGigE 1/1/1

3. Einige Netzwerke verfügen über Geräte mit mehreren Weiterleitungspfaden. Überprüfen Sie Spanning-Tree, um sicherzustellen, dass die Topologie wie erwartet konvergiert wird. Stellen Sie sicher, dass blockierende Schnittstellen blockiert werden.

ACCESS-C#show spanning-tree

Integrieren Sie diese Schritte, und erstellen Sie eine Topologie, während Sie von Gerät zu Gerät wechseln. Man kommt schließlich an die Quelle der Schleife.

Die Schleife kann auftreten, wenn ein Faktor die erwartete Konvergenz von Spanning Tree verhindert. In diesem Szenario führte eine unidirektionale Verbindung dazu, dass ein Access Switch eine Verbindung weiterleitete, deren Blockierung erwartet wurde.

Broadcast-Stürme treten auch dann auf, wenn nicht autorisierte oder verdächtige Geräte den Datenverkehr in das Netzwerk zurückleiten oder reflektieren.

Die in diesem Dokument beschriebene Methode hilft Netzwerkexperten, die Quelle eines Layer-2-Loops oder eines Szenarios mit Datenverkehrsspiegelung schnell zu finden.

Schließlich - Warum nicht TCNs?

Eine gängige Praxis in diesem Bereich besteht darin, sich bei der Fehlerbehebung von Schleifen auf Spanning-Tree-TCNs zu konzentrieren und diese zu verfolgen. Dagegen empfehlen wir die Inputraten. Die Catalyst Switches der Serie 9000 umfassen eine robuste CoPP (Control-Plane Policing Policy), um Unterbrechungen des Datenverkehrs durch Interrupts aufgrund des Volumens an Interrupts zu verhindern. CoPP auf den Catalyst Switches der Serie 9000 steuert BPDUs, wenn das Volumen den Plattformrichtlinienwert überschreitet. Auch wenn also keine hohe CPU-Auslastung erkennbar ist, wird Spanning-Tree auf einem Catalyst 9000 zu Opfern. Andere Switch-Plattformen, darunter ältere Catalyst-Lösungen wie die 2960-, 3560-, 3750- und 4000-Serie, verwenden kein CoPP und können während eines Loops leicht überlastet werden. Jedes Gerät wird durch den Loop potenziell zum Opfer gefallen - dadurch ist Spanning Tree mit den Millionen von fehlerhaften Broadcasts auf dem CPU-Punt-Pfad konkurrenzfähig. Daher sind die generierten TCNs oft falsch-positiv und führen einen Techniker auf den falschen Weg.

Prävention und Best Practices

Catalyst Switches verfügen über optionale Funktionen zur Absicherung gegen Layer-2-Schleifen. Diese Funktionen und Best Practices sollen Schleifen verhindern, bevor sie auftreten, und ihre Auswirkungen mindern, falls sie auftreten.

Funktionen

RootGuard - Root Guard verhindert, dass Schnittstellen zu Root-Ports werden. Die Funktion versetzt die Schnittstelle in einen Root-Inconsistent-Status, wenn eine übergeordnete BPDU empfangen wird. Dies ist besonders nützlich, wenn das Netzwerk Verbindungen zu Geräten enthält, die von anderen Organisationen verwaltet werden. In der Regel wird dies auf die Downlinks des Distribution-Layers angewendet, die dem Access-Layer zugewandt sind. Überlegene BPDUs werden niemals vom Downstream eines stabilen Netzwerks erwartet.

LoopGuard - Im Allgemeinen empfangen Root-Ports und alternative Ports in STP BPDUs, während designierte Ports sie übertragen. Diese Beziehung kann dazu führen, dass Spanning Tree nicht auf unidirektionale Links reagieren kann. Loop Guard verhindert, dass alternative Ports oder Root-Ports zugewiesen werden. Loop Guard setzt die Schnittstelle in den Status "errr-disabled" (deaktiviert), wenn BPDUs nicht regelmäßig von der Schnittstelle empfangen und verarbeitet werden.

BPDUGuard: Diese Funktion setzt eine Schnittstelle in den Status "err-disable", wenn sie an einem konfigurierten Port eine BPDU empfängt. Konfigurieren Sie dies an Edge-Ports, an die sich kein anderes Netzwerkgerät anschließen soll. Diese Funktion wird häufig in Verbindung mit Portfast verwendet.

PortFast: PortFast wird an Edge-Ports verwendet - meist für den Zugriff, in einigen Szenarien aber auch für Trunks. Dadurch kann ein Edge-Port auf die normalen Phasen von Spanning Tree verzichten und direkt zur Weiterleitung wechseln. Dies spart Zeit aus der Perspektive des Endpunkts und verhindert, dass ein instabiler Edge-Port TCNs überträgt. Portfast muss immer zusammen mit BPDUGuard verwendet werden, um eine Schleife zu vermeiden, wenn ein Netzwerkgerät versehentlich angeschlossen wird.

Zusätzliche Best Practices

VLAN Scoping - Nur erforderliche VLANs auf Trunks zulassen. Dies schränkt den Umfang der Schleifen ein und verhindert, dass ein lokalisiertes Problem zu einem netzwerkweiten Ausfall wird. 

Nicht betriebsbereite VLANs als nativ verwenden - Als Best Practice empfiehlt es sich, ein nicht betriebsbereites VLAN für Trunks zu verwenden. In vielen Netzwerken wird das native Standard-VLAN (1) verwendet, das sich über das gesamte Netzwerk erstreckt. Verwenden Sie ein nicht betriebsbereites VLAN als natives VLAN, um den potenziellen Umfang eines Loops weiter einzuschränken.

Uniform Path Cost Calculation Method verwenden: Die Catalyst Switches der Serie 9000 führen standardmäßig ab IOS XE 17.6 die Long Path Cost Method aus. Frühere Versionen werden standardmäßig möglicherweise zu kurz ausgeführt. Die meisten älteren Catalyst-Switches sind standardmäßig knapp. In Umgebungen, in denen gemischte Pfadkostenmethoden zum Einsatz kommen, können Topologieänderungen und -störungen nur schwer umgesetzt werden. Stellen Sie sicher, dass auf allen Switches dasselbe Verfahren ausgeführt wird. Weitere Informationen finden Sie im entsprechenden Plattform-Konfigurationsleitfaden für Spanning Tree.

Verwenden Sie den Befehl "spanning-tree pathcost method <long/short>", um die Pfadkostenmethode zu ändern. "Show spanning-tree summary" wird verwendet, um die verwendete Methode zu bestätigen.

ACCESS-A(config)#spanning-tree pathcost method ?
  long   Use 32 bit based values for default port path costs
  short  Use 16 bit based values for default port path costs

ACCESS-A(config)#spanning-tree pathcost method long
<snip>
ACCESS-A#show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: VLAN0001
Extended system ID                      is enabled
Portfast Default                        is disabled
PortFast BPDU Guard Default            is disabled
Portfast BPDU Filter Default           is disabled
Loopguard Default                      is disabled
EtherChannel misconfig guard            is enabled
UplinkFast                              is disabled
BackboneFast                            is disabled
Configured Pathcost method used is long             <--- Displays the configured pathcost method.
<snip>

Zugehörige Informationen

Konfigurieren des Spanning Tree Protocol - Catalyst Switches der Serie 9300

Konfiguration optionaler Spanning-Tree-Funktionen - Catalyst Switches der Serie 9300

Konfiguration optionaler Spanning-Tree-Funktionen - Catalyst Switches der Serie 9600

Konfigurieren von Unidirectional Link Detection (UDLD) - Catalyst Switches der Serie 9300

Fehlerbehebung beim Betrieb der Kontrollebene auf Catalyst Switches der Serie 9000