Wie kann ich eine Überbrückungsschleife (Ethernet) diagnostizieren?


43

Angenommen, Spanning Tree ist fehlgeschlagen (oder Sie haben keinen Spanning Tree), und Sie erhalten eine Ethernet-Schleife. Wie kann das Problem am besten diagnostiziert werden?

Welcher Schalter? Welches Kabel? und so weiter.


Hat Ihnen eine Antwort geholfen? In diesem Fall sollten Sie die Antwort akzeptieren, damit die Frage nicht für immer auftaucht und nach einer Antwort sucht. Alternativ können Sie auch Ihre eigene Antwort eingeben und annehmen.
Ron Maupin

Antworten:


31

OK, nehmen Sie an, Sie haben eine Topologie wie:

          SW1
         /   \
        /     \
       /       \
PC A--SW2-----SW3--PC B

Aus irgendeinem Grund gibt es eine Überbrückungsschleife, STP ist deaktiviert oder jemand hat einen Filter an der falschen Stelle angewendet oder so.

PC A will mit PC B kommunizieren. Es werden zunächst ARPs für den MAC von PC B, das Ziel ist ein Broadcast mit MAC ffff.ffff.ffff. Der Frame geht also sowohl an SW1 als auch an SW3. Der SRC MAC ist PC A. SW1 überflutet dann den Rahmen in Richtung SW3 und SW3 überflutet den von SW2 zu SW1 kommenden Rahmen.

SW1 und SW3 haben den MAC von PC A gelernt, als der erste Frame eingegangen ist. Wenn der zweite Frame aus der entgegengesetzten Richtung eingegangen ist, muss er ihn neu lernen. Da diese Ereignisse so schnell und wiederholt auftreten, werden Protokollnachrichten angezeigt, die sich über das MAC-Flattern beschweren. So etwas wie "MAC FLAP 0000.0000.0001 flattert zwischen Gi0 / 24 und Gi0 / 23". Dies ist ein gutes Zeichen dafür, dass Sie eine Schleife haben.

Was Sie dann tun könnten, ist zu versuchen, diesen MAC zu verfolgen. Suchen Sie im ARP-Cache eines Geräts im selben Subnetz nach der IP-Adresse des Geräts. Also mit dem MAC könnten Sie versuchen, es mit sh mac-address-table oder mit der IP zu verfolgen, vielleicht haben Sie eine Liste mit allen IPs und wo sie verbunden sind.

Wenn der Host eine IP-Adresse von einem DHCP-Server erhält, können Sie dort auch versuchen, herauszufinden, woher der Host stammt. Wenn Sie Option 82 aktiviert haben, wäre das eine große Hilfe.

Andere Anzeichen sind, dass die CLI sehr träge sein wird. Die CPU-Auslastung ist sehr hoch. Switches machen fast alles in ASICs. Wenn ein Switch eine CPU-Auslastung von über 50% hat, ist das wahrscheinlich nicht gut. Sie sollten die SNMP-Überwachung implementieren und auf hohe CPU-Auslastung achten. Achten Sie auch auf die MAC-Klappenmeldungen. Wenn die Schalter eine Schleife haben, blinken die LEDs wahrscheinlich wie verrückt.

Dinge, die Sie tun können, um sich vor Schleifen zu schützen:

  • STP aktivieren! (duh)
  • SNMP-Überwachung der CPU-Auslastung
  • Aktivieren Sie SNMP-Traps für bestimmte Ereignisse, z. B. Änderungen der STP-Topologie
  • Aktivieren Sie die Sturmkontrolle an den Ports, um die Übertragung einzuschränken
  • Spannen Sie Ihre VLANs nicht zu stark in Ihre L2-Topologie ein
  • Aktivieren Sie die Port-Sicherheit und begrenzen Sie die Anzahl der MAC-Adressen pro Port
  • Aktivieren Sie Option82, wenn Sie DHCP ausführen

Ich muss sagen, dass mich das CPU-Lastelement ein bisschen überrascht. Ich habe das noch nie bei der Überbrückung von Loops gesehen, obwohl meine gesamte Erfahrung im Umgang mit ihnen auf ProCurve-Geräten beruht. Auf sie schien die CLI nie träge zu sein.
Paul Gear

