Introduction
Ce document décrit comment le protocole UDLD (Unidirectional Link Detection) peut aider à empêcher les boucles et les anomalies de trafic dans les réseaux commutés.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Conventions
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Définition du problème
Le protocole STP (Spanning Tree Protocol) résout la topologie physique redondante en une topologie de transfert de type arbre sans boucle.
Pour ce faire, il bloque un ou plusieurs ports. Avec un ou plusieurs ports bloqués, il n'y a pas de boucles dans la topologie de transfert. Dans son fonctionnement, le protocole STP compte sur la réception et la transmission des unités BPDU (Bridge Protocol Data Unit). Si le processus STP qui s'exécute sur le commutateur avec un port à l'état de blocage ne reçoit pas de BPDU de son commutateur amont (désigné), STP finit par expirer les informations STP pour le port et le déplace à l'état de transmission.
Cela peut créer une boucle STP où les paquets commencent à circuler indéfiniment le long du chemin en boucle, et consomme de plus en plus de bande passante et de ressources. Ceci mène à une éventuelle panne de réseau.
Comment est-il possible que le commutateur ne reçoive pas de BPDU lorsque le port est actif ? La raison en est une liaison unidirectionnelle.
Une liaison est considérée unidirectionnelle quand ceci se produit :
Considérez ce scénario. Les flèches indiquent le flux des BPDU STP.
En fonctionnement normal, le pont B est un port désigné sur la liaison B-C. Le pont B envoie des BPDU à C, qui bloque le port. Le port est bloqué tandis que C voit des BPDU de B sur cette liaison.
Maintenant, considérez ce qui se passe si la liaison B-C tombe en panne dans la direction de C. C cesse de recevoir le trafic de B, cependant, B reçoit toujours le trafic de C.
vers le haut
C ne reçoit pas de BPDU sur la liaison B-C et vieillit les informations reçues avec la dernière BPDU. Cela prend jusqu'à 20 secondes, ce qui dépend du minuteur STP maxAge. Une fois que les informations STP ont expiré sur le port, ce dernier passe de l'état de blocking à l'état STP de listening, learning et par la suite forwarding . Cela crée une boucle, car il n'y a pas de port bloqué dans le triangle A-B-C. Les paquets circulent le long du chemin (B reçoit toujours des paquets de C), ce qui consomme de la bande passante supplémentaire jusqu'à ce que les liaisons soient complètement remplies.
Ce scénario peut mettre le réseau hors service. Un autre problème possible qui peut être causé par une liaison unidirectionnelle est un trou noir de trafic.
Comment fonctionne le protocole UDLD (Unidirectional Link Detection)
UDLD est un protocole de couche 2 (L2) qui fonctionne avec les mécanismes de la couche 1 (L1) pour déterminer l'état physique d'une liaison. À la couche 1, la négociation automatique prend soin de la signalisation physique et de la détection des pannes. UDLD effectue des tâches que la négociation automatique ne peut pas effectuer, telles que la détection des identités des voisins et l'arrêt des ports déconnectés. Quand vous activez la négociation automatique et UDLD, la détection de la couche 1 et celle de la couche 2 fonctionnent ensemble pour empêcher les connexions unidirectionnelles physiques et logiques et le défaut de fonctionnement d'autres protocoles.
UDLD fonctionne par l'échange de paquets de protocole entre les périphériques voisins. Pour qu'UDLD fonctionne, les deux périphériques sur la liaison doivent prendre en charge UDLD et l'activer sur les ports respectifs.
Chaque port de commutateur configuré pour UDLD envoie des paquets de protocole UDLD qui contiennent l'ID de port/périphérique et les ID de port/périphérique voisins vus par UDLD sur ce port. Les ports voisins voient leur propre ID de périphérique/port (écho) dans les paquets reçus de l'autre côté. Si le port ne voit pas son propre ID de périphérique/port dans les paquets UDLD entrant pendant une durée spécifique, la liaison est considérée unidirectionnelle.
Cet écho-algorithme permet la détection des problèmes suivants :
-
La liaison est up des deux côtés, mais les paquets ne sont reçus que par un côté.
-
Des erreurs de connexion (fil) se produisent lorsque les fibres de réception et de transmission ne sont pas connectées au même port du côté distant.
Une fois la liaison unidirectionnelle détectée par UDLD, le port respectif est désactivé et ce message est imprimé sur la console :
UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabled
L'arrêt de port par UDLD reste désactivé jusqu'à ce qu'il soit activé manuellement ou jusqu'à expiration de la temporisation de désactivation (si configuré).
Modes de fonctionnement d'UDLD
UDLD peut fonctionner dans deux modes : normal et agressif : .
- Dans le mode normal, si l'état de la liaison du port a été déterminé pour être bidirectionnel et que les informations UDLD expirent, aucune mesure n'est prise par UDLD. L'état du port pour UDLD est marqué en tant que undetermined. Le port se comporte conformément à son état STP.
- Dans le mode agressive , si l'état de la liaison du port est déterminé pour être bidirectionnel et que les informations UDLD expirent tandis que la liaison sur le port est toujours up, UDLD essaye de rétablir l'état du port. En cas d'échec, le port est placé en l'état errdisable.
L'expiration des informations UDLD se produit lorsque le port qui exécute UDLD ne reçoit pas de paquets UDLD du port voisin pendant la durée du temps d'attente. Le temps d'attente pour le port est dicté par le port distant et dépend de l'intervalle des messages sur le côté distant. Plus l'intervalle entre les messages est court, plus le temps d'attente et la détection sont courts. Les réalisations récentes d'UDLD autorisent la configuration de l'intervalle des messages. Les informations UDLD peuvent expirer en raison du taux d'erreur élevé sur le port provoqué par un problème physique ou une erreur de correspondance de duplex. Une telle perte de paquets ne signifie pas que la liaison est unidirectionnelle et UDLD en mode normal ne désactive pas une telle liaison.
Il est important de pouvoir choisir le bon intervalle de messages afin d'assurer un temps de détection approprié. L'intervalle de message doit être suffisamment rapide pour détecter la liaison unidirectionnelle avant la création de la boucle de transfert, mais il ne doit pas surcharger le processeur du commutateur. L'intervalle de message par défaut est de 15 secondes et est suffisamment rapide pour détecter la liaison unidirectionnelle avant la création de la boucle de transfert avec les compteurs STP par défaut. Le temps de détection est approximativement égal à trois fois l'intervalle des messages.
Par exemple : Tdetection~ intervalle_message x3
C'est 45 secondes pour l'intervalle de messages par défaut de 15 secondes.
Il faut Treconvergence=max_age + 2x forward_delay pour que le STP reconverge en cas de défaillance de liaison unidirectionnelle. Avec les temporisateurs par défaut, cela prend 20+2x15=50 secondes.
Il est recommandé de conserver Tdetection< Treconvergence et de choisir un intervalle de message approprié.
En mode agressif, une fois que les informations sont vieillies, UDLD fait une tentative de rétablir l'état de la liaison et envoie des paquets toutes les secondes pendant huit secondes. Si l'état de la liaison n'est toujours pas déterminé, la liaison est désactivée.
Aggressivemode ajoute une détection supplémentaire de ces situations :
-
Le port est coincé (d'un côté le port ne transmet ni ne reçoit, mais la liaison est up des deux côtés).
-
La liaison est up d'un côté et down de l'autre côté. Ce problème peut être constaté sur les ports fibre lorsque la fibre de transmission est débranchée sur le port local, la liaison reste active sur le côté local. Cependant, elle est désactivée< /tt>sur le côté distant.
Récemment, les réalisations de matériel FastEthernet par fibre ont des fonctions d'indication de panne d'extrémité lointaine (FEFI) afin que la liaison soit down des deux côtés dans ces situations. Sur GigabitEthernet, une fonction similaire est fournie par la négociation de liaison. Les ports cuivre ne sont normalement pas sujets à ce type de problème, car ils utilisent des impulsions de liaison Ethernet pour surveiller la liaison. Il est important de mentionner que dans les deux cas, aucune boucle de transfert ne se produit car il n'y a aucune connectivité entre les ports. Cependant, si la liaison est active d'un côté et inactive de l'autre, un trou noir peut se produire. La détection UDLD agressive est conçue pour empêcher ceci.
Disponibilité
UDLD est disponible en mode normal et agressif à partir de la version 12 du logiciel Cisco IOS®.
Configuration et surveillance
Exécutez la commande show udld pour vérifier si UDLD est activé sur les interfaces :
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 peut être configuré sur l'interface avec le udld port aggressive
commande :
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#
Lancez show udld
et show udld neighbors
pour vérifier si UDLD est activé ou désactivé sur le port et quel est l'état de la liaison et du voisin :
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-01
Switch#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
Utilisez udld message time
pour modifier l'intervalle entre les messages :
Switch(config)#udld message time 10
UDLD message interval set to 10 seconds
L'intervalle peut être compris entre 1 et 90 secondes, la valeur par défaut étant de 15 secondes.
Informations connexes