Résumé

  • Une porteuse optique ne prouve ni le bon voisin ni une communication de niveau 2 dans les deux sens. UDLD ajoute une preuve d’identité de port renvoyée par écho.
  • En mode normal, l’absence non qualifiée reste undetermined. Le mode agressif accepte de sacrifier la disponibilité après une relation auparavant bidirectionnelle, une expiration et des essais de rétablissement infructueux.

Imaginons deux brins de fibre mal raccordés. Le récepteur d’un commutateur voit de la lumière, mais son émetteur aboutit sur une autre porte que celle qui lui répond. Le voyant vert ne ment pas : il décrit une réalité physique étroite. C’est l’interprétation « le bon voisin est joignable dans les deux sens » qui dépasse sa preuve.

UDLD corrige ce raccourci avec des identités. Chaque message annonce un Device-ID et un Port-ID. Le voisin renvoie, dans l’Echo TLV, les couples qu’il a effectivement reçus et mis en cache sur la même interface. Retrouver son propre couple dans la réponse établit une boucle de reconnaissance entre portes précises.

Cette boucle n’est pas un test universel du trafic. Elle ne parcourt pas toutes les files, tous les VLAN, toutes les tailles de trame ou tous les chemins applicatifs. Elle est un témoin de contrôle daté, traité par le plan de contrôle et dépendant d’un minuteur.

Le temps fait partie de la preuve

Les voisins appris restent en mémoire jusqu’à un holdtime. Un nouveau hello remplace l’entrée précédente et relance son délai. Une désactivation ou un redémarrage efface l’état local et tente d’avertir les voisins afin qu’ils effacent l’état correspondant.

Le registre de voisinage doit donc être lu comme une série d’observations, pas comme une propriété permanente du câble. Une entrée peut être fraîche, vieillissante, remplacée ou absente. L’opérateur qui ne conserve que l’état final perd l’ordre des événements : dernier hello accepté, expiration, tentative de resynchronisation, coupure et reprise.

Le RFC précise aussi que l’algorithme envoie un train de N échos et suppose que N suffit malgré quelques pertes. La vitesse dépend du processeur, de l’ordonnancement logiciel et du traitement des événements. Les valeurs prudentes visaient à limiter les faux positifs. Un délai n’est donc pas un simple chiffre de configuration ; il appartient au modèle de confiance du détecteur.

Le mode normal exige un événement

Le mode normal fonde sa conclusion sur des informations reçues. Un écho peut confirmer les bonnes identités ou révéler une association contradictoire. Mais lorsque plus aucune information utile n’arrive, même après une perte dans les deux sens, ce mode refuse de transformer le vide en diagnostic. Il retient l’état undetermined.

Ce choix protège contre une confusion fréquente. Les messages peuvent disparaître à cause d’un défaut de fibre, d’un taux d’erreur élevé, d’un duplex incohérent, d’une charge CPU, d’un processus arrêté, d’un voisin incapable ou d’une modification de configuration. La même observation externe ne sépare pas ces causes.

La documentation Cisco actuelle maintient cette limite : une entrée UDLD peut expirer à cause d’erreurs ou d’un problème de duplex sans que le lien soit unidirectionnel. Le mode normal ne coupe pas uniquement parce que le cœur de contrôle est devenu silencieux.

Le mode agressif assume un coût

Le mode agressif ajoute une règle de décision. Si une relation bidirectionnelle existait, si les informations expirent et si les derniers essais répétés ne la restaurent pas, la porte locale peut passer en errdisable. Des guides Cisco actuels décrivent huit messages espacés d’une seconde sur certaines implémentations. Il s’agit d’un comportement de plate-forme, pas d’une constante intemporelle pour tous les équipements.

La coupure reste justifiée par un ensemble de prémisses : état antérieur connu, silence assez long, essais actifs, lien physique encore présenté comme actif et topologie où perdre le voisin est inadmissible. Voilà pourquoi le RFC réserve ce mode à des scénarios particuliers, typiquement des liaisons point à point.

Errdisable limite un risque ; il ne révèle pas automatiquement sa cause. Il peut empêcher une boucle ou un trou noir. Il ne dit pas si le brin, l’optique, l’ASIC, le processus distant ou le câblage est responsable.

UDLD ne gagne pas toujours la course

Le spanning tree peut réagir pendant que le délai UDLD court. La documentation Cisco avertit que le calcul historique associé à STP ne garantit pas que UDLD agira avant une transition RSTP. Le résultat dépend de la plate-forme, du logiciel, des rôles de ports, des minuteurs, de la topologie et de l’instant du défaut.

Une enquête sérieuse rapproche donc les reçus sans les fusionner : signal physique, voisinage UDLD, expiration, échos de secours, errdisable, changement STP/RSTP, bascule de chemin, compteurs de trafic et résultat applicatif. Le silence devient exploitable seulement parce que ses hypothèses et son coût ont été déclarés.

Sources