Interessant. Vielleicht macht HP etwas anders als Cisco. Einige Dinge, die sich darauf auswirken könnten, wären die Geschwindigkeit der Schnittstellen, die an der Schleife beteiligt sind. Wenn es Unicast oder Broadcast ist. Ob der Switch eine SVI im VLAN hat oder nicht.
Daniel Dib

1
Ja - irgendwie komisch. Ich hätte gedacht, dass all diese Dinge (außer dem IP-Problem mit dem Switch) in Silikon sein würden ...
Paul Gear

Jetzt, wo ich darüber nachdenke, bin ich mir fast sicher, dass wir in einem betroffenen VLAN nie eine Switch-IP hatten. Alle Switch-to-Switch-Links auf dieser Site waren nicht mit einem Transit-VLAN versehen, auf dem keine Verwaltungs-IPs verzeichnet waren.
Paul Gear

22

Einer meiner Benutzer hat kürzlich einen Desktop-Switch von einem Schreibtisch ausgeliehen. Bei der Rücksendung des Switches steckten sie alle losen Ethernet-Anschlüsse in der Nähe ein. Eines dieser Kabel ging zum Netzwerk und ein anderes bestand aus zwei Enden desselben Kabels. Der Desktop-Switch wurde an das Netzwerk und auch an sich selbst angeschlossen. Der Switch hatte kein STP, sodass vom Netzwerk eingegangene Sendungen über das andere Kabel in beide Richtungen weitergeleitet wurden. Natürlich wird jedes Mal, wenn eine Sendung an den geschleiften Ports empfangen wurde, sie wieder in das Netzwerk repliziert. Es hat HSRP absolut verrückt gemacht und - aufgrund des schlechten Designs - auch zu Fehlern bei der OSPF-Adjazenz auf dem gesamten Campus geführt.

Der erste Hinweis auf das Problem war eine an meine E-Mail weitergeleitete Mac-Klappe. Dies führte uns sofort zum richtigen Schaltschrank. Von da an war es ein Prozess der Eliminierung, der auf Port-LEDs, Schnittstellen-pps und Protokollen basierte. Unnötig zu erwähnen, dass ich seitdem den gesamten Campus recherchiert habe. Die beste vorbeugende Maßnahme ist wahrscheinlich bpduguard. Ich habe das Feature seitdem implementiert und es war recht einfach. Das fehlerhafte Syslog in meine E-Mail zu bekommen, ist nichts weniger als Glückseligkeit.


3
Leider sind MAC Flaps-Protokollnachrichten unbrauchbar, wenn Sie über WIFI-Zugangspunkte verfügen, die mit verschiedenen Switches verbunden sind, da Benutzer, die von einem AP zum nächsten wechseln, eine solche Nachricht verursachen. BPDU Guard (oder ähnliche Mechanismen) ist ein MUSS für Zugangsschalter. Wenn Sie faul sind, können Sie auch die "errdisable recovery cause bpduguard" -Anweisung setzen, die dazu führt, dass in error-disable gesetzte Ports nach 5 Minuten automatisch in den Weiterleitungsstatus versetzt werden, sodass der Port in config nach dem Trennen nicht zurückgesetzt werden muss das beleidigende Kabel
Remi Letourneau

1
> Von da an war es ein Eliminierungsprozess basierend auf Port-LEDs ... Ahh, Das Blinkenlichten.
Arthur Kay

11

Bei den meisten Geräten schießt die CPU zu 100% und Sie können nur die redundanten physischen Verbindungen trennen. Sobald sich die CPU beruhigt hat, können Sie die Links nacheinander wieder einstecken und sehen, welcher die Schleife erneut auslöst.

Bei einem großen Chassis (wie einem 6500) musste ich alle Klingen herausziehen und nacheinander wieder einstecken. Sobald ich herausgefunden hatte, welches Blade ich verwendet hatte, musste ich alle einzelnen Links (16 GBICs) herausziehen und auch einzeln wieder einsetzen. Niemals Spaß.

Einige modernere Geräte verfügen über eine geschützte CPU, die den Umgang damit erleichtern soll - Sie können weiterhin mit der Box interagieren. An diesem Punkt wird das Betrachten von Verkehrszählern und dergleichen, um die fehlerhafte Verbindung zu bestimmen, möglich.


11

