In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie das Unidirectional Link Detection (UDLD)-Protokoll dazu beitragen kann, Schleifen und Datenverkehrsanomalien in Switched-Netzwerken zu verhindern.
Es gibt keine spezifischen Anforderungen für dieses Dokument.
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.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Das Spanning Tree Protocol (STP) löst redundante physische Topologie in eine schleifenfreie, baumartige Vorwärtstopologie auf.
Zu diesem Zweck werden ein oder mehrere Ports blockiert. Wenn ein oder mehrere Ports blockiert sind, gibt es keine Schleifen in der Vorwärtstopologie. STP ist auf den Empfang und die Übertragung von Bridge Protocol Data Units (BPDUs) angewiesen. Wenn der STP-Prozess, der auf dem Switch mit blockierendem Port ausgeführt wird, keine BPDUs von seinem Upstream-Switch (designierten Switch) empfängt, altert STP die STP-Informationen für den Port schließlich und verschiebt sie in den Weiterleitungsstatus.
Dadurch kann eine STP-Schleife entstehen, in der Pakete unbegrenzt entlang des Schleifenpfads zyklisch verarbeitet werden und mehr Bandbreite und Ressourcen verbrauchen. Dies führt zu einem möglichen Netzwerkausfall.
Wie ist es möglich, dass der Switch keine BPDUs empfängt, während der Port aktiv ist? Der Grund dafür ist eine unidirektionale Verbindung.
Eine Verbindung gilt als unidirektional, wenn Folgendes auftritt:
Die Verbindung ist auf beiden Seiten der Verbindung aktiv.
Die lokale Seite empfängt die von der Remote-Seite gesendeten Pakete nicht, während die Remote-Seite die von der lokalen Seite gesendeten Pakete empfängt.
Betrachten wir dieses Szenario. Die Pfeile zeigen den Fluss von STP-BPDUs an.
Im Normalbetrieb ist Bridge B ein designierter Port an der Verbindung B-C. Bridge B sendet BPDUs nach unten an C, wodurch der Port blockiert wird. Der Port wird blockiert, während C BPDUs von B für diese Verbindung erkennt.
Nun überlegen Sie, was passiert, wenn die Verbindung B-C in Richtung C ausfällt. C hört auf, Datenverkehr von B zu empfangen, aber B empfängt weiterhin Datenverkehr von C.
aufstehen
C empfängt keine BPDUs für die Verbindung B-C und altert die mit der letzten BPDU empfangenen Informationen. Dies dauert bis zu 20 Sekunden, abhängig vom maxAge STP-Timer. Sobald die STP-Informationen auf dem Port veraltet sind, wechselt dieser Port vom blockierenden in den überwachenden, lernenden und schließlich in den weiterleitenden STP-Status. Dadurch wird eine Schleife erzeugt, da im Dreieck A-B-C kein blockierter Port vorhanden ist. Pakete laufen entlang des Pfads (B empfängt weiterhin Pakete von C), was zusätzliche Bandbreite verbraucht, bis die Links vollständig gefüllt sind.
In diesem Szenario kann es zu einem Netzwerkausfall kommen. Ein weiteres mögliches Problem, das durch eine unidirektionale Verbindung verursacht werden kann, ist ein schwarzes Loch im Datenverkehr.
UDLD ist ein Layer-2-Protokoll (L2), das mit den Layer-1-Mechanismen (L1) zusammenarbeitet, um den physischen Status einer Verbindung zu bestimmen. Auf Layer 1 übernimmt die automatische Aushandlung die physische Signalisierung und Fehlererkennung. UDLD führt Aufgaben aus, die die automatische Aushandlung nicht ausführen kann, wie die Erkennung der Identitäten von Nachbarn und das Herunterfahren falsch angeschlossener Ports. Wenn Sie sowohl Auto-Negotiation als auch UDLD aktivieren, werden Erkennungen auf Layer 1 und Layer 2 eingesetzt, um physische und logische unidirektionale Verbindungen und andere Protokollfehler zu verhindern.
UDLD ermöglicht den Austausch von Protokollpaketen zwischen benachbarten Geräten. Damit UDLD funktioniert, müssen beide Geräte an der Verbindung UDLD unterstützen und es an den jeweiligen Ports aktiviert haben.
Jeder für UDLD konfigurierte Switch-Port sendet UDLD-Protokollpakete, die die Port-Geräte-/Port-ID und die von UDLD auf diesem Port erkannten Geräte-/Port-IDs der Nachbarn enthalten. Benachbarte Ports sehen ihre eigene Geräte-/Port-ID (Echo) in den von der anderen Seite empfangenen Paketen. Wenn der Port seine eigene Geräte-/Port-ID in den eingehenden UDLD-Paketen für einen bestimmten Zeitraum nicht sieht, wird die Verbindung als unidirektional angesehen.
Dieser Echo-Algorithmus ermöglicht die Erkennung folgender Probleme:
Die Verbindung ist auf beiden Seiten aktiv, Pakete werden jedoch nur von einer Seite empfangen.
Fehler bei der Verbindung (Verdrahtung), wenn Empfangs- und Übertragungskabel nicht am gleichen Port der Gegenstelle angeschlossen sind.
Sobald die unidirektionale Verbindung von UDLD erkannt wurde, wird der entsprechende Port deaktiviert und die folgende Meldung auf der Konsole ausgegeben:
UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabled
Das Port-Shutdown durch UDLD bleibt deaktiviert, bis es manuell aktiviert wird oder bis "untilerrdisabletimeout" abläuft (falls konfiguriert).
UDLD kann in zwei Modi betrieben werden: normal und aggressiv: .
Eine "Age out" (Alter) der UDLD-Informationen tritt auf, wenn der Port, auf dem UDLD ausgeführt wird, während der Haltezeit keine UDLD-Pakete vom benachbarten Port empfängt. Die Haltezeit für den Port wird vom Remote-Port vorgegeben und hängt vom Nachrichtenintervall auf der Remote-Seite ab. Je kürzer das Nachrichtenintervall, desto kürzer die Haltezeit und desto schneller wird die Erkennung. Kürzlich durchgeführte UDLD-Implementierungen ermöglichen die Konfiguration des Nachrichtenintervalls. UDLD-Informationen können aufgrund der hohen Fehlerrate am Port, die durch ein physisches Problem oder Duplexungleichheit verursacht wird, veraltet sein. Ein solcher Paketverlust bedeutet nicht, dass die Verbindung unidirektional ist und dass UDLD im normalen Modus diese Verbindung nicht deaktiviert.
Es ist wichtig, das richtige Nachrichtenintervall auswählen zu können, um eine korrekte Erkennungszeit zu gewährleisten. Das Nachrichtenintervall muss schnell genug sein, um die unidirektionale Verbindung zu erkennen, bevor die Vorwärtsschleife erstellt wird. Die Switch-CPU darf dabei jedoch nicht überlastet werden. Das Standard-Nachrichtenintervall beträgt 15 Sekunden und ist schnell genug, um die unidirektionale Verbindung zu erkennen, bevor die Vorwärtsschleife mit STP-Standard-Timern erstellt wird. Die Erkennungszeit entspricht ungefähr dem Dreifachen des Nachrichtenintervalls.
Beispiel: Tdetection~ message_interval x3
Dies sind 45 Sekunden für das Standard-Nachrichtenintervall von 15 Sekunden.
Treconvergence=max_age + 2x forward_delay erfordert die Wiederherstellung der STP-Konvergenz bei Ausfall einer unidirektionalen Verbindung. Bei den Standard-Timern dauert es 20+2x15=50 Sekunden.
Es wird empfohlen, Tdetection< Treconvergence beizubehalten und ein geeignetes Nachrichtenintervall auszuwählen.
Im aggressiven Modus versucht UDLD nach dem Veralten der Informationen, den Verbindungsstatus wiederherzustellen und Pakete jede Sekunde für acht Sekunden zu senden. Wenn der Verbindungsstatus immer noch nicht ermittelt wurde, wird die Verbindung deaktiviert.
Aggressivemode fügt zusätzliche Erkennung dieser Situationen hinzu:
Der Port ist blockiert (auf einer Seite wird der Link weder gesendet noch empfangen, jedoch ist er auf beiden Seiten aktiv).
Die Verbindung ist auf der einen Seite hoch und auf der anderen Seite runter. Dieses Problem tritt an Glasfaser-Ports auf, wenn die Glasfaserübertragung am lokalen Port getrennt wird und die Verbindung auf der lokalen Seite aktiv bleibt. Sie befindet sich jedoch auf der Remote-Seite nach unten.
In letzter Zeit verfügen Glasfaser-FastEthernet-Hardware-Implementierungen über Far End Fault Indication (FEFI)-Funktionen, um in solchen Situationen die Verbindung auf beiden Seiten herunter zu bringen. Bei GigabitEthernet wird eine ähnliche Funktion durch die Link-Aushandlung bereitgestellt. Kupferports sind normalerweise nicht anfällig für diese Art von Problem, da sie Ethernet-Verbindungspulse verwenden, um die Verbindung zu überwachen. Es ist wichtig zu erwähnen, dass in beiden Fällen kein Forward-Loop auftritt, da keine Verbindung zwischen den Ports besteht. Steht die Verbindung jedoch auf der einen Seite nach oben und auf der anderen Seite nach unten, kann es zu einem Blackhole-Problem kommen. Aggressive UDLD wurde entwickelt, um dies zu verhindern.
UDLD ist im normalen und aggressiven Modus ab Version 12 der Cisco IOS® Software verfügbar.
Führen Sie den Befehl show udld aus, um zu überprüfen, ob UDLD auf den Schnittstellen aktiviert ist:
Switch#show udld
Interface Gi1/0/1
---
Port enable administrative configuration setting: Disabled
Port enable operational state: Disabled
Current bidirectional state: Unknown
Interface Gi1/0/2
---
Port enable administrative configuration setting: Disabled
Port enable operational state: Disabled
Current bidirectional state: Unknown
Interface Gi1/0/3
---
Port enable administrative configuration setting: Disabled
Port enable operational state: Disabled
Current bidirectional state: Unknown
Aggressive UDLD kann an der Schnittstelle mit dem udld port aggressive
command:
Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#interface gigabitEthernet1/0/1
Switch(config-if)#udld port aggressive
Switch(config-if)#end
Switch#
Stellen Sie dieshow udld
und show udld neighbors
-Befehl, um zu überprüfen, ob UDLD auf dem Port aktiviert oder deaktiviert ist, und um festzustellen, welcher Link- und Nachbarstatus vorliegt:
Switch#show udld GigabitEthernet1/0/1
Interface Gi1/0/1
---
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15000 ms
Time out interval: 5000 ms
Port fast-hello configuration setting: Disabled
Port fast-hello interval: 0 ms
Port fast-hello operational state: Disabled
Neighbor fast-hello configuration setting: Disabled
Neighbor fast-hello interval: Unknown
Entry 1
---
Expiration time: 31600 ms
Cache Device index: 1
Current neighbor state: Bidirectional
Device ID: 346288238580
Port ID: Gi4/0/1
Neighbor echo 1 device: 70B4F35F080
Neighbor echo 1 port: Gi1/0/1
TLV Message interval: 15 sec
No TLV fast-hello interval
TLV Time out interval: 5
TLV CDP Device name: MXC.TAC.M.02-3850-01Switch#show udld neighbors
Port Device Name Device ID Port ID Neighbor State
---- ----------- --------- ------- --------------
Gi1/0/1 346288238580 1 Gi4/0/1 Bidirectional
Total number of bidirectional entries displayed: 1
Verwenden Sie udld message time
Befehl, um das Nachrichtenintervall zu ändern:
Switch(config)#udld message time 10 UDLD message interval set to 10 seconds
Das Intervall kann zwischen 1 und 90 Sekunden liegen, wobei der Standardwert 15 Sekunden beträgt.
Informationen zu Catalyst 3560-Switches finden Sie unter Configuring UDLD.
Informationen zu Catalyst 4500/4000, auf denen Cisco IOS ausgeführt wird, finden Sie unter Configuring UDLD (Konfigurieren von UDLD).
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
20-Jul-2022 |
Erstveröffentlichung |