Dépannez les erreurs unidirectionnelles de détection de lien sur des Commutateurs de Nexus

Introduction

Ce document décrit comment dépanner les messages d'erreur unidirectionnels de la détection de lien (UDLD) sur gamme 7000 de Cisco Nexus commutent.

Conditions préalables

Conditions requises

Cisco recommande que vous ayez une connaissance de base de ces thèmes :

• Système d'exploitation de Cisco Nexus (NX-OS)
• Exécutions de base UDLD 

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Commutateurs de la gamme Cisco Nexus 7000
• Version 6.2(10) de Cisco NX-OS 

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Informations générales 

Les ports permutent des paquets UDLD pendant le procédé de détection UDLD, pour inclure le commutateur-ID de créateur et le port-ID de créateur. Une fois qu'un paquet UDLD est reçu, le commutateur fait écho le commutateur-ID et le port-ID de pair de nouveau au pair. Une fois que les Commutateurs permutent des paquets d'écho, des relations bidirectionnelles sont formées. 

Les conditions d'erreurs UDLD existent quand le commutateur ne reçoit pas les informations prévues de son pair UDLD. 

Ce document décrit ces conditions d'erreurs UDLD et comment les dépanner :

• Vide-écho
• Transmettre-recevez la boucle (de Tx-Rx)
• Unidirectionnel
• Non-concordance voisine
• Arrêt soudain des trames UDLD 

Conditions d'erreurs UDLD

Cette section décrit les divers types des conditions d'erreurs UDLD et de quelques causes probables.

Écho vide 

Cette condition est présente où le commutateur A reçoit une trame UDLD du commutateur B sans écho prévu du commutateur-ID et du port-ID de commutateur A. 

Quand un vide-écho est détecté, l'UDLD exécute ces actions :

Mode	Action
Mode normal	port d'errer-débronchement
Mode agressif	port d'errer-débronchement

Ces messages de Syslog sont alors générés :

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)

Voici quelques causes possibles pour cette condition

• Les relations bidirectionnelles UDLD ont chronométré sur le commutateur B parce qu'elles ne reçoivent pas les trames UDLD du commutateur A.
  
  
• Le commutateur B a reçu les trames UDLD du commutateur A mais ne les a pas traitées.
  
  
• Le commutateur A n'a pas envoyé les trames UDLD au commutateur B.

Boucle de Tx-Rx

Cette condition se produit quand une trame UDLD est reçue sur le même port duquel elle a été transmise.

Quand une boucle de Tx-Rx est détectée, UDLD exécute ces actions :

Mode	Action
Mode normal	port d'errer-débronchement
Mode agressif	port d'errer-débronchement

Ces messages de Syslog sont alors générés :

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)

Voici quelques causes possibles pour cette condition :

• Il pourrait y avoir câblage incorrect ou un support physique émet.
  
  
• Les périphériques intermédiaires reflètent les trames de nouveau au port émetteur.

Non-concordance voisine 

Cette condition est présente où le port-Un sur le commutateur A reçoit une trame d'un port autre que celui avec lequel il a déjà formé des relations bidirectionnelles UDLD. 

Quand une non-concordance voisine est détectée, UDLD exécute ces actions :

Mode	Action
Mode normal	port d'errer-débronchement
Mode agressif	port d'errer-débronchement

Ces messages de Syslog sont alors générés :

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)

Voici quelques causes possibles pour cette condition :

• L'udld port en question est un membre d'un Port canalisé sur lequel un port membre a des états modifiés.
  
  
• Il y a un périphérique intermédiaire entre les deux ports qui ont formé les relations bidirectionnelles.

Arrêt soudain des trames UDLD

Cette condition est présent quand un port qui a formé des relations bidirectionnelles ne reçoit pas une trame UDLD pendant l'intervalle de minuterie (50 secondes par défaut). 

Quand cette condition est détectée, l'UDLD exécute ces actions :

Mode	Action
Mode normal	Les marques UDLD mettent en communication comme indéterminé, et le port continue à fonctionner selon son état de port de spanning tree
Mode agressif	port d'errer-débronchement

Dépannez les conditions d'erreurs UDLD

Cette section décrit les étapes de dépannage générales que vous devriez se terminer si vous rencontrez un port en désactivation des erreurs UDLD. 

Puisque les erreurs UDLD indiquent des défauts de couche physique, il est approprié de dépanner à la couche physique. Quand des messages d'erreur UDLD sont produits, considérez ces questions :

• L'erreur persiste-t-elle si l'émetteur-récepteur de Small Form-Factor Pluggable (SFP) est remplacé ?
  
  
• L'erreur persiste-t-elle si le câble est remplacé ?
  
  
• L'erreur persiste-t-elle si la connexion est déplacée à un port physique différent sur le commutateur ?

Commandes utiles

Employez cette commande afin de restaurer tous les ports qui ont été placés dans le mode d'erreur-débronchement par l'UDLD :

N7KA(config)# udld reset

Employez cette commande afin de vérifier les relations bidirectionnelles :

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.

Employez cette commande afin de vérifier des compteurs d'erreurs sur les interfaces physiques, qui détermine si les trames UDLD sont dues abandonné aux défaillances matérielles de couche physique :

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

Employez cette commande afin de vérifier l'utilisation du processeur, qui détermine si l'utilisation du CPU élevé empêche les trames UDLD d'être traité :

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

Les informations utiles TAC

Cette section décrit les sorties que vous devriez collecter avant que vous restauriez le lien (si l'autorisation de circonstances) afin de fournir le centre d'assistance technique Cisco (TAC) la meilleure occasion de diagnostiquer la cause principale du lien étant placé dans le mode d'erreur-handicapés par l'UDLD :

• lacp de show tech-support tout (si l'interface défectueuse est un membre d'un portchannel du Control Protocol d'agrégation de liaisons (LACP))
• <x> de module de show tech-support (où x est le module où l'erreur UDLD est détectée)
• ethpm de show tech-support
• udld de show tech-support 
• erreurs internes d'événement-historique de show udld 
• msgs internes d'événement-historique de show udld | grep - des 3 - b 3 L2_RX_DATA
• Ethernets internes <x/y> d'événement-historique de show udld
• fichier journal de show log | grep UDLD
• fichier journal de show log | grep Ethernet<x/y> 
• historique de show processes cpu
• affichez les Ethernets <x/y> d'interface
• affichez le <x> de module d'erreurs internes de matériel
• affichez le <x> de module d'erreurs de compteurs d'interface