Konfigurieren der UDLD-Protokollfunktion

Einleitung

In diesem Dokument wird beschrieben, wie das Unidirectional Link Detection-Protokoll (UDLD-Protokoll) helfen kann, Schleifen und Anomalien beim Datenverkehr in Switch-Netzwerken zu verhindern.

---

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

---

Verwendete Komponenten

In diesem Dokument wird der allgemeine UDLD-Vorgang beschrieben. Die Konfigurations- und Verifizierungsbeispiele in diesem Dokument wurden für Cisco Catalyst Switches der Serie 9300 mit der Cisco IOS XE Version 17.x validiert.

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.

---

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

---

Problemdefinition

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 ein Port im STP-Blockierungs- oder -Verwerfungsstatus den Empfang von BPDUs von der designierten Bridge beendet, altert STP die mit diesem Port verknüpften Informationen schließlich und verschiebt sie in einen 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? Dies ist auf eine unidirektionale Verbindung zurückzuführen.

---

Eine Verbindung gilt als unidirektional, wenn:

• Die Verbindung ist auf beiden Seiten der Verbindung aktiv.

• Die lokale Seite empfängt keine von der Remote-Seite gesendeten Pakete, während die Remote-Seite von der lokalen Seite gesendete Pakete empfängt.

Im nächsten Szenario zeigen die Pfeile den Fluss von STP-BPDUs an:

---

STP-Portstatus-Topologie

---

Während des in dieser Topologie gezeigten Zustands ist die Schnittstelle an Switch B in Richtung Switch C der designierte Port für das B-C-Segment und überträgt BPDUs an Switch C. Die Schnittstelle an Switch C in Richtung Switch B ist ein nicht designierter Port im klassischen IEEE 802.1D STP. Oder ein alternativer Port im RSTP, der im Blockierungs-/Verwerfungsstatus verbleibt, während er BPDUs von Switch B empfängt und verarbeitet. Obwohl sich die Schnittstelle an Switch C im Blockierungs- oder Verwerfungsstatus befindet, empfängt und verarbeitet der Port weiterhin BPDUs. Diese Zustände verhindern, dass der Port Daten-Frames weiterleitet, verhindern jedoch nicht, dass er BPDUs empfängt.

---

Überlegen Sie, was passiert, wenn die B-C-Verbindung unidirektional wird und die B → C-Richtung fehlschlägt. Switch C kann keine BPDUs mehr von Switch B empfangen, während Switch B BPDUs empfangen kann, die von Switch C übertragen wurden. Switch C speichert die von der letzten BPDU empfangenen Informationen, bis diese Informationen veraltet sind. Bei einem klassischen IEEE 802.1D STP und dem standardmäßigen Max Age von 20 Sekunden kann dies bis zu 20 Sekunden dauern. Sobald die STP-Informationen veraltet sind, berücksichtigt Switch C Switch B in diesem Segment nicht mehr als überlegen, und der Port kann von Blockierung zu Listening, dann zu Lernen und schließlich zu Weiterleitung wechseln.

---

Dadurch wird eine Layer-2-Weiterleitungsschleife erstellt, da im Dreieck A-B-C kein blockierter Port mehr vorhanden ist. Broadcast-, Unicast- und Multicast-Frames können wiederholt um den Loop zirkulieren und dabei Bandbreite, CPU und möglicherweise einen Broadcast-Sturm verursachen.

Dieses Szenario kann zu einem Netzwerkausfall führen. Dies ist ein weiteres mögliches Problem, das durch eine unidirektionale Verbindung wie ein schwarzes Loch im Datenverkehr verursacht wird.

---

STP-BPDU-Fluss

---

Funktionsweise des Unidirectional Link Detection Protocol

UDLD ist ein Layer-2-Protokoll, das die Mechanismen zur Erkennung von Layer-1-Verbindungen ergänzt, indem unidirektionale Kommunikation und spezifische Verkabelungsinkonsistenzen zwischen direkt verbundenen Geräten identifiziert werden.