Ich habe vor kurzem bei einem Unternehmen angefangen, bei dem Broadcast-Limits für jeden Port verwendet werden. Wenn ein Port mehr als 5% seiner Kapazität als Broadcast überträgt, versetzt der Switch ihn in den Status ERRDISABLE.

 storm-control broadcast level 5.00  
 storm-control action shutdown

Dies hat Leben gerettet, wenn eine Gruppe Geräte an das LAN anschließt, die die drahtlosen Netzwerke überbrücken.

Obwohl für Ihre eigentliche Frage, ich habe es immer als manuell befunden.


9

für iOS:

Sie werden wahrscheinlich MAC-Adressen zwischen den Ports haben. Suchen Sie nach MAC_MOVE_NOTIFICATION(oder ähnlichen) Fehlern in:

sh logg

So finden Sie den Hafen:

sh int g0/1 controller

Suche nach Ungewöhnlichen Multicastund BroadcastZahlen. Kollisionen sind ein schlechtes Zeichen.

Zu guter Letzt können Sie sich nicht einloggen, da die CPU pwned ist :)

sh proc cpu

Wie läuft der Wechsel hier? Wenn es sich nur um einen L2-Switch handelt, möchten Sie keine höheren Werte als ~ 10%.


9

In dem Fall, dass Sie einen nicht verwalteten oder nicht verwalteten Switch haben (fehlende Anmeldedaten oder Kenntnisse des Switch-Betriebssystems usw.), Switches und eine Bridge-Schleife, beschreibe ich, wie ich die Schleife manuell finden würde. Hiermit wird auch der fundamentale Grund der ursprünglichen Frage "Sie haben kein STP" angesprochen.

Der grundlegende Algorithmus zur Fehlerlokalisierung dieser Schleife ähnelt STP, mit der Ausnahme, dass Sie nicht ohne weiteres Zugriff auf das Senden von BPDUs mit Port-IDs haben.

  • Schließen Sie zunächst ein paketauswurf- / schnüffelfähiges Gerät an einen Port in einem der Switches an. Dieses Gerät ist jetzt das Root-Gerät Ihres Baums.
    • Wenn Sie Fehler an mehreren Orten lokalisieren müssen, z. B. über einen "Campus" oder Ähnliches, können Sie sich remote mit einem tragbaren SSH-Client bei der Packet-Dumping-Maschine anmelden.
      • Ich persönlich würde meinen Linux-Laptop mit einer Internetverbindung mit tcpdump auf einem Bildschirm verwenden und von beispielsweise einem iPad oder einem Telefon darauf zugreifen.
    • Wenn Sie sich nicht aus der Ferne anmelden können, können Sie den tcpdump, der wahrscheinlich mit Verbindungsgeschwindigkeit überflutet wird, mithilfe eines Freundes visuell überwachen. So können Sie einen Unterschied leicht feststellen, wenn der Pfad zum Loop-Quellgerät getrennt wird.
  • Als Nächstes müssen Sie im Wesentlichen einen Baum neu erstellen, beginnend mit Ihrem Root-Switch.
    1. Und da Sie das Szenario haben können, in dem mehrere Loop-Links in Ihr Root-Gerät eingespeist werden, müssen Sie zunächst alle verbundenen Ports gleichzeitig entfernen.
    2. Schließen Sie die Ports nacheinander wieder an. Wenn der Paketburst zu einem beliebigen Zeitpunkt erneut angezeigt wird, folgen Sie diesem Port zum verbundenen Switch am anderen Ende.
    3. Wiederholen Sie Schritt 1, bis Sie den / die geschleiften Anschluss (e) gefunden haben und nicht weiter unten in Ihrer manuellen Struktur iterieren können.
    4. Nachdem Sie die Schleifensituation in diesem Switch behoben haben, kehren Sie zum obigen Switch in der Baumstruktur zurück und setzen Sie Schritt 2 fort. Diese Rekursion wird bis zum erneuten Anschließen des letzten Kabels in Ihrem Root-Switch fortgesetzt.

Dies ist eine vollständig ausführliche manuelle Suche nach geschleiften Ports.

Normalerweise gibt es nur ein Paar geschleifter Ports. Dies bedeutet, dass eine umfassende und sichere Suche nicht erforderlich ist, bei der zuerst alle verbundenen (Link-) Ports entfernt und dann einzeln neu verbunden werden. Wenn nur ein Portpaar im "Baum" durchgeschleift ist, können Sie es finden, indem Sie einfach jeweils einen Port trennen.

