les boucles : j'en remets une couche !

Cédric a bien raison de recommander quelques précautions élémentaires concernant les attaques du Spanning-Tree. On ne va quand même pas laisser n’importe qui prendre le pouvoir dans notre réseau de switches !

Cependant, si on désactive le Spanning Tree sur les interfaces des utilisateurs pour ne pas se faire hacker, he bien, si jamais il y a une boucle, elle ne sera pas désactivée. C’est bien ennuyeux. Et puis on a déjà vu Spanning Tree mal fonctionner pour diverses raisons.

En fait, quoi que vous fassiez, une tempête peut toujours survenir. Et, la plupart du temps, on ne comprend ni pourquoi, ni comment cela a bien pu arriver, parce qu’on est très occupé à jouer au pompier pour essayer d’arrêter cette maudite tempête ! (et ça peut prendre des heures)

Alors, que faire ? La réponse est simple : configurer la limitation de tempêtes « storm-control ». Ce n’est pas bien compliqué, et ça peut éviter de GROS ennuis.

à propos, c’est quoi cette histoire de tempête ?

Pour avoir une tempête, il faut réunir deux conditions :

1. il y a une ou plusieurs boucles de niveau 2
2. un equipement génère au moins une trame qui doit être diffusée sur toutes les interfaces

La trame va aussi être émise sur chaque interface de la boucle et reçue, donc difusée, à nouveau … et cela sans fin.

Dans la pratique, les tempêtes sont liées à des trames dont l’adresse de destination porte le bit « Group address ». Cela correspond à une valeur impaire du premier octet de l’adresse mac destination. On observe en fait deux valeurs pour cet octet : la valeur « FF » et la valeur « 01 ». La valeur « FF » correspond à des trames « broadcast », tandis que la valeur « 01 » correspond à des trames « multicast ».

Exemples de trames

• « broadcast » : les ARP request, DHCP request, le protocole NETBIOS des réseaux Microsoft., les protocoles ISO …
• « multicast » : les protocoles de niveau 2 comme STP, CDP, VTP, etc, mais aussi certaines applications.

venons-en aux faits : la configuration

Avec le « storm-control », le flux « broadcast » et « multicast » qui entre dans le switch reste dans des limites acceptables.

Sur Catalyst 3750G, configurer sur toutes les interfaces :

• storm-control broadcast level 5.00 ! en % du débit de l'interface
• storm-control multicast level 5.00

Sur Catalyst 3750G, le « storm-control » laisse passer environ 1 million de trames avant de couper totalement le flux à l’origine de la tempête, ce qui stoppe radicalement la tempête. Mais elle va reprendre à la prochaine trame broadcast ou unicast… Et il y en a souvent ! Au final, le réseau subira des rafales intenses de trames indésirables.

Sur Catalyst 4500, configurer sur toutes les interfaces :

• storm-control broadcast include multicast
• storm-control broadcast level 5.00

Suir Catalyst 4500, le storm control limite le flux à la valeur indiquée. La tempête n’est pas stoppée, elle est limitée. On va dire que ce n’est plus une tempête, mais un courant d’air. Le traffic limité généré par la tempête est continuellement diffusé par le switch.

Il ne faut pas mettre des valeurs trop grandes. Par exemple, 10% d’un Gigabit Ethernet, ce serait trop, car cela fait 100% d’un FastEthernet !

conclusion

On voit que le storm-control permet d’atténuer considérablement les conséquences d’une boucle. Il y a de bonnes chances pour que le réseau local continue à fonctionner. Mais les applications qui tournent au dessus du réseau local peuvent souffrir d’un manque de bande passante. Les serveurs peuvent mal réagir quand ils reçoivent les trames générées par la tempête. Il faut bien évidement localiser l’origine de la boucle et la supprimer.

Doc Ethernet attend vos commentaires, remarques, compléments ...