---

Auf Layer 1 löst die automatische Aushandlung die physische Signalisierung und Fehlererkennung auf. UDLD führt Aufgaben aus, die die automatische Aushandlung nicht durchführen kann, wie z. B. das Erkennen von Nachbaridentitäten und das Herunterfahren falsch angeschlossener Ports. Bei Aktivierung von Auto-Negotiation und UDLD; Erkennungen auf Layer 1 und Layer 2 arbeiten zusammen, um physische und logische unidirektionale Verbindungen und die Fehlfunktion anderer Protokolle zu verhindern.

UDLD ermöglicht den Austausch von Protokollpaketen zwischen benachbarten Geräten. Um eine bidirektionale UDLD-Nachbarbeziehung herzustellen, müssen beide direkt verbundenen Geräte UDLD unterstützen und es auf den verbundenen Schnittstellen aktiviert haben. Überprüfen Sie den bidirektionalen Status auf beiden Geräten.

---

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 UDLD eine unidirektionale Bedingung erkennt, setzt es die lokale Erkennungsschnittstelle in den Status err-disable. Der Status der Remote-Schnittstelle hängt von der Remote-UDLD-Erkennung und dem Verhalten der physischen Verbindung ab. Eine ähnliche Meldung wird auf der Konsole ausgegeben:

UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabled

---

Eine von UDLD deaktivierte Schnittstelle bleibt im Status "err-disable", bis sie manuell wiederhergestellt wird oder ein aktivierter Timer für die Wiederherstellung "errdisable" abläuft. Korrigieren Sie Glasfaser-, Transceiver-, Verkabelungs- oder Remote-Schnittstellenfehler vor der Wiederherstellung. Verwenden Sie shutdown und kein shutdown für die manuelle Wiederherstellung. Auf Plattformen, die dies unterstützen, setzt udld reset Schnittstellen zurück, die von UDLD deaktiviert wurden bzw. heruntergefahren wurden. Führen Sie nach der Wiederherstellung die Befehle show interfaces status err-disabled, show udld <interface-id> und show udld neighbors aus, um zu bestätigen, dass die Schnittstelle betriebsbereit und die UDLD-Beziehung bidirektional ist. Überprüfen Sie die Systemprotokolle, um sicherzustellen, dass der Fehler nicht erneut auftritt.

---

UDLD-Betriebsmodi

UDLD kann in zwei Modi betrieben werden: Normal und aggressiv:

---

Normaler Modus

Wenn UDLD auf einer unterstützten Schnittstelle aktiviert ist, ist der Normalmodus der Standardbetriebsmodus, es sei denn, der aggressive Modus ist explizit konfiguriert. UDLD verwendet Layer-1-Mechanismen wie die automatische Aushandlung, um einen Link zu validieren. Layer-1-Mechanismen erkennen physische Signalisierungs- und Verbindungsfehler, während UDLD benachbarte Geräte identifiziert und Glasfaserstränge verifiziert, die mit den richtigen Ports verbunden sind.

Im normalen Modus erkennt UDLD eine unidirektionale Bedingung, wenn Glasfaserstränge zwischen den Ports falsch angeschlossen sind und Layer-1-Mechanismen den Verkabelungsfehler nicht erkennen. Wenn die Glasfaserstränge mit den richtigen Ports verbunden sind, der Datenverkehr jedoch nur in eine Richtung fließt, markiert der UDLD-Normalmodus die logische Verbindung als unbestimmt und deaktiviert den Port nicht. Dieses Verhalten beruht auf Layer-1-Mechanismen zur Erkennung des physischen Ausfalls. Wenn ein Glasfaserstrang getrennt wird und die automatische Aushandlung den physischen Fehler erkennt, bleibt die Verbindung nicht aktiv. UDLD führt keine Abschaltaktion aus, da Layer 1 das Problem bereits erkannt hat und der Status der logischen UDLD-Verbindung unbestimmt ist.

