14h03, tout va bien. 14h04, plus rien ne répond. Les téléphones IP grésillent, les partages réseau tombent, les voyants des switches clignotent tous en même temps comme un sapin de Noël pris de folie. Personne n'a rien débranché. Ce que tu vis, c'est une tempête de broadcast. Ton réseau s'étouffe tout seul.

La tempête de broadcast, c'est quoi ? C'est le moment où une simple trame diffusée à tout le monde se met à tourner en boucle et à se multiplier jusqu'à saturer le réseau en quelques secondes. Pour la comprendre, oublie les schémas : pense à un micro qu'on approche trop près de son enceinte. On va voir ce qui déclenche ce hurlement, d'où il vient, et comment on le coupe. Et à la fin, tu le provoques toi-même dans Packet Tracer, en sécurité, pour le voir de tes yeux.

Tempête de broadcast : c'est quoi, au juste ?

Une tempête de broadcast, c'est une trame de diffusion (un message envoyé à "tout le monde" sur le réseau local) qui, au lieu d'être livrée une fois et oubliée, se met à repasser en boucle de switch en switch. Chaque switch la recopie sur tous ses ports. Un autre switch la reçoit, la recopie à son tour, la renvoie au premier, qui la recopie encore. En une poignée de secondes, il n'y a plus de place pour le trafic utile. Le réseau ne transporte plus que sa propre panique.

Voilà l'image à garder : l'effet Larsen. Tu connais ce hurlement strident quand un chanteur colle son micro contre l'enceinte. Le micro capte le son de l'enceinte, l'envoie à l'ampli, l'ampli le ressort par l'enceinte, le micro le recapte, en plus fort. La boucle s'auto-alimente jusqu'au cri. Une tempête de broadcast, c'est le Larsen du réseau : une trame qui se réentend elle-même et monte en puissance jusqu'à ce que tout sature.

Pourquoi ça s'emballe si vite ?

À l'étage où circulent ces trames (la couche 2, celle des adresses MAC et des switches), il manque un truc que le grand internet possède : un compteur de durée de vie. Sur internet, chaque paquet a un TTL, un nombre de sauts maximum. À zéro, poubelle. Ça évite qu'un paquet erre pour toujours.

La trame de broadcast en couche 2 n'a pas ce garde-fou. Rien ne lui dit "tu as assez tourné, tu meurs". Alors tant qu'il existe un chemin qui la ramène à son point de départ, elle tourne. Et comme chaque tour la duplique sur tous les ports, ça ne fait pas que tourner : ça grossit. C'est exactement pour ça que le multicast existe, d'ailleurs. Plutôt que d'arroser tout le monde comme le broadcast, le multicast ne livre qu'aux abonnés. Moins de bruit, moins de risque.

D'où vient la boucle ?

Le Larsen a besoin que le micro "voie" l'enceinte. La tempête a besoin d'une boucle physique. Et dans 90% des cas, la boucle, c'est une bête erreur humaine :

• Deux câbles entre les deux mêmes switches, au lieu d'un seul. Quelqu'un a voulu "faire une sauvegarde" du lien. Il a fabriqué un anneau.
• Un câble dont les deux bouts finissent sur la même prise murale, en salle de réu.
• Un petit switch de bureau rebranché sur deux prises du réseau par un utilisateur qui range son bazar.

Un seul de ces gestes, et le chemin de retour existe. Le micro voit l'enceinte. Il ne manque plus qu'une trame de broadcast pour lancer le hurlement, et il y en a en permanence.

Le remède : STP, l'ingé son qui coupe un chemin

Sur un concert, l'ingénieur du son ne casse pas le micro : il coupe la boucle. Il baisse le retour, il éloigne l'enceinte, il ferme le chemin qui provoque le Larsen. Sur un réseau, ce rôle est joué par STP (Spanning Tree Protocol).

