21/05/2026
Jeudi matin. Colmar. BON Industrie, une PME qui usine des pièces mécaniques de précision. Une cinquantaine de salariés répartis entre l’atelier, le bureau d’études, la compta et la direction.
8h17. Les téléphones sonnent tous en même temps.
La production ne scanne plus les pièces. La compta n’atteint plus le serveur. Le bureau d’études a perdu sa connexion au NAS.
Et dans le local technique, les LEDs des switchs clignotent comme les illuminations du marché de Noël. Sauf que là, personne ne trouve ça féérique.
En moins de 2 minutes, tout le réseau de l’usine vient de tomber.
Le coupable ? Pas une cyberattaque. Pas une panne matérielle. Un câble. Un seul câble de trop.
Voici, étape par étape, ce que Stéphane — l’admin réseau de la boîte — a vu, compris et fait. Et surtout : ce que tu dois retenir pour que ça ne t’arrive jamais.
Le symptôme : une “tempête de broadcast”
EDOUARD arrive dans le local technique et comprend tout de suite. Les LEDs des trois switchs de distribution clignotent à une fréquence anormale. Pas le clignotement tranquille du trafic normal. Un clignotement frénétique, continu, sur tous les ports en même temps.
Ce symptôme a un nom : la broadcast storm, la tempête de broadcast.
Pour comprendre, reviens aux bases.
Dans un réseau commuté, quand une trame arrive sur un port, le switch la renvoie vers le bon port de destination. Mais quand c’est une trame de broadcast — une trame destinée à tout le monde, comme une requête ARP ou DHCP — le switch la renvoie sur tous ses ports. C’est normal, c’est comme ça que le réseau fonctionne.
Le problème, c’est quand il existe une boucle physique : deux switchs reliés par deux chemins différents.
Là, la trame de broadcast part du switch A, arrive sur le switch B, qui la renvoie sur tous ses ports… y compris celui qui revient vers A. A la reçoit, la renvoie à nouveau. Et ainsi de suite. À l’infini.
C’est un rond-point sans sortie. Les voitures tournent, et à chaque tour il y en a plus. Sauf qu’ici les voitures, ce sont tes trames réseau. Et le rond-point, c’est ton infrastructure.
En quelques secondes, les switchs montent à 99 % de CPU. Plus rien ne passe.
Le diagnostic : un chef de réseau désigné par hasard
Stéphane branche un câble console sur le switch central (SW-Core) et lance les commandes de référence :
show processes cpu → 98 % de CPU, le switch est noyé
show spanning-tree vlan 1 → l'état du Spanning Tree
Et là, premier choc : le root bridge du réseau n’est pas SW-Core.
Petit rappel, parce que c’est LE concept à comprendre.
Le Spanning Tree Protocol (STP) sert justement à éviter les boucles. Son principe : il élit un “chef” parmi tous les switchs — le root bridge — puis tous les autres calculent le chemin le plus court vers lui et bloquent automatiquement les ports qui créeraient une boucle.
L’élection se joue sur la priorité. Par défaut, tous les switchs sont à 32768. Le switch avec la priorité la plus basse gagne. Et en cas d’égalité ? C’est celui qui a l’adresse MAC la plus basse qui l’emporte.
Le souci chez Bonet : personne n’a jamais configuré les priorités. Tous les switchs sont à 32768. Donc l’élection s’est jouée sur la MAC la plus basse.
Le gagnant ? Un vieux Catalyst 2950 planqué dans un placard de l’atelier depuis 7 ans. Le switch le plus lent, le plus vieux, le moins bien placé de toute l’infra.
C’est comme si l’organigramme de l’entreprise avait élu PDG le stagiaire de 2018, juste parce que son nom de famille commence par un A.
La source : le switch qui ne parle à personne
Mais ça n’explique pas encore la boucle. Stéphane descend à l’atelier.
Et il trouve. Un technicien de maintenance a branché un petit switch non managé à 15 € pour connecter une nouvelle machine de mesure. Sauf qu’il a utilisé deux câbles : un vers une prise murale d’un côté, un autre vers une prise de l’autre côté de l’atelier. Les deux remontent vers le même switch de distribution.
Deux câbles. Deux chemins. Une boucle physique.
Pourquoi le STP n’a pas géré ? Parce que ce switch à 15 € est non managé. Pour s’auto-organiser, les switchs intelligents s’échangent en permanence des petits messages appelés BPDU (Bridge Protocol Data Unit) — une sorte de talkie-walkie entre agents de circulation, où chacun annonce sa priorité et le chemin vers le root bridge.
Le switch à 15 € ne sait pas ce qu’est un BPDU. Il ne les envoie pas, ne les comprend pas. Il renvoie tout, comme un bon petit soldat aveugle. Et un soldat aveugle planté au milieu d’un rond-point… tourne en rond.
Pour ne rien arranger : le STP classique (802.1D) peut mettre jusqu’à 50 secondes à converger. La boucle s’est formée plus vite que le protocole n’a pu réagir.
La résolution : 3 étapes, dans cet ordre
1. Éteindre l’incendie. Stéphane débranche un des deux câbles du switch pirate. Immédiatement, les LEDs se calment. Le CPU redescend. Le réseau respire.
2. Reprendre le contrôle du root bridge. SW-Core doit redevenir le chef — c’est lui le mieux connecté et le plus performant. La commande :
spanning-tree vlan 1 root primary
Ce raccourci Cisco regarde la priorité actuelle du root et se met juste en dessous (en général 24576, un cran sous le défaut). Résultat : SW-Core gagne l’élection. Vérification avec show spanning-tree vlan 1 → le fameux “This bridge is the root”.
3. Verrouiller les ports d’accès pour de bon. Le vrai problème de fond : n’importe qui peut rebrancher un switch et recréer une boucle. La parade, c’est le combo PortFast + BPDU Guard :
spanning-tree portfast default
spanning-tree portfast bpduguard default
PortFast : le port passe direct en forwarding (pour les PC, imprimantes, équipements terminaux — pas pour des switchs).
BPDU Guard : si un port en PortFast reçoit un BPDU — donc si quelqu’un branche un switch dessus — le port se coupe net (err-disable). Aucune boucle possible.
CPU redescendu à 12 %. La prod scanne à nouveau. La compta accède au serveur. Le bureau d’études retrouve son NAS.
La vraie leçon (et elle ne parle pas de câbles)
Le coupable n’était pas le technicien qui a branché deux câbles. Le coupable, c’était :
un réseau sans documentation (un prédécesseur parti sans laisser la moindre trace),
des priorités jamais configurées (le root bridge tiré au sort),
des ports d’accès non protégés.
Un réseau sans STP bien configuré, c’est un château de cartes. Ça tient debout… jusqu’au jour où quelqu’un éternue.
La dernière action de EDOUARD n’a pas été une commande. Il a ouvert un fichier texte et documenté toute la topologie : switchs, ports, liens, root bridge, priorités. Tout. Parce que la prochaine personne dans ce local ne doit pas hériter du même château de cartes.