---

Aggressive-Modus

Der aggressive Modus umfasst die Erkennungsfunktionen des normalen Modus und bietet zusätzlichen Schutz für Point-to-Point-Glasfaserverbindungen und Twisted-Pair-Verbindungen. Es erkennt falsch verbundene Glasfaserstränge und Bedingungen, unter denen ein Endpunkt keinen Datenverkehr senden oder empfangen kann, ein Port aktiv bleibt, der andere inaktiv ist oder ein Glasfaserstrang unterbrochen wird.

---

UDLD-Hello-Pakete dienen als Heartbeat für die Point-to-Point-Verbindung. Wenn UDLD den Empfang dieser Pakete beendet, nachdem die Verbindung in eine bidirektionale Richtung hergestellt wurde, versucht der aggressive Modus, die bidirektionale Beziehung wiederherzustellen. Wenn UDLD die Beziehung nicht wiederherstellen kann, wird der betroffene lokale Port deaktiviert, um die weitere Verwendung einer Verbindung zu verhindern, deren bidirektionaler Betrieb nicht überprüft werden kann.

Wenn beide Glasfaserstränge für Layer 1 betriebsbereit zu sein scheinen, überprüft das aggressive UDLD, ob sie mit den richtigen benachbarten Ports verbunden sind und ob der Datenverkehr zwischen den erwarteten Nachbarn in beide Richtungen fließt. Die automatische Aushandlung kann diese Überprüfung der Nachbarn- und Portidentität nicht durchführen, da sie auf Layer 1 ausgeführt wird.

---

UDLD-Nachrichten- und Hold-Timer

UDLD-Informationen verstreichen, wenn ein Port, auf dem UDLD ausgeführt wird, während der Haltezeit keine UDLD-Pakete vom benachbarten Port empfängt. Diese Timer gelten für die Wartung von UDLD-Nachbarinformationen im normalen und im aggressiven Modus. Die Aktion nach dem Ablauf hängt vom konfigurierten Modus und der erkannten Bedingung ab. 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 von Meldungsintervallen. 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 die Verbindung im normalen Modus nicht deaktiviert.

---

Es ist wichtig, das richtige Nachrichtenintervall auszuwählen, um eine korrekte Erkennungszeit zu gewährleisten. Das Nachrichtenintervall muss schnell genug sein, um die unidirektionale Verbindung zu erkennen, bevor der Weiterleitungs-Loop erstellt wird. Die Switch-CPU darf dabei jedoch nicht überlastet werden. Das Standard-Nachrichtenintervall in diesem Beispiel beträgt 15 Sekunden. Beim beschriebenen klassischen IEEE 802.1D STP-Timer-Szenario ist die geschätzte UDLD-Informationsablaufzeit kürzer als die geschätzte Zeit, die der blockierte Port benötigt, um den Weiterleitungsstatus zu erreichen.

Dieser Vergleich garantiert nicht, dass das aggressive UDLD die Schnittstelle in den Status "err-disable" versetzt, bevor STP die Weiterleitungstopologie ändert. Die ungefähre Zeit, während der UDLD-Nachbarinformationen ablaufen, ist dreimal so lang wie das Nachrichtenintervall. Beispiele:

Texpiration ≈ message_interval × 3

---

Mit dem Standard-Nachrichtenintervall Texpiration ≈ 15 × 3 = 45 Sekunden. Für den klassischen IEEE 802.1D-STP-Betrieb beträgt die ungefähre Zeit, die ein gesperrter Port benötigt, um seine gespeicherten STP-Informationen zu altern und durch den Überwachungs- und Lernstatus in den Weiterleitungsstatus zu wechseln:

Tforward = max_age + (2 × forward_delay)

---

Mit den Standard-STP-Timern: Tforward = 20 + (2 × 15) = 50 Sekunden -Wenn Sie den Ablauf von UDLD-Nachbarinformationen mit dem STP-Port-Übergang vergleichen, wählen Sie ein Nachrichtenintervall aus, das Folgendes beibehält: Ablaufdatum < Tforward

