une cause de panne inattendue : le service Achat !
Albert a maintenant un second centre de calcul, mais cette fois-ci, il est à distance. Alors bien sûr, on demande à Albert de relier tout cela de manière sécurisée.
Ce dernier voudrait bien utiliser l’architecture éprouvée qu’il a mis au point sur son campus : il demande donc deux liaisons en fibre optique pour relier les deux sites. Mais voilà, c’est trop cher ! Le service des achats commande à la place deux accès Ethernet, c’est moins cher et ça fera la même chose.
rien ne marche comme prévu lors de la mise en service
En effet, contrairement à une liaison sur fibre optique, sur l’accès Ethernet, l’interface locale est « up ». On ne connait pas l’état de l’interface distante. Du coup, en cas d’incident, Spanning Tree peut faire passer le trafic par un lien cassé.
Albert m’appelle, il est en retard sur son planning, il a la pression…
- Comment faire, Pascal ???
- Ben, c’est facile, tu supervises ta liaison avec des OAM…
- Très drôle, Pascal, tu sais bien qu’il n’y en a pas sur les switches que j’utilise !
- Hum. Alors, j’ai un truc pas propre à te proposer… et pas garanti…
- Allez, vas-y
Alors là, je dis à Albert d’activer UDLD entre les interfaces de ses switches : « udld port agressive »
UDLD : comment ça marche
UDLD envoie toutes les secondes un message qui identifie le switch émetteur et son interface.
Si UDLD reçoit ce genre de message du switch d’en face, il sait que le lien fonctionne dans les deux sens. Quand il ne les reçoit plus, il sait que quelque chose ne va plus.
En mode « agressive », UDLD va passer le lien « disabled ». Cela prend une dizaine de secondes. Et Spanning Tree n’essaye pas d’utiliser une interface « disabled ».
Le seul problème, c’est qu’on ne sait pas si le service Ethernet laisse passer UDLD. Je conseille à Albert de dire à son fournisseur qu’il veut la transparence à tous les protocoles de niveau 2.
Albert essaye et hop, ça passe, UDLD fonctionne !
« sh udld Gi1/1 » indique partout « Current neighbor state: Bidirectional ».
Dès lors, si on perd le contact avec le switch d’en face, on voit les messages suivants :
%UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi1/1, aggressive mode failure detected
%PM-4-ERR_DISABLE: udld error detected on Gi1/1, putting Gi1/1 in err-disable state
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/1, changed state to down
%LINK-3-UPDOWN: Interface GigabitEthernet1/1, changed state to down
Albert est content (pour l’instant)
N.B. Albert a quand même de la chance, le service Ethernet qu’il utilise peut laisser passer UDLD. Croyez-moi, ce n’est pas si évident, parce que UDLD utilise des mac adresses qui ne sont normalement pas transportées par la norme d’encapsulation L2CP.
Heureusement, il y a des fournisseurs qui savent faire ce que demandent les clients au lieu d’appliquer bêtement les normes (je ne dénoncerai personne).
Pascal
crédit photo : © Andrey Armyagov - Fotolia.com
Depuis 2004, je m’occupe d'ingénierie de commutateurs Ethernet (switches en anglais). Comme je suis curieux de nature, j'ai voulu savoir ce qu'il y avait sous le capot ... et c'est là que j'ai vu tous ces protocoles qui ne nous veulent que du bien, mais qui posent d'inévitables questions de sécurité. Sont-ils fiables ? Peuvent-ils être trompés ? Il me semble que ce domaine est peu documenté, et que les informations disponibles sont souvent incomplètes, parfois erronées. Je désire vous faire partager mes connaissances qui s'appuient sur des tests en laboratoire ainsi que sur plusieurs centaines de machines opérationnelles.