Fehlerbehebung bei Fehlern der unidirektionalen Verbindungserkennung auf Nexus-Switches

Einleitung

In diesem Dokument wird die Fehlerbehebung bei UDLD-Fehlermeldungen (Uni-Directional Link Detection) auf einem Cisco Nexus Switch der Serie 7000 beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Grundkenntnisse in den folgenden Themen verfügen:

• Cisco Nexus-Betriebssystem (Cisco NX-OS)
• Grundlegende UDLD-Vorgänge 

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Cisco Nexus Switches der Serie 7000
• Cisco NX-OS Version 6.2(10) 

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 

Die Ports tauschen UDLD-Pakete aus, wenn der UDLD-Erkennungsprozess ausgeführt wird. Sie enthalten die Switch-ID des Originators und die Port-ID des Originators. Wenn ein UDLD-Paket empfangen wird, sendet der Switch ein Echo der Peer-Switch-ID und der Port-ID zurück an den Peer. Wenn die Switches Echopakete austauschen, entsteht eine bidirektionale Beziehung. 

Die UDLD-Fehlerbedingungen liegen vor, wenn der Switch die erwarteten Informationen nicht von seinem UDLD-Peer empfängt. 

In diesem Dokument werden die UDLD-Fehlerbedingungen und die entsprechende Fehlerbehebung beschrieben:

• Leeres Echo
• Sende-Empfangs-Schleife (Tx-Rx)
• Uni-Richtung
• Nachbarn stimmen nicht überein
• Plötzliches Beenden von UDLD-Frames 

UDLD-Fehlerbedingungen

In diesem Abschnitt werden die verschiedenen Arten von UDLD-Fehlerzuständen und einige wahrscheinliche Ursachen beschrieben.

Leeres Echo 

Diese Bedingung tritt auf, wenn Switch-A einen UDLD-Frame von Switch-B ohne das erwartete Echo der Switch-A-Switch-ID und Port-ID empfängt. 

Wenn ein leeres Echo erkannt wird, führt das UDLD die folgenden Aktionen aus:

Modus	Aktion
Normaler Modus	Port für err-disable
Aggressiver Modus	Port für err-disable

Diese Syslog-Meldungen werden generiert:

2015 Mar 19 11:57:56.155 N7kA ETHPORT-2-IF_DOWN_ERROR_DISABLED Interface Ethernet1/2
 is down (Error disabled. Reason:UDLD empty echo)
2015 Mar 19 11:57:56.186 N7kA ETH_PORT_CHANNEL-5-PORT_INDIVIDUAL_DOWN individual port
 Ethernet1/2 is down
2015 Mar 19 11:57:56.336 N7kA ETHPORT-2-IF_DOWN_ERROR_DISABLED Interface Ethernet1/2
 is down (Error disabled. Reason:UDLD empty echo)

Hier einige mögliche Ursachen für diese Bedingung:

• Die bidirektionale UDLD-Beziehung ist auf Switch-B abgelaufen, da er die UDLD-Frames nicht von Switch-A empfängt.
• Switch-B hat die UDLD-Frames von Switch-A empfangen, sie aber nicht verarbeitet.
• Switch-A hat die UDLD-Frames nicht an Switch-B gesendet.

Tx-Rx-Schleife

Diese Bedingung tritt auf, wenn ein UDLD-Frame an demselben Port empfangen wird, von dem er übertragen wurde.

Wenn eine Tx-Rx-Schleife erkannt wird, führt UDLD die folgenden Aktionen aus:

Modus	Aktion
Normaler Modus	Port für err-disable
Aggressiver Modus	Port für err-disable

Diese Syslog-Meldungen werden generiert:

2015 Mar 20 14:52:30 N7kA   %ETHPORT-2-IF_DOWN_ERROR_DISABLED: Interface Ethernet17/5
 is down (Error disabled. Reason:UDLD Tx-Rx Loop)
2015 Mar 20 14:52:30 N7kA   %ETHPORT-2-IF_DOWN_ERROR_DISABLED: Interface Ethernet17/5
 is down (Error disabled. Reason:UDLD Tx-Rx Loop)

Hier sind einige mögliche Ursachen für diesen Zustand:

• Es kann sich um eine falsche Verkabelung oder ein physisches Medienproblem handeln.
• Die zwischengeschalteten Geräte spiegeln die Frames zurück zum sendenden Port.

Nachbarkonflikt 

Diese Bedingung ist gegeben, wenn Port-A auf Switch-A einen Frame von einem anderen Port empfängt als dem, mit dem er bereits eine bidirektionale UDLD-Beziehung aufgebaut hat. 

Wenn eine Nachbarinkongruenz erkannt wird, führt UDLD die folgenden Aktionen aus:

Modus	Aktion
Normaler Modus	Port für err-disable
Aggressiver Modus	Port für err-disable

Diese Syslog-Meldungen werden generiert:

2015 Mar 21 10:23:05.598 N7kA %ETHPORT-2-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/21
 is down (Error disabled. Reason:UDLD Neighbor mismatch)
2015 Mar 21 10:24:07.065 N7kA %ETHPORT-2-IF_DOWN_ERROR_DISABLED: Interface Ethernet3/21
 is down (Error disabled. Reason:UDLD Neighbor mismatch)

Hier sind einige mögliche Ursachen für diesen Zustand:

• Der betreffende UDLD-Port ist Mitglied eines Port-Channels, auf dem ein Mitglied-Port seinen Status geändert hat.
• Zwischen den beiden Ports, die die bidirektionale Beziehung bildeten, befindet sich eine Zwischenvorrichtung.