Im aggressiven Modus versucht UDLD nach Ablauf der UDLD-Nachbarinformationen, die bidirektionale Beziehung wiederherzustellen, indem es acht Sekunden lang eine Nachricht pro Sekunde sendet. Wenn der bidirektionale Status nicht wiederhergestellt werden kann, deaktiviert UDLD den lokalen Port.

---

Beispiele für zusätzliche Bedingungen, die vom aggressiven Modus erkannt werden:

• Die physische Verbindung ist auf beiden Seiten aktiv, aber der Port auf einer Seite sendet oder empfängt keine UDLD-Nachrichten.
• Der Link befindet sich auf der einen Seite und auf der anderen Seite. Bei einigen Glasfaserschnittstellen kann das Trennen der Übertragungsfaser vom lokalen Port beispielsweise dazu führen, dass die lokale Verbindung aktiv bleibt, während die Remote-Verbindung ausfällt. Dieses Verhalten hängt von den Mechanismen der Plattform, der Schnittstelle, des Transceivers und der physischen Schicht ab.

---

Einige Ethernet-PHY-Implementierungen bieten Remote-Fehlersignalisierungs- oder Verbindungsaushandlungsmechanismen, die dazu führen können, dass ein oder beide Verbindungsendpunkte nach bestimmten physischen Ausfällen ausfallen. Das Verhalten variiert je nach Plattform, Schnittstellentyp, Transceiver, Medien und Verhandlungsmodus. UDLD bietet Layer-2-Validierung für unidirektionale Bedingungen, die von der Signalisierung der physischen Schicht nicht erkannt werden. Wenn ein Endpunkt nicht senden/empfangen kann oder wenn ein Endpunkt aktiv ist, während der andere inaktiv ist, stellt die ausgefallene Verbindung selbst keinen vollständigen Weiterleitungspfad bereit und bildet keine Weiterleitungsschleife. Eine Schnittstelle, die jedoch aktiv bleibt, kann den Datenverkehr weiterhin an einen nicht funktionierenden Pfad weiterleiten, was zu einem schwarzen Loch im Datenverkehr führt. Aggressive UDLD erkennt den Verlust der bidirektionalen Kommunikation und deaktiviert den betroffenen lokalen Port, wenn die UDLD-Beziehung nicht wiederhergestellt werden kann.

---

Konfiguration und Überwachung

Aktivieren Sie UDLD auf beiden verbundenen Schnittstellen. Konfigurieren Sie auf beiden Endgeräten den gleichen UDLD-Modus, um eine konsistente lokale Fehlererkennung und ein Fehlerdeaktivierungsverhalten zu ermöglichen:

9300-1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
9300-1(config)#interface TenGigabitEthernet1/1/6
9300-1(config-if)#udld port 
9300-1(config-if)#end

9300-2#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
9300-2(config)#interface TenGigabitEthernet1/1/6
9300-2(config-if)#udld port 
9300-2(config-if)#end

Führen Sie die Befehle show udld <Schnittstellen-ID> und show udld neighbors auf beiden Verbindungsendpunkten aus. Vergewissern Sie sich, dass jede Schnittstelle betriebsbereit ist, der aktuelle Status "Bidirectional" (Bidirektional) lautet und die erwarteten Geräte- und Port-IDs der Nachbarn angezeigt werden:

9300-1#show udld TenGigabitEthernet1/1/6

Interface Te1/1/6
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
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: 37500 ms
    Cache Device index: 1
    Current neighbor state: Bidirectional
    Device ID: F87A41A8CA00  
    Port ID: Te1/1/6  
    Neighbor echo 1 device: F87A41A8C180
    Neighbor echo 1 port: Te1/1/6

    TLV Message interval: 15 sec
    No TLV fast-hello interval
    TLV Time out interval: 5
    TLV CDP Device name: 9300-2  