Trotzdem wird die allgemeine "schmutzabweisende" Methode oder der Algorithmus zu dem, was ich oben beschrieben habe.


7

Autsch. Aber ok, ich kann mir zwei Möglichkeiten vorstellen, wie ich das angehen würde ...

Augapfel: Wenn die Switches Port-Anzeigen haben, sollten Sie in der Lage sein, die Ports zu beobachten, die am aktivsten sind. Das sind diejenigen, die zuerst anfangen zu suchen. Hoffentlich sind die Kabel beschriftet, damit Sie auf zwei Switches mit demselben Kabel nach dem Ergebnis suchen können, dass zwei Ports belegt sind.

SNMP-Überwachung: Wenn Sie über SNMP-Nutzungsstatistiken (oder ähnliche) verfügen, suchen Sie nach dem am stärksten ausgelasteten Switch und den am stärksten ausgelasteten Ports. Dann schauen Sie sich die Kabel an.

... Wenn Sie nicht beschriftete Kabel haben, beginnen Sie mit dem Aufspüren und Beschriften, um die am stärksten frequentierten Ports zu überprüfen.


2
Ein SNMP-Trap ist besser als eine SNMP-Abfrage, die normalerweise nur alle 300 Sekunden durchgeführt wird. Ein Hochwasser und eine anschließende Kernschmelze können so schnell eintreten, dass SNMP keine Überwachung durchführt. Die SNMP-Monitore, die keine Daten von Switches zurückerhalten, die nicht mithalten können, können jedoch einen Ausgangspunkt darstellen.
generalnetworkerror

3

Ich beantworte diese Frage auf der Grundlage des Verständnisses, dass für die betreffende Layer-2-Domäne ein vollständiger Ausfall vorliegt und Sie keinen Verwaltungszugriff haben, da alle CPUs gebunden sind.

Die beste Möglichkeit zur Fehlerbehebung bei einer Überbrückungsschleife besteht darin, die Uplinks zu entfernen, bis sie verschwunden sind. Angenommen, Sie haben eine Standard-Switched-Access-Schicht, bei der alle Access-Switches zu einem Paar von Distributions-Switches verbunden sind. Gehen Sie zum ersten Zugriffsschalter und entfernen Sie die Uplinks. Wenn die LEDs für die Switchports nicht mehr funktionieren, stecken Sie sie wieder ein und wechseln Sie zum nächsten. Wiederholen Sie diesen Vorgang, bis Sie zu einem Schalter gelangen, an dem Sie die Uplinks entfernt haben und die LEDs weiterhin schnell blinken. Dies ist Ihr Schalter mit der Schleife.

Beginnen Sie nun mit dem Trennen der Anschlüsse des Endbenutzers, bis sich die LED-Anzeigen beruhigt haben. Wenn dies der Fall ist, war der problematische Anschluss der letzte, an dem Sie den Stecker gezogen haben. Verfolgen Sie das Kabel und verurteilen Sie den Benutzer entsprechend.


2

Um ehrlich zu sein, wenn Sie eine Remote-Verbindung (oder ein Konsolenkabel) mit dem Gerät herstellen, werden Sie feststellen, dass es sehr träge ist. Es wird eine Verzögerung von der Eingabe bis zu den Buchstaben auf der CLI geben.

Wenn es sich um einen Cisco-Switch handelt, zwei einfache, um die Schnittstellenstatistiken zu überprüfen, wird er ständig zu 100% (oder 255/255) genutzt. In meinen Jahren mit Switches habe ich noch nicht gesehen, dass ein Port zu 100% ausgelastet ist. Überprüfen Sie außerdem die CPU-Auslastung (normalerweise "Prozess-CPU-Verlauf anzeigen"). Durchgeschleifte Schnittstellen treffen Ihre CPU normalerweise ziemlich stark, es sei denn, Sie verwenden einen High-End-Switch.

STP sollte aber wirklich aktiviert sein!


2

