Les chercheurs ont tout inventé, y compris des choses qui ne servent plus, et puis d’autres, qui sont bien là, mais qu’on a oubliées. C’est le cas de« CTP loopback » : en gros, c’est un « ping » de niveau 2 et un « anti boucle » de base.
Alors, si vous cherchez les spécifications de CTP loopback, vous allez être bien surpris, le protocole n’est pas mentionné dans le standard IEEE 802.3. Pendant longtemps, tout ce qu’on trouvait, c’était l’mage scannée d’une documentation dactylographiée !! (pour approfondir, voir ici)
Et pourtant, c’est implémenté... En l’absence de spécifications, on peut déjà s’attendre à des surprises. He bien, il y en a !
CTP loopback : des bâtons dans les roues
La trame « CTP loopback » est facile à reconnaître : la mac adresse source est égale à la mac adresse destination. Vous pensez que ce n’est pas possible ? He bien si, ils l’ont fait. Et la plupart des Catalyst en génère un « CTP loopback » toutes les 10 secondes sur chaque interface.
Maintenant, si jamais l’interface reçoit une des trames CTP loopback qu’elle a émise, c’est qu’il y a une boucle dans le réseau, ce qui n’est pas souhaitable. Logiquement, l’interface en question sera désactivée. Il faut passer une commande manuelle pour la réactiver.
Vous allez me dire que cela n’arrive jamais ?? Mais si, cela arrive. Spécialement quand il y a des travaux sur la ligne. Ou si par hasard un Etherchannel bagote quelque part dans le réseau de switches. Alors on met un paramètre qui dit qu’au bout d’un certain temps, l’interface doit repasser opérationnelle.
Mais que va-t-il se passer si Gaston met dans le PC de Prunelle un petit programme qui renvoie la trame CTP loopback dès qu’elle est reçue ? Eh bien, le PC de Prunelle n’a plus accès au réseau tant qu’on n’a pas éliminé ce tout petit bout de code (en fait , le code de Gaston peut même construire de toute pièce une trame CTP loopback, à partir de l’observation des autres protocoles actifs sur le Catalyst).
CTP loopback ne sert pas à grand chose : autant le désactiver.
Pour cela, configurer « no keepalive » sur les interfaces. De la sorte, les CTP loopback ne sont plus émis sur cette interface.
Mais cela ne suffit pas !! Car si l’interface reçoit quand même un CTP loopback (à cause du code de Gaston), le switch va désactiver l’interface. Il faut lui dire de n’en rien faire : configurer « no errdisable detect loopback» en configuration globale.
Nota : à partir de l’IOS 12.2(50)SE, cette précaution est moins justifiée, le « no keepalive » suffit à lui seul.
Vos remarques, questions et autres interventions sont les bienvenues.
Pascal BONNARD
Les articles de la série "Ethernet" :
Ethernet, un niveau à ne pas négliger
Les attaques « classiques » : interception de trafic, dénis de service
A éliminer d’urgence : DTP
Les VLANs pour les Nuls : je configure les VLANs de mes trunks bien propres
Les VLANs pour les Nuls : VTP / MRP
Les boucles et les tempêtes : STP et comment s’en dispenser
L’art d’en dire trop : CDP et LLDP
Incroyable, mais vrai : CTP loopback
A utiliser sans (trop) d’ illusions : LAG (PaGP, LACP)
Conclusion, la configuration ultime pour mes switches
copyright image : © Stephen Finn - Fotolia.com