9300-1#show udld neighbors 
Port           Device Name     Device ID    Port ID         Neighbor State
----           -----------     ---------    -------         --------------
Te1/1/6 F87A41A8CA00 1 Te1/1/6 Bidirectional  

Total number of bidirectional entries displayed: 1

9300-2#show udld TenGigabitEthernet1/1/6

Interface Te1/1/6
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
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: 32500 ms
    Cache Device index: 1
    Current neighbor state: Bidirectional
    Device ID: F87A41A8C180  
    Port ID: Te1/1/6  
    Neighbor echo 1 device: F87A41A8CA00
    Neighbor echo 1 port: Te1/1/6

    TLV Message interval: 15 sec
    No TLV fast-hello interval
    TLV Time out interval: 5
    TLV CDP Device name: 9300-1  

9300-2#show udld neighbors 
Port           Device Name     Device ID    Port ID         Neighbor State
----           -----------     ---------    -------         --------------
Te1/1/6 F87A41A8C180 1 Te1/1/6 Bidirectional 
Total number of bidirectional entries displayed: 1

---

Aggressive UDLD kann über den aggressiven Befehl udld auf der Schnittstelle konfiguriert werden:

9300-1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
9300-1(config)#interface TenGigabitEthernet1/1/6
9300-1(config-if)#udld port aggressive 
9300-1(config-if)#end

9300-2#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
9300-2(config)#interface TenGigabitEthernet1/1/6
9300-2(config-if)#udld port aggressive 
9300-2(config-if)#end

---

Führen Sie den Befehl show udld <interface-id> auf beiden Endpunkten aus, um zu überprüfen, ob der aggressive Modus betriebsbereit ist:

9300-1#show udld TenGigabitEthernet1/1/6

Interface Te1/1/6
---
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: 31200 ms
    Cache Device index: 1
    Current neighbor state: Bidirectional
    Device ID: F87A41A8CA00  
    Port ID: Te1/1/6  
    Neighbor echo 1 device: F87A41A8C180
    Neighbor echo 1 port: Te1/1/6

    TLV Message interval: 15 sec
    No TLV fast-hello interval
    TLV Time out interval: 5
    TLV CDP Device name: 9300-2  

9300-2#show udld TenGigabitEthernet1/1/6

Interface Te1/1/6
---
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: 38600 ms
    Cache Device index: 1
    Current neighbor state: Bidirectional
    Device ID: F87A41A8C180  
    Port ID: Te1/1/6  
    Neighbor echo 1 device: F87A41A8CA00
    Neighbor echo 1 port: Te1/1/6

    TLV Message interval: 15 sec
    No TLV fast-hello interval
    TLV Time out interval: 5
    TLV CDP Device name: 9300-1

---

Führen Sie den Befehl udld message time aus, um das Nachrichtenintervall zu ändern:

9300-1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
9300-1(config)#udld message time ?
  <1-90>  Time in seconds between sending of messages in steady state

---

Bei Cisco Catalyst Switches der Serien 3000 und 9000 liegt der Zeitwert für die udld-Nachricht zwischen 1 und 90 Sekunden, der Standardwert ist 15 Sekunden. Überprüfen Sie in den Referenzhandbüchern zu den Befehlen den akzeptierten Bereich und die Standardeinstellungen auf anderen Systemen.

---

Zugehörige Informationen

• Technischer Support und Downloads von Cisco

• Weitere Informationen zu Catalyst 3560-Switches finden Sie unter Konfigurieren von UDLD.

• Informationen zu Catalyst 9300-Switches finden Sie unter How to Configure UDLD 
• Informationen zu Catalyst 9500-Switches finden Sie unter How to Configure UDLD

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
2.0	18-Aug-2026	Aktualisierte Rechtschreibung, Grammatik, eingefügte horizontale Linien in separate Abschnitte für Lesbarkeit.
1.0	09-Jul-2007	Erstveröffentlichung