Découvrez Radia Perlman et comment le Spanning Tree Protocol empêche les boucles Ethernet, permet la redondance et a rendu les réseaux locaux stables et fiables.
Ethernet a commencé comme une façon simple de relier des ordinateurs dans le même bâtiment. À mesure qu’il s’est répandu dans des bureaux, des campus et des centres de données, les attentes ont changé : les réseaux locaux n’étaient plus seulement « agréables à avoir », ils sont devenus la plomberie pour les e‑mails, le partage de fichiers, les imprimantes, les téléphones et finalement des flux de travail entiers. Quand cette plomberie tombe en panne, tout en amont s’effondre.
Les concepteurs de réseaux ont aussi appris une leçon de fiabilité : si vous concevez un réseau avec un seul chemin entre les équipements, un câble ou un commutateur cassé peut couper toute une zone. La solution évidente est la redondance : des liens et commutateurs supplémentaires.
Au niveau 2 d’Ethernet, cependant, la redondance a un effet secondaire dangereux : les boucles.
Radia Perlman a conçu le Spanning Tree Protocol (STP), le mécanisme qui permet aux réseaux Ethernet d’avoir de la redondance sans fondre à cause des boucles. Sa contribution n’était pas de fournir des « tuyaux plus gros », mais une méthode distribuée et pratique permettant aux commutateurs de se coordonner, de s’accorder sur une structure d’acheminement sûre et de s’adapter automatiquement lorsque la topologie change.
STP est le genre de système qu’on ne remarque que lorsqu’il manque ou qu’il est mal configuré. Quand il fonctionne, rien ne semble spécial : le trafic circule, les liens restent actifs et le réseau tolère les pannes. Il bloque discrètement juste assez de chemins pour empêcher les boucles, tout en gardant des alternatives prêtes si un chemin actif se casse.
Nous rendrons le problème tangible en montrant à quoi ressemble une boucle Ethernet et pourquoi elle provoque des tempêtes et des pannes. Ensuite, nous expliquerons l’idée centrale derrière STP : comment il conserve la redondance tout en éliminant les boucles, et, en termes clairs, comment les commutateurs décident quels liens transmettent et lesquels restent en réserve. À la fin, vous aurez un modèle intuitif de pourquoi STP est devenu fondamental pour la commutation de couche 2, et pourquoi la conception de Perlman compte encore alors qu’Ethernet a largement dépassé ses racines de bureau.
Les premiers réseaux Ethernet étaient souvent petits et simples : quelques machines sur un segment partagé, ou plus tard, quelques commutateurs (et des « bridges », terme plus ancien) reliant des segments. Si un câble était débranché, on le remarquait — mais la panne était facile à comprendre.
Quand les organisations ont ajouté des salles, des étages et des bâtiments, le réseau n’a rarement grandi selon un plan net. Il a grandi comme un organisme vivant : un nouveau commutateur ici, un câble « d’urgence » là, un contournement temporaire devenu permanent.
Quand un réseau s’étend ainsi, des liens supplémentaires sont ajoutés pour des raisons pratiques :
Individuellement, chaque changement peut sembler inoffensif. Collectivement, ils peuvent créer plusieurs chemins entre les mêmes commutateurs.
La redondance est souhaitable car elle améliore la disponibilité. Si un lien échoue, le trafic peut emprunter un autre itinéraire et les utilisateurs restent productifs.
Mais au niveau 2 (commutation), Ethernet n’était pas conçu pour « choisir » automatiquement un chemin et ignorer les autres. Les commutateurs transmettent des trames en se basant sur des adresses apprises et, sans un plan de contrôle coordonné, plusieurs chemins peuvent former une boucle.
C’est la tension centrale : plus de câbles peuvent accidentellement casser le réseau. Les mêmes connexions ajoutées pour rendre le système plus sûr peuvent créer des conditions où le trafic circule indéfiniment, saturant les liens et les équipements. Spanning Tree a été créé pour conserver les bénéfices de la redondance tout en évitant ces pannes auto‑infligées à l’échelle du réseau.
Une boucle de commutation Ethernet se produit lorsqu’il existe deux (ou plusieurs) chemins actifs au niveau 2 entre les mêmes commutateurs — souvent parce que quelqu’un a ajouté un câble de secours, branché deux uplinks sur le même réseau ou connecté des commutateurs en anneau sans mécanisme de contrôle. Les trames n’ont pas de durée de vie au niveau 2, elles peuvent donc circuler indéfiniment.
Certaines trames sont destinées à être inondées : les diffusions (comme les requêtes ARP) et les trames « destination inconnue » (quand un commutateur ne sait pas encore quel port mène à une adresse MAC). Dans une boucle, cette trame inondée est copiée et renvoyée autour de la boucle, puis recopiée, encore et encore.
Un exemple simple : un poste demande « Qui a 10.0.0.5 ? » via ARP (diffusion). Avec une boucle, chaque commutateur répète la diffusion sur plusieurs ports, et les copies répétées reviennent aux autres commutateurs. Très vite, les liens et les CPU des commutateurs passent la majeure partie du temps à traiter des doublons, laissant peu de place au vrai trafic.
Les commutateurs apprennent où sont les équipements en observant sur quel port arrive une adresse MAC source. Dans une boucle, les trames du même équipement peuvent arriver sur des ports différents à quelques millisecondes d’intervalle. Le commutateur change sans cesse d’avis sur l’emplacement de cette MAC, réécrivant sa table à répétition. Le résultat : le trafic est envoyé sur le mauvais port, puis inondé, puis réappris incorrectement.
Ces effets se combinent en symptômes connus : ralentissements soudains à l’échelle du réseau, déconnexions intermittentes, téléphones coupant les appels, Wi‑Fi « fonctionnel mais inutilisable », et parfois une panne complète quand les commutateurs sont saturés et ne répondent plus. Un simple câble de brassage accidentel peut abattre bien plus que les deux appareils qu’il relie.
Ethernet tire sa résilience du fait d’avoir plus d’un chemin possible entre les commutateurs. Si un câble est coupé, le trafic peut emprunter un autre itinéraire. Le hic : des chemins supplémentaires peuvent accidentellement former un cercle — et les trames Ethernet n’ont pas de « time to live » pour les arrêter.
Spanning Tree Protocol (STP) résout cela par un compromis simple : garder les liens redondants physiquement connectés, mais en désactiver logiquement certains pour que le réseau actif forme un arbre sans boucle.
Imaginez une ville qui construit des routes supplémentaires pour que les ambulances puissent toujours atteindre chaque quartier en cas de fermeture. Si la ville ouvre toutes les routes sans règles, on peut créer des itinéraires circulaires où les conducteurs tournent en rond.
STP agit comme un contrôle de la circulation :
Un point clé de la conception de Radia Perlman est qu’elle ne repose pas sur un contrôleur central indiquant à chaque commutateur quoi faire. Chaque commutateur participe, échange de petits messages et arrive indépendamment à la même conclusion sur les liens à transmettre et ceux à garder en réserve.
Cela rend STP pratique dans des réseaux réels : on peut ajouter des commutateurs, supprimer des liens ou subir des pannes, et le réseau converge vers un motif d’acheminement sûr.
Bien mis en œuvre, STP offre deux résultats qui se contredisent normalement :
Le Spanning Tree Protocol (STP) a une mission : conserver la redondance Ethernet sans laisser le trafic tourner en boucle. Il le fait en faisant en sorte que tous les commutateurs s’accordent sur un ensemble « meilleur » de liens à utiliser à un instant donné — appelé arbre couvrant — et en mettant les liens excédentaires en état de secours.
STP élit d’abord un root bridge, le commutateur choisi comme point de référence pour tout le réseau. Pensez‑le comme « le centre de la carte ». Le root est déterminé par une valeur de priorité (configurée ou par défaut) et un identifiant unique ; le plus bas gagne.
Chaque commutateur se demande : « Quel est mon meilleur chemin vers le root ? » STP assigne un coût de chemin à chaque lien (les liens plus rapides ont généralement un coût inférieur). Chaque commutateur additionne les coûts le long des routes possibles et choisit le total le plus bas comme route préférée vers le root.
Le port qu’un commutateur non‑root utilise pour atteindre le root via ce meilleur chemin devient son root port.
Sur chaque connexion partagée entre commutateurs (un « segment »), STP a besoin d’un seul commutateur pour transmettre le trafic vers le root. Ce port transmetteur est le designated port pour le segment. Le commutateur annonçant le chemin de moindre coût vers le root sur ce segment obtient le rôle désigné.
Les ports qui ne sont ni root ports ni designated ports sont placés en blocking (STP) ou dans un état de non‑transmission similaire (variantes plus récentes). Bloquer ne supprime pas le câble ni n’élimine la redondance : cela empêche simplement le port de transmettre des trames Ethernet usuelles, afin qu’une boucle ne puisse pas se former. Si un lien actif échoue, STP peut débloquer un chemin de secours et maintenir la connectivité.
Rendons STP concret avec un petit réseau de quatre commutateurs :
STP commence par choisir un point de référence : le root bridge. Chaque commutateur annonce un identifiant (le « bridge ID »), et le plus bas ID gagne.
Supposons que S1 ait le bridge ID le plus bas. Maintenant tout le monde est d’accord : S1 est le root.
Chaque commutateur non‑root choisit exactement un port comme root port : le port qui fournit le meilleur chemin vers S1.
Pour chaque lien, STP choisit un côté comme designated port (le côté qui doit transmettre pour ce segment). Tout port qui n’est ni root port ni designated port devient blocking.
Dans cet exemple, le lien S3–S4 est l’endroit où la boucle est coupée. Si S3 atteint déjà le root via S2, STP peut mettre le port de S3 vers S4 (ou celui de S4 vers S3, selon le départage) en blocking.
Résultat : tous les câbles restent branchés, mais il n’y a qu’un seul chemin actif entre deux points — pas de boucle.
Si le chemin actif se casse (par exemple S2–S3 tombe), STP réévalue. Le lien précédemment bloqué S3–S4 peut passer en transmission, restaurant la connectivité via S3 → S4 → S1.
Ce changement n’est pas instantané ; STP a besoin de temps pour converger en toute sécurité et mettre à jour les états de transmission sans réintroduire de boucles.
Spanning Tree ne fonctionne que si chaque commutateur dans le réseau s’accorde sur les mêmes règles. C’est pourquoi les normes sont importantes : la plupart des réseaux réels sont multi‑fournisseurs, construits avec du matériel acheté sur plusieurs années. Sans protocole partagé, la « prévention de boucles » d’une marque pourrait être incompréhensible pour une autre, et la redondance deviendrait une panne.
Le Spanning Tree traditionnel est défini dans IEEE 802.1D. Vous n’avez pas besoin de lire la norme pour en tirer avantage : l’essentiel est que 802.1D donne un langage commun aux vendeurs pour élire un root bridge, calculer le coût de chemin et décider quels ports doivent transmettre ou bloquer.
Même si vous migrez vers des variantes plus récentes (comme RSTP ou MSTP), la possibilité d’upgrader repose sur la même idée : un comportement standardisé permet aux appareils de se coordonner plutôt que de deviner.
Les commutateurs se coordonnent en échangeant de petites trames de contrôle appelées BPDUs (Bridge Protocol Data Units). Pensez aux BPDUs comme aux messages « hello » du STP : elles véhiculent les informations nécessaires pour construire une vue partagée de la topologie — qui est le root, la distance (coût) et des paramètres temporels.
Parce que les BPDUs sont échangées en continu, STP peut réagir quand quelque chose change. Si un lien tombe, la conversation BPDU change aussi, et les commutateurs peuvent reconverger et ouvrir un chemin précédemment bloqué.
Un point pratique : les fournisseurs utilisent parfois des noms différents pour les mêmes réglages. Un paramètre comme « port cost », « edge/PortFast » ou « bpdu guard » peut apparaître dans des menus variés ou être formulé différemment. Les concepts STP sous‑jacents sont cohérents, mais le vocabulaire d’interface ne l’est pas — il est donc utile de ramener les fonctionnalités à ce que 802.1D cherche à accomplir.
Le STP classique (IEEE 802.1D) a résolu le problème des boucles, mais la « guérison » après une panne pouvait être péniblement lente. La raison est simple : STP était prudent. Les ports n’entraient pas immédiatement en transmission ; ils traversaient des états temporisés (blocking → listening → learning → forwarding). Avec les temporisations par défaut, la reconvergence pouvait prendre des dizaines de secondes (souvent ~30–50 s), assez pour qu’un appel vocal tombe, une application expire ou qu’un utilisateur pense que « le réseau est en panne ».
Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) conserve l’objectif — transmission sans boucles avec redondance — mais change la façon dont les commutateurs s’accordent.
Au lieu d’attendre de longs timers, RSTP utilise une poignée de main plus rapide entre commutateurs pour confirmer quels ports peuvent transmettre en sécurité.
En clair : RSTP bloque toujours les bons liens pour empêcher les boucles ; il traite juste chaque changement moins comme un cas catastrophe.
À mesure que les réseaux se sont agrandis, exécuter un seul arbre pour tout est devenu limitant — surtout avec de nombreux VLANs et des topologies complexes. Multiple Spanning Tree Protocol (MSTP, IEEE 802.1s) permet de créer plusieurs instances de spanning tree, et d’y mapper des groupes de VLANs.
Cela signifie que vous pouvez :
L’amélioration principale à travers STP → RSTP → MSTP est cohérente : garder la redondance, empêcher les boucles et rétablir la transmission plus vite et de façon plus prévisible.
Le bénéfice souvent sous‑estimé de Spanning Tree est de transformer « des câbles et commutateurs en plus » en une fiabilité prévisible. À l’échelle de l’entreprise — de nombreux placards, de nombreux commutateurs d’accès, des mouvements/ajouts/changes constants — la redondance de niveau 2 peut être un cadeau ou un piège. STP augmente les chances que ce soit le premier.
Les grands réseaux tombent rarement parce qu’un lien est coupé ; ils échouent parce que la récupération est chaotique. STP aide en fournissant une manière contrôlée pour le réseau de réagir lorsqu’un élément change :
Beaucoup d’organisations laissent STP activé même si elles pensent que leur topologie est sans boucle. La raison est pragmatique : les gens font des erreurs, la documentation se dégrade et des chemins Layer 2 inattendus apparaissent. Avec STP activé, un câble de brassage accidentel est plus susceptible de provoquer un port bloqué que de déclencher une panne d’un bâtiment entier.
Les datacenters modernes préfèrent souvent des architectures leaf–spine routées (couche 3) ou des technologies multi‑path Layer 2 spécifiques pour obtenir une bande passante active/active sans dépendre de la convergence STP classique. Cela dit, STP (ou des variantes comme RSTP/MSTP) reste largement utilisé dans les réseaux de campus, en périphérie et comme couche de compatibilité là où le pur Layer 3 n’est pas pratique.
À grande échelle, l’accomplissement réel de STP est autant opérationnel que technique : il rend la redondance gérable par des équipes ordinaires, pas seulement par des spécialistes.
STP est simple en concept — empêcher les boucles Layer 2 tout en gardant des chemins de secours — mais quelques mythes persistants poussent des équipes à le désactiver, le mal configurer ou l’« optimiser » jusqu’à provoquer une panne.
Il est vrai que les réseaux modernes s’appuient souvent sur le routage Layer 3, MLAG et des designs overlay qui réduisent le besoin du STP classique (IEEE 802.1D). Mais STP (ou ses formes récentes comme RSTP/MSTP) reste un filet de sécurité partout où Ethernet peut créer accidentellement une boucle : commutateurs d’accès, réseaux d’événements temporaires, laboratoires, sites distants et tout environnement où quelqu’un pourrait brancher deux ports ensemble « juste pour tester ».
Désactiver STP peut transformer une erreur de câblage bénigne en une tempête de diffusion qui prend en otage tout un VLAN.
Un port bloqué n’est pas « mort ». C’est un chemin de secours prévalidé. STP accepte volontairement de sacrifier une partie de la capacité active pour la stabilité : si le lien de transmission échoue, le lien bloqué peut devenir le nouveau chemin sans qu’un humain doive rebrancher des câbles.
Des équipes essaient parfois de forcer tous les liens à transmettre en désactivant STP, en aplatissant des VLANs ou en ajoutant des switches non‑gérés. Cela peut sembler efficace — jusqu’à la première boucle qui fait fondre le réseau.
La redondance n’aide que lorsqu’elle est conçue. Ajouter des liaisons transversales entre commutateurs sans planification augmente le nombre de scénarios de boucle possibles et rend le comportement STP plus difficile à prévoir. Le résultat peut être des chemins inattendus, des uplinks bloqués ou une reconvergence prolongée après une panne.
Même avec STP activé, de mauvais paramètres peuvent faire de gros dégâts :
Conclusion : STP n’est pas un simple checkbox — c’est un plan de contrôle. Traitez‑le comme tel, documentez vos intentions et validez les changements avant un déploiement large.
Les problèmes STP se manifestent souvent par un « le réseau est lent » avant que quelqu’un n’identifie un problème de niveau 2. Quelques vérifications ciblées peuvent épargner des heures de recherche.
Quand une boucle Ethernet ou une instabilité STP apparaît, on observe souvent :
Commencez par les fondamentaux :
La bonne hygiène STP est surtout une question de processus :
Si vous voulez une checklist plus large pour isoler des problèmes réseau au‑delà du STP, voir /blog/network-troubleshooting-basics.
STP est un exemple typique d’« infrastructure discrète » et il échoue souvent de façon très humaine : intention peu claire, câblage non documenté, configs incohérentes et dépannage ad‑hoc. Une manière pratique de réduire ce risque est de créer des outils légers internes et des runbooks autour de vos opérations STP.
Avec Koder.ai, les équipes peuvent rapidement coder de petits tableaux de bord web ou utilitaires depuis un simple chat : un outil qui ingère les sorties des commutateurs, met en évidence le root bridge actuel, signale des ports bloqués inattendus ou suit les événements de changement de topologie dans le temps. Comme Koder.ai permet d’exporter le code source et de déployer/ héberger des apps (avec rollback et snapshots), c’est aussi un moyen pratique de transformer le « savoir tribal » en un service interne maintenu plutôt qu’en script isolé sur l’ordinateur de quelqu’un.
Le travail de Radia Perlman sur le spanning tree rappelle que certaines des infrastructures les plus importantes ne sont pas tape‑à‑l’œil : elles empêchent simplement le chaos. En donnant à Ethernet un moyen pratique d’utiliser des liens redondants sans créer de boucles, STP a fait de l’ajout d’un chemin de secours un choix sûr plutôt qu’une expérience risquée. Ce changement a permis des réseaux de couche 2 plus larges et plus résilients dans les entreprises, les campus et les centres de données.
STP part du principe que quelque chose va mal tourner : un câble branché au mauvais endroit, un commutateur qui redémarre, un lien qui clignote. Plutôt que d’espérer que les opérateurs ne font pas d’erreurs, il construit un système capable d’absorber les erreurs et de converger vers un état sûr. La leçon dépasse le réseau : traitez les modes de défaillance comme des exigences de première classe.
Spanning Tree bloque volontairement certains liens pour que le réseau global reste stable. Cette « capacité non utilisée » est un arbitrage en faveur d’un comportement prévisible. Les bons systèmes réservent souvent des marges — temps, contrôles, garde‑fous — parce qu’éviter une panne catastrophique vaut mieux que grappiller le dernier pourcent de taux d’utilisation.
STP fonctionne parce que chaque commutateur suit les mêmes règles distribuées et échange de petits messages de contrôle pour s’accorder sur une topologie sans boucle. On n’a pas besoin d’un opérateur qui décide manuellement quels ports couper à chaque changement. Le message : quand de nombreux composants doivent coopérer, investissez dans des protocoles et des valeurs par défaut qui rendent le comportement sûr le plus simple à obtenir.
Si vous ne retenez que quelques points : construisez de la redondance, supposez l’erreur humaine et automatisez le « choix sûr ». Cet état d’esprit — plus que n’importe quelle fonctionnalité — explique pourquoi le spanning tree est devenu un essentiel discret.
Si vous voulez d’autres fondamentaux accessibles sur le réseau, parcourez /blog.
Une boucle de niveau 2 se produit lorsque des commutateurs disposent de deux chemins actifs (ou plus) entre les mêmes segments, formant un cycle. Comme les trames Ethernet n’ont pas de limite de saut au niveau 2, le trafic inondé (diffusions et unicasts inconnus) peut circuler indéfiniment et se multiplier, surchargeant les liens et les processeurs des commutateurs.
La redondance fournit des chemins alternatifs, mais sans coordination, les commutateurs peuvent transmettre sur tous ces chemins. Cela crée une boucle où les trames inondées sont dupliquées en boucle, entraînant des tempêtes de diffusion et une instabilité des apprentissages MAC — souvent une panne réseau globale déclenchée par un simple câble supplémentaire.
STP conserve physiquement les liens redondants mais désactive logiquement certains ports afin que la topologie active forme un arbre sans boucles. Si un chemin actif tombe, STP peut promouvoir un port précédemment bloqué en mode transmission pour restaurer la connectivité.
STP élit un root bridge comme point de référence pour tout le domaine de niveau 2. Le commutateur avec l'identifiant de bridge le plus bas (priorité + identifiant unique) devient le root ; choisir un commutateur de cœur/distribution prévu comme root permet de conserver des chemins de trafic prévisibles.
Chaque commutateur non-root sélectionne un root port : le port qui offre le coût de chemin total le plus bas vers le root. Le coût de chemin dépend de la vitesse du lien (les liens plus rapides ont généralement un coût plus faible). En cas d’égalité, des critères supplémentaires (IDs) servent de départage.
Pour chaque segment reliant deux commutateurs, STP choisit un designated port qui doit transmettre pour ce segment (le côté annonçant le meilleur chemin vers le root). Tout port qui n'est ni root port ni designated port devient bloquant/discarding, ce qui permet à STP de casser les boucles.
Cela signifie que le port n'émet pas les trames utilisateurs normales : il ne participe donc pas à une boucle. Le lien reste en place et peut transporter le trafic de contrôle STP ; si la topologie change (p. ex. une défaillance), ce port bloqué peut être promu en forwarding pour devenir le nouveau chemin actif.
Les BPDUs (Bridge Protocol Data Units) sont des trames de contrôle STP que les commutateurs s’envoient pour partager l’état topologique : qui est le root, le coût du chemin jusqu’au root, et des informations temporelles. En s’échangeant continuellement des BPDUs, les commutateurs détectent les changements et reconvergent vers une topologie sans boucle.
Le STP classique (IEEE 802.1D) peut mettre des dizaines de secondes à reconverger parce qu'il utilise des temporisations conservatrices et des états de port séquentiels. RSTP (802.1w) accélère cela avec des handshakes plus rapides et des transitions rapides (notamment pour les ports dits « edge/PortFast »), réduisant ainsi les interruptions après une panne.
Checklist pratique :
Pour un diagnostic plus large au-delà de STP, voir /blog/network-troubleshooting-basics.
