plus le système est sécurisé, plus la faille est vicieuse

au secours, j'ai une boucle dans mon carré !

Albert avait pourtant été prudent…

Albert gère un site avec deux bâtiments. Dans chaque bâtiment, il y a deux switches (au total, si vous suivez bien, cela fait 4 switches). Cela forme un beau carré en fibres optiques. Et en plus, à l’intérieur de chaque bâtiment, Albert a mis un Etherchannel avec deux fibres. Bien sûr, Albert fait tourner Spanning Tree pour éviter de créer une boucle de niveau 2.

Autant dire qu’avec ceinture ET bretelles, Albert partait tranquillement en week end.

Tout marchait très bien, jusqu’à la semaine dernière, horreur, une tempête de broadcast : réseau par terre, IT inutilisable, téléphonie IP cassée… Albert a fait débrancher toutes les fibres, les a fait rebrancher en vérifiant tout. Ouf, le réseau fonctionne à nouveau normalement aux niveaux 2 et 3. Albert passe la main aux collègues de l’IT. Des heures à redémarrer les services, à resynchroniser les serveurs…

Réunion de crise, rapport circonstancié, critiques acerbes… Pas d’augmentation pour Albert.

Pascal, explique-moi, j’y comprends rien !

Albert me contacte pour voir si j’ai une explication et des conseils à donner. Il me signale que, sur un Etherchannel, il y a un truc bizare : 
une des interfaces de l’Ether Channel est « UP » d’un côté, « DOWN » de l’autre.

• "ben, quelqu’un a dû bricoler tes fibres ?"
• "c’est possible, il y avait des travaux de câblage le jour de la panne"
• "Albert, je crois que je sais ce qui c’est passé.
  Un brin de fibre dans ton etherchannel est mal branché ou cassé.
  Du coup, le lien ne fonctionne que dans un sens. C’est un lien unidirectionnel..."
• "et alors ?"
• "alors, il faut 90 secondes pour que PAgP s’en aperçoive. 
  Pendant ce temps, il y a un trou noir, PAgP continue à envoyer du trafiic.
  Et, pas de chance, c’était le lien par où passe le protocole Spanning Tree.
  Dans le switch de l’autre côté, Spanning Tree ne reçoit rien du switch d’en face.
  Il passe le lien en « forwarding ». Le premier broacast venu va être envoyé sur l’Etherchannel…il fait le tour de ton carré… encore… et encore… et tu as une belle tempête. Avec la tempête, la CPU des switches est à 100% de charge.
  Les protocoles font n’importe quoi. Spanning Tree ne marche plus bien, il ne peut pas rétablir un arbre. 
  Ton réseau est raide mort… bon, disons, dans le coma…"

bon, alors, je fais quoi ?

Voici la configuration des interfaces :

interface GigabitEthernet1/0/25
. . .
channel-group 1 mode desirable
speed nonegotiate
interface GigabitEthernet1/0/26
. . .
channel-group 1 mode desirable
speed nonegotiate

Là je lui dis : "ah ben oui, t'as mis « speed nonegotiate », y fallait pas."

Albert me répond : "c’est configuré comme cela depuis la nuit des temps. 
C’était écrit en toutes lettres dans le « Configuration Guide » de l’époque. 
Et puis, y a rien à négocier sur une fibre, c'est toujours du Gigabit Ethernet, Full Duplex."

"C’est comme tu veux, Albert, mais lis donc la RFC 802.3z 2008, section 3, clause 37. 
Tu y verras que l’autonegociation prévoit de transmettre un “Remote Fault signal”.
Si jamais une interface ne reçoit rien, elle émet ce signal.
Et de l’autre côté, l’interface passe “DOWN”, le tout dure environ 300 millisecondes.
Alors dans ton cas, avec l’autonégociation, le réseau ne serait pas parti en boucle...
Pas besoin d’attendre que PaGP s’aperçoive que quelque chose ne va pas.
D'ailleurs, à propos de boucles, tu aurais dû suivre mes conseils : 
Mettre du "storm-control". Tu aurais eu une boucle, mais pas une tempête ...
Et si ça avait été Gi 1/0/26 au lieu de Gi 1/0/25, eh bien tu n'aurais rien vu !
Et pourtant, il y aurait eu un trou noir de 90" sur l'etherchannel, du trafic perdu.
Tes collègues de l'IT aurait râlé fort ...mais ils auraient eu moins de travail.
Finalement, cette tempête a révéle une faille bien cachée ... 
Une ligne de configuration de trop !! Le fameux grain de sable ...

...bruits sourds (Albert se tape la tête contre le mur)

"Mon conseil, Albert, c’est de laisser l’autonégociation faire son travail.
Depuis 2008, tous les équipements doivent savoir le faire pour être conformes au 802.3z.
Et bien sûr, configurer storm-control."

moralités

1. le mieux est l’ennemi du bien
2. plus le système est sécurisé, plus la faille est vicieuse
3. oh, architecte réseau, n’oublie jamais la Loi de Murphy

Pascal

crédit photo : © picadillu - Fotolia.com