STP regarde la topologie, repère les chemins qui forment un anneau, et en bloque juste ce qu'il faut pour qu'il n'en reste plus aucun. Le câble de secours est toujours là, physiquement branché, mais mis en veille. Si le lien principal tombe, STP réveille le lien bloqué en quelques secondes. Tu gardes ta redondance, sans le Larsen. Sur les réseaux qui transportent beaucoup de diffusion, on ajoute souvent une seconde ceinture de sécurité, le storm control : le switch surveille le volume de broadcast sur un port et coupe le robinet s'il explose un seuil. STP empêche la boucle, le storm control amortit les pics.

Question avant la pratique : à ton avis, combien de temps met un réseau sans STP pour tomber, une fois la boucle en place ? Une minute ? Dix ? Fais le TP, tu vas être surpris de la vitesse.

Le TP : provoque une tempête de broadcast (et coupe-la) dans Packet Tracer

Objectif : créer une boucle, voir le réseau s'affoler, puis le sauver avec STP. En simulateur, donc zéro risque.

Prérequis : Cisco Packet Tracer, gratuit. C'est un vrai TP réseau, pas une commande Windows.

1. Pose deux switches (2960 par exemple) et deux PC, un PC par switch.
2. Relie les deux switches par DEUX câbles cuivre droits, sur des ports différents. Tu viens de créer la boucle.
3. Désactive STP sur les deux switches pour l'expérience : configure terminal puis no spanning-tree vlan 1.
4. Regarde les voyants des liens entre switches. Ils passent au vert puis se mettent à clignoter en orange sans s'arrêter : les trames tournent.
5. Depuis un PC, envoie un ping en broadcast (ping 255.255.255.255) ou une simple requête, et observe l'activité exploser.
6. Maintenant, sauve le réseau : réactive STP avec spanning-tree vlan 1 sur les deux switches. Attends une trentaine de secondes.
7. Un des deux liens passe en mode bloqué (voyant orange fixe). La boucle est coupée, le calme revient.

Auto-vérification : si, STP désactivé, tes liens inter-switches clignotent sans repos et que tout se calme dès que tu réactives STP (un lien passe orange fixe), tu viens de reproduire et de guérir une tempête de broadcast. Tu as vu le Larsen, et tu as coupé le micro.

FAQ : la tempête de broadcast en clair

Qu'est-ce qui cause une tempête de broadcast ?

Presque toujours une boucle physique en couche 2 : deux chemins entre les mêmes switches sans STP pour en bloquer un. Les trames de diffusion tournent alors en boucle et se multiplient, car il n'y a pas de TTL pour les arrêter.

Comment savoir si mon réseau subit une tempête de broadcast ?

Signes typiques : tout ralentit ou tombe d'un coup, sans cause évidente, et les voyants d'activité des switches clignotent frénétiquement et en même temps. Le trafic utile n'arrive plus à passer.

STP suffit-il à empêcher une tempête de broadcast ?

Dans la grande majorité des cas, oui : STP casse les boucles avant qu'elles ne deviennent une tempête. On le double souvent de storm control pour amortir les pics de diffusion, ceinture et bretelles.

Quelle différence entre une boucle réseau et une tempête de broadcast ?

La boucle est la cause (un chemin physique en anneau), la tempête est la conséquence (les trames de diffusion qui s'y multiplient jusqu'à saturer). Pas de boucle, pas de tempête.

C'est quoi le storm control ?

Une fonction du switch qui surveille le volume de trafic broadcast (ou multicast) sur un port et le coupe ou l'alarme s'il dépasse un seuil. Un pare-feu anti-débordement, en complément de STP.

Un réseau qui ne s'écoute pas hurler

Retiens le Larsen : une trame qui se réentend et monte jusqu'au cri, faute de quelqu'un pour couper la boucle. STP est ce quelqu'un. Comprendre ça, savoir le reproduire et le corriger, c'est exactement le genre de réflexe qui sépare celui qui subit la panne de celui qu'on appelle pour la régler. Et ce métier-là, il s'apprend.