Ich hatte dieses Problem in einem Netzwerk am anderen Ende der USA und musste einigen Level-1-Analysten über das Telefon und meinen WAN-Link zu ihrer Site aus der Ferne helfen. Das Problem wurde durch die Tatsache weiter erschwert, dass sie mehrere Switch-Marken hatten, die sie im Laufe der Jahre langsam zum Netzwerk hinzugefügt hatten. Als sie das Büro verlegten, markierten sie, wo jeder Port hinging, befestigten alles genau so wie im neuen Büro und starteten alles. Es erübrigt sich zu erwähnen, dass die Handvoll Switches, auf denen Spanning Tree funktionierte, nicht auf die gleiche Weise konvergierten und alle Arten von Schleifen und Problemen aufwiesen. Als ich fertig war, stellte sich heraus, dass nicht weniger als drei nicht verwaltete Switches in Schleifen mit dem Rest der Infrastruktur verbunden waren.

Ich konnte jeden der nicht verwalteten Switches mithilfe eines Tools namens nedi aufspüren (auf den Switches, die verwaltet werden konnten, habe ich lldp / cdp aktiviert). Ich habe zuerst Karten mit nedi erstellt. Dann ließ ich in Gebieten, in denen die Karte Verbindungen von einem Switch zu einem anderen und dann wieder zurück zu demselben Switch zeigte, den Netzwerktechniker vor Ort die Leitung manuell verfolgen. Entweder habe ich die an der Schleife beteiligten Schnittstellen manuell heruntergefahren oder die Person vor Ort hatte Kabel abgezogen. Am Ende war ich in der Lage, das Netzwerk trotz aller verrückten Markenwechsel zum Laufen zu bringen.


1

Eine Sache, die hier gemacht werden kann, ist zu sehen, welche Maschinen mit den Befehlen show cdp neighboroder mit dem Switch verbunden sind show lldp neighbor.

Wenn der BPDU-Guard-Befehl nicht verwendet wird und jemand einen Rogue-Switch mit niedrigerer Priorität (oder einer älteren Mac-Adresse) anschließt, handelt das neue Gerät als Spanning Tree-Root aus, was mit Sicherheit ein Problem verursacht.


0

Nach meiner Erfahrung war es immer das Kabel, das ich gerade eingesteckt oder nicht geschlossen oder dem Port-Kanal hinzugefügt habe. Härter ist es, wenn jemand anderes es getan hat und nicht sofort nachgibt.


0

Das Bestimmen einer Schleife hängt wirklich von der Marke des Switch ab, den Sie haben. Auf einem Extreme-Switch kann ich beispielsweise elrp-client in einem VLAN ausführen, und der Switch sendet grundsätzlich einen Broadcast-Frame an alle Ports für dieses VLAN und überprüft, ob er von einem dieser Ports zurückgegeben wird. Wenn ja, teilt er mir mit, welcher Port (s), an denen der Frame wieder empfangen wurde, wodurch die Loop-Kandidaten angezeigt werden.

Auf einem Cisco können Sie die Sturmkontrolle aktivieren, die eher ein stumpfes Instrument ist, da sie den Port im Grunde genommen für eine gewisse Zeit blockiert, bis der Status gelöscht wird (oder Sie den Status "Errdisable" löschen) - im Allgemeinen jedoch auf diese Weise of thing ist nur relevant, wenn Sie Cisco-Switches in einer gemischten Topologie von Geräten verwenden, die weder Spanning Tree- noch Forward-BPDUs ausführen.


0

Ohne Zweifel ist der schnellste Ansatz, den ich gefunden habe, die Überwachung der Paket / Sek-Raten von Schnittstellen. Eine Kurzübersicht der Schnittstellen mit dem entsprechenden CLI-Filter listet jede Schnittstelle und die Paket- / Sek.-Rate auf. Um die Quelle der Schleife zu finden, suchen Sie nach der einzigen Schnittstelle mit einer verrückten hohen INPUT-Rate von Paketen pro Sekunde. In einer typischen Unternehmensumgebung mit typischen Auslastungsprofilen funktioniert dies jederzeit ohne Fehler. Bei einem 6500 mit vielen Schnittstellen dauert es nicht lange, die Quelle zu erkennen ...


0

Während einer Schleife kann bei einer großen Anzahl von Broadcast-Verkehr (z. B. ARP-Anforderung) an der Endstation auch die Belastung der CPU zunehmen (z. B. wenn Sie eine billige 100-Mbit / s-Realtek-Karte verwenden, die eine Prüfsumme für die CPU berechnet). Da es physikalisch möglich ist, eine Schleife zu finden, wenn das Kabel abgezogen wird, geht die Verbindung sofort an 2 Ports verloren.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.