Plötzliches Beenden von UDLD-Frames

Diese Bedingung tritt auf, wenn ein Port, der eine bidirektionale Beziehung gebildet hat, bei einer Zeitüberschreitung des Intervalls (standardmäßig 50 Sekunden) keinen UDLD-Frame empfängt. 

Wenn diese Bedingung erkannt wird, führt das UDLD die folgenden Aktionen aus:

Modus	Aktion
Normaler Modus	UDLD markiert den Port als unbestimmt, und der Port funktioniert weiterhin gemäß seinem Spanning-Tree-Port-Status.
Aggressiver Modus	Port für err-disable

Fehlerbehebung bei UDLD-Fehlerbedingungen

In diesem Abschnitt wird beschrieben, wie Sie die Fehlerbehebung durchführen und die Schritte durchführen, die bei einem UDLD-Vorfall erforderlich sind.  error-disabled anschluss. 

Da UDLD-Fehler auf Fehler in der physischen Schicht hinweisen, ist es angebracht, die Fehlerbehebung auf der physischen Schicht durchzuführen. Bei Auftreten von UDLD-Fehlermeldungen sollten Sie folgende Fragen berücksichtigen:

• Bleibt der Fehler bestehen, wenn der Small Form-Factor Pluggable Transceiver (SFP) ersetzt wird?
• Bleibt der Fehler bestehen, wenn das Kabel ersetzt wird?
• Bleibt der Fehler bestehen, wenn die Verbindung an einen anderen physischen Port des Switches verschoben wird?

Nützliche Befehle

Verwenden Sie diesen Befehl, um alle Ports wiederherzustellen, die in  error-disable  Modus durch UDLD:

N7KA(config)# udld reset

Verwenden Sie diesen Befehl, um die bidirektionale Beziehung zu überprüfen:

N7KA-NORTH-AGG(config-if)# show udld eth 3/4

Interface Ethernet3/4
--------------------------------
Port enable administrative configuration setting: enabled
Port enable operational state: enabled
Current bidirectional state: bidirectional
Current operational state:  advertisement - Single neighbor detected
Message interval: 7
Timeout interval: 5

Entry 1
----------------
Expiration time: 39
Cache Device index: 1
Current neighbor state: bidirectional
Device ID: JAF1620ABAB
Port ID: Ethernet3/12
Neighbor echo 1 devices: JAF1617BACD
Neighbor echo 1 port: Ethernet3/4

Message interval: 15
Timeout interval: 5
CDP Device name: N7KB-SOUTH-AGG(JAF1620ABAB)


Last pkt send on: 400096, Aug  6 13:58:52 2014
Probe pkt send on: 400096, Aug  6 13:58:52 2014
Echo  pkt send on: 395799, Aug  6 13:58:43 2014
Flush pkt send on: None.

Last pkt recv on: 740333, Aug  6 13:58:52 2014
Probe pkt recv on: 740333, Aug  6 13:58:52 2014
Echo  pkt recv on: 730454, Aug  6 13:58:43 2014
Flush pkt recv on: None.

Deep pkt inspections done: None.
Mismatched if index found: None.
Deep pkt inspection drops: None.

Verwenden Sie diesen Befehl, um die Fehlerindikatoren auf den physischen Schnittstellen zu überprüfen, die bestimmen, ob die UDLD-Frames aufgrund von Hardwarefehlern auf der physischen Ebene verworfen werden:

RTP-Agg1# show interface ethernet 4/1 | i error|CRC|discard|drop
    0 runts  0 giants  0 CRC/FCS  0 no buffer
    0 input error  0 short frame  0 overrun   0 underrun  0 ignored
    0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
    0 input with dribble  0 input discard
    0 output error  0 collision  0 deferred  0 late collision
    0 lost carrier  0 no carrier  0 babble  0 output discard

Verwenden Sie diesen Befehl, um die CPU-Auslastung zu überprüfen, die feststellt, ob eine hohe CPU-Auslastung den Prozess für die UDLD-Frames verhindert:

N7K-A# show system resources
Load average:   1 minute: 0.17   5 minutes: 0.25   15 minutes: 0.20
Processes   :   1993 total, 1 running
CPU states  :   0.18% user,   0.81% kernel,   98.99% idle

Nützliche TAC-Informationen

In diesem Abschnitt werden die Ausgaben beschrieben, die Sie sammeln müssen, bevor Sie den Link wiederherstellen (sofern die Umstände dies erlauben). Dadurch erhält das Cisco Technical Assistance Center (TAC) die beste Chance, die Ursache für den Link zu diagnostizieren, der vom UDLD in den fehlerdeaktivierten Modus versetzt wird:

• show tech-support lacp all (wenn die ausgefallene Schnittstelle Teil eines LACP-Port-Channels (Link Aggregation Control Protocol) ist)
• show tech-support module   (wobei x das Modul ist, in dem der UDLD-Fehler erkannt wird)
• show tech-support ethpm
• show tech-support udld 
• show udld internal event-history errors 
• show udld internal event-history msgs | grep -a 3 -b 3 L2_RX_DATA
• show udld internal event-history ethernet
• show log logfile | grep UDLD
• show log logfile | grep Ethernet  
• show processes cpu history
• show interface ethernet
• show hardware internal errors module
• show interface counters errors module

Zugehörige Informationen

• Technischer Support und Downloads von Cisco