Spanning Tree – Théorie

Spanning Tree est l’un des principaux protocoles que l’on retrouve au niveau 2. Il permet d’éviter les boucles dans un réseau, mais aussi de profiter des topologies redondantes, sans risque de créer des boucles.

Voyons ensemble comment fonctionne ce protocole, mais aussi pourquoi il est nécessaire.

 

1) Problématique

 

Comme nous l’avons dit, Spanning Tree permet d’éviter les boucles réseau.

Les boucles réseau peuvent résulter d’une erreur, ou d’une topologie redondante.

En effet, afin de minimiser l’impact en cas de panne, nous pouvons chercher à redonder les liens et les équipements.

 

Voici un exemple de topologie redondante :

Spanning Tree Topologie

La perte d’un switch n’impactera que les utilisateurs qui y sont directement connectés, et non tout le réseau.

Bien entendu, il y aurait bien d’autres exemples de topologie redondante (cf : Entreprise Composit Network Model).

Sur la topologie précédente, nous sommes en présence d’une boucle.

En effet, les connexions entre les switchs forment une boucle.

 

Tempête de Broadcast

Voici le problème principal dans une topologie redondante.

On appel tempête de Broadcast, le fait que des messages de Broadcast tournent en rond.

 

Voyons un exemple.

 

Dans la topologie précédente, prenons l’exemple de PC 1 qui envoie un message en Broadcast.

Ce message va alors aller jusqu’à S1.

Comme c’est un message de Broadcast, S1 va le transmettre sur tous ses ports.

Le message va alors partir vers S2 et S3.

Considérons le message qui part vers S2.

Quand le message arrivera sur S2, il sera alors envoyé vers PC 2 et S3.

Arrivé sur S3, le message va alors aller vers PC 3 et S1.

Quand S1 va recevoir le Broadcast, il va l’envoyer à PC 1 et S2.

 

Et cela va continuer indéfiniment.

De plus, nous n’avons pris en compte que le message qui est allé vers S2 (au départ).

 

Au final le message circulera de cette façon (sans jamais s’arrêter):

L2 Broadcast Storm

Si les messages ne s’arrêtent jamais, les liens vont finir par être saturés (à force que des Broadcast s’ajoutent).

De plus, ce phénomène est très mauvais pour la CPU des switchs.

 

Lorsque qu’une boucle est créée, il suffit d’une seconde pour que le switch soit HS.

Plus aucun autre trafic ne pourra circuler.

 

Duplication de trame

Sur certaines topologies redondantes, les trames peuvent être dupliquées.

Nous nous retrouverons très rarement dans ce scénario car la tempête de Broadcast fera tomber le réseau bien avant.

De plus, il faut une topologie redondante d’un certain type.

En voici un exemple :

L2 Duplication de trame

Les PC sont connectés aux deux switchs (par un Hub, un dédoubleur, etc…)

 

Quand PC 1 enverra une trame à PC 2, celle-ci sera envoyée à S1 et S2. Ces derniers vont ensuite envoyer la trame à PC 2.

PC 2 aura donc reçu la trame 2 fois.

 

Instabilité des tables CAM

La table CAM – Content Addressable Memory, est une table dans laquelle le switch garde une correspondance du type « Adresse MAC A -> derrière port 1 »

C’est grâce à cette table que le switch saura sur quel port transmettre les trames qu’il reçoit.

Reprenons l’exemple précédent : PC1 envoie un message à PC 2.

Le message va jusqu’aux switchs S1 et S2.

Ceux-ci vont alors envoyer la trame vers PC2.

Sauf que le message arrivera aussi au deuxième switch.

Par exemple, S2 transmet la trame vers PC2, et celle-ci arrive aussi sur S1 – port 2.

 

A ce moment-là, S1 va noter dans sa table CAM, que PC1 (son adresse MAC), se trouve derrière le port 2 (et non plus derrière le port 1).

Les tables CAM de S1 et S2 seront alors faussées.

 

2) Le rôle de Spanning Tree

 

Parlons maintenant de la solution.

Spanning Tree aura pour rôle de désactiver les liens qui peuvent créer une boucle. Il se chargera le les réactiver si nécessaire (en cas de panne d’un autre lien).

 

Revenons sur notre premier exemple. La topologie ressemblera alors à ceci :

Spanning Tree Topologie

Les switchs vont se mettre d’accord sur les ports à désactiver, de manière à supprimer le risque de boucle.

Si nécessaire, Spanning Tree réactivera le port.

Par exemple, si le lien S1 – S2 tombe, le lien S1 – S3 sera automatiquement réactivé.

 

Nous pouvons donc profiter de la redondance.

Nous verrons plus tard que Spanning Tree peut aussi répartir la charge en utilisant les liens redondants (répartition en fonction des VLAN).

 

3) BPDU et Root Bridge

 

Afin de détecter les boucles, les switchs émettent des messages appelés BPDU – Bridge Protocol Data Units.

Les BPDU vont permettre de découvrir la topologie, et d’élire le Root Bridge.

 

Le Root Bridge est en quelque sorte le chef de la topologie Spanning Tree.

Une fois le Root Bridge élu, les switchs vont rechercher le meilleur chemin vers le Root Bridge.

Les chemins redondants seront désactivés.

En d’autres termes, les switchs vont chercher le port avec la métrique la plus faible vers le Root Bridge, puis ils vont couper les autres ports.

Nous verrons plus tard, que pour trouver le meilleur chemin, les switchs utilisent le coût de chaque lien traversé.

 

Prenons un exemple :

Spanning Tree Topologie

Dans cette topologie, il y a des liens redondants.

Considérons que S3 est élu Root Bridge.

S1, S2 et S4 vont chercher le meilleur chemin vers S3.

En toute logique, ils vont choisir un lien direct vers S3 (nous reviendrons sur ce choix juste après).

Nous obtiendrons alors ceci :

Spanning Tree Topologie

Il n’y a plus de boucle.

 

Revenons sur l’élection du Root Bridge. Comment est-il choisi ?

Les messages BPDU contienne le Bridge ID.

Le Bridge ID est composé de la priorité du switch + son adresse MAC.

Spanning Tree Bridge ID

La priorité est de 32768 par défaut. Elle peut être modifiée pour influencer l’élection.

Elle peut aller de 0 à 61440.

 

Pour gagner l’élection, le switch doit avoir le BID le plus bas.

C’est donc le switch avec la priorité la plus basse qui gagnera.

En cas d’égalité (ou si la priorité est partout à sa valeur par défaut), c’est le switch avec l’adresse MAC la plus basse qui gagnera.

Au final, si nous ne changeons pas la priorité, le Root Bridge sera choisi de manière « arbitraire ».

 

Il existe 3 types de BPDU :

  • BPDU de configuration, utilisé pour le calcul de Spanning Tree
  • BPDU de notification de changement (TCN – Topology Change Notification BPDU), utilisé quand la topologie change
  • BPDU d’acquittement de changement

 

Les BPDU sont envoyés en Multicast sur l’adresse 01:80:C2:00:00:00

 

Les BPDU de configuration contiennent l’ID du switch qui envoie le message, l’ID du port, le coût du lien.

 

Les BPDU de changement sont envoyés par l’un des switchs lorsque la topologie change.

Ensuite, le Root Bridge va envoyer un BPDU de configuration à tout le monde.

 

Le BPDU d’acquittement se fait en réponse au BPDU de changement.

 

4) Les Types de Ports

 

En Spanning Tree, les ports peuvent avoir 3 rôles :

  • Root Port : port offrant le meilleur chemin vers le Root Bridge
  • Designated Port : il faut un et un seul port désigné par lien
  • Blocking : port bloqué par Spanning Tree (les ports non Root ou Designated sont bloqués)

 

Voici notre topologie précédente avec les rôles des ports :

Spanning Tree Topologie

 

5) Trouver le meilleur chemin

 

Pour que les switchs trouvent le meilleur chemin vers le Root Bridge, ils se basent sur le coût de chaque lien.

Spanning Tree défini un coût en fonction du type de lien.

Voici le tableau récapitulatif :

Spanning Tree Link Cost

Ensuite, les switchs vont additionner les coûts de tous les liens jusqu’au Root Bridge, pour en déduire le meilleur chemin, et donc le Root Port.

Voici notre topologie précédente avec les coûts :

Spanning Tree Topologie

Si le switch a le choix entre deux chemins équivalents, il va les départager grâce au Bridge ID.

Le voisin avec le plus petit BID gagnera.

Spanning Tree Topologie

S’il y a toujours égalité (deux liens entre deux switch), c’est le port avec le numéro le plus bas qui sera privilégié.

Spanning Tree Topologie

 

Autre question qui se pose, comment choisir le port à bloquer sur un lien ?

Spanning Tree Topologie

Dans ce schéma il y a un lien bloqué entre S1 et S4 (en raison du coût).

Seul le port Fa 0/2 de S1 est bloqué. Il n’est pas possible de bloquer aussi le port FA 0/2 de S4, car il faut obligatoirement qu’il y ai un port Designated sur chaque lien.

 

Mais alors pourquoi bloquer le port de S1 et pas celui de S4 ?

S1 ayant le BID le plus haut, c’est lui qui devra passer son port en Blocking.

S4 garde son port en Designated pour la raison précédemment citée.

 

6) Procesus Spanning Tree

 

Résumons un peu tout cela.

La première action des Switchs en Spanning Tree, c’est d’élire le Root Bridge.

Pour cela, les switchs se basent sur le BID – Bridge ID, contenu dans les BPDU.

Le Root Bridge sera le switch avec le BID le plus faible.

 

Ce dernier est composé de la priorité et de l’adresse MAC.

Il est donc possible de choisir nous même le Root Bridge, simplement en modifiant la priorité du Switch voulu.

 

Une fois le Root Bridge choisi, les switchs vont chercher le meilleur lien vers ce dernier.

Pour cela, les switchs cumulent les coûts des liens vers le Root Bridge.

Les liens restants et qui causent des boucles seront désactivés.

 

Les ports peuvent avoir 3 rôles :

  • Root
  • Designated
  • Blocking

Pour rappel, il y a toujours un et un seul Designated Port par lien.

De plus, le Root Bridge n’a que des ports Designated.

Enfin, il n’est pas possible de mettre un port Blocking sur le même lien qu’un port Root.

 

Au final, notre topologie se retrouve dans un état stable.

En cas de panne d’un lien, Spanning Tree se chargera de réactiver un des liens bloqués, afin maintenir la connectivité.

Il y aura néanmoins une interruption de service.

 

7) Peer VLAN Spanning Tree

 

Il existe une variante de Spanning Tree appelée Peer VLAN Spanning Tree.

Le principe est simple : il y a un Root Bridge par VLAN.

Ce qui fait que tous les liens seront utilisés, mais pas par les mêmes VLAN.

Au final, la charge sera mieux répartie.

 

Voici un exemple du résultat :

Spanning Tree Topologie

Le BID en PVLAN STP sera le suivant :

Per-VLAN Spanning Tree Bridge ID

8) Etats des ports en Spanning Tree

 

En Spanning Tree, les ports peuvent avoir 4 états.

Les voici :

Etats des ports en Spanning Tree

Au tout départ, le switch est en mode Listening. Il se contente d’envoyer et de recevoir des BPDU.

Le but est ici de trouver le Root Bridge, choisir le rôle des ports, etc…

 

Ensuite, le port passe en Learning.

Le but est simplement d’apprendre des adresses MAC, de manière à remplir la table CAM.

 

Quand tout est bon, le port passe en Forwarding.

 

Le port peut aussi être dans l’état bloqué. Cela va de pair avec le rôle Blocking.

Pour sortir le port de ce mode (si nécessaire) il faudra attendre 20 secondes.

Le switch va attendre ce temps de manière à s’assurer qu’il est bien nécessaire de remonter le port.

Par exemple, s’il y a une panne de 5 secondes sur la topologie Spanning Tree, le port ne sera pas réactivé.

 

Pour faire simple, quand on branche deux switch ensemble, il faudra attendre 30 secondes avant que le lien soit UP.

Il en va de même si l’on branche un PC à un switch.

En cas de panne il faudra attendre 20 secondes pour qu’un lien de secours (ou plutôt le port associé) passe à l’état Listening. Puis 30 secondes de plus pour que le lien monte.

 

Le constat est simple : Spanning Tree est très lent !

 

Ce qui nous amène vers les deux dernières notions : Portfast et Rapid Spanning Tree.

 

9) Portfast

 

Portfast est une fonctionnalité à activer sur les ports faisant face à des PC, Serveur, etc…

Cela va tout simplement désactiver Spanning Tree sur le port en question.

Le résultat est simple :

  • Plus de BPDU envoyé
  • Plus d’état Spanning Tree –> activation du port immédiate

 

Cette fonctionnalité est indispensable sur les ports qui font face à des PC.

Sinon, les ports mettront 30s à répondre lorsque l’on y connectera un PC. Cela donnera l’impression que le port ne fonctionne pas.

Portfast ne fonctionne pas sur les liens Trunk, ce qui est logique. En effet Portfast ne doit pas être utilisé entre des switchs.

 

10) Rapid Spanning Tree

 

Rapid Spanning Tree est un protocole standard qui est apparu suite à une version propriétaire Cisco.

Pour faire simple, RSTP est beaucoup plus rapide que le Spanning Tree classique.

Les Timers ont été réduits ou supprimés.

Des BPDU sont envoyés tous les HELLO-Time (2s par défaut).

 

Etats des ports

Les états de port en RSTP sont un peu différents.

Etats des ports en Rapid Spanning Tree

L’état Listening a disparu.

L’état Learning est relativement court.

Quand un port est en mode Discarding, il peut très rapidement passer en mode Forwarding.

 

Rôles des ports

En Rapid Spanning Tree, les ports peuvent avoir 3 rôles :

  • Root Port : port offrant le meilleur chemin vers le Root Bridge
  • Designated Port : il faut un et un seul port désigné par lien
  • Alternate Port : port bloqué par Spanning Tree, mais qui peut très rapidement passer en Forwarding en cas de panne
  • Edge Port : n’est pas connecté à un switch (équivalent du Portfast)

 

11) Autres variantes de STP

 

Il existe différentes variante de STP.

Pour faire simple, il y a une série Cisco, et une standard. Dans chaque série il existe différentes versions.

Voici un tableau les résumant :

Tableau des Protocoles Spanning Tree

12) Conclusion

 

Nous voici arrivés au terme de cette longue présentation du protocole Spanning Tree.

Nous avons eu l’occasion de voir à quoi sert Spanning Tree (et les risques de ne pas l’utiliser), comment les liens à désactiver sont choisis, les rôles et états des ports, mais aussi des variantes au protocole Spanning Tree de base.

Une fois toutes ces notions théoriques assimilées, je vous invite à jeter un œil à l’article traitant de la pratique.

 

Tagués avec : , , , , , ,
Publié dans Spanning Tree
9 commentaires pour “Spanning Tree – Théorie
  1. Ryka dit :

    Super ! Clair !
    Si je l avais lu plus tôt je me serais évité une bonne galère.

    Ryk
    Novice !

  2. Jeantantou dit :

    Merci d’avoir publier cet article.
    ça m’a bien éclairé sur le sujet.

    Vous êtes maintenant dans mes « Favoris » 😉

    Jeantantou.

  3. rabihfad dit :

    Bonjour,
    je tiens à te remercier vivement de ces éclaircissement, je vois les choses en clair

  4. Julien dit :

    Merci pour ces explications, très bon travail.
    J’ai tout de même une question, que se passe-t-il lorsque l’on ajoute un switch ?

    Est-ce que tout le processus de spanning tree est reexecuté sur tout le lan ?
    Et ainsi bloque le traffic durant une 50 de secondes ?

    Merci pour vos réponses.

    • Valentin Weber dit :

      Bonjour Julien,

      Il y a deux scénarios possibles. Soit le nouveau switch à un BID plus faible que les switchs existants, soit il a un BID plus élevé.
      Pour rappel le BID correspond à la priorité + l’adresse MAC. De base la priorité est de 32768. Le BID le plus faible gagne.

      Donc si le nouveau switch a un BID plus faible que les autres, il va devenir Root Bridge, ce qui va causer un recalcule du processus STP et donc une coupure. En RSTP la coupure sera courte et dépendra surtout de l’architecture.

      Mais si le nouveau switch a un BID plus élevé que les switchs existants, il n’y aura pas de recalcule. De plus, en RSTP le lien vers le nouveau switch montera rapidement.

      Lors-ce que ‘on ajoute un switch dans une topologie STP, il faut forcer sa priorité STP à une valeur adéquate, pour s’assurer qu’il prenne le rôle STP voulu.

  5. Julien dit :

    Merci pour ce complément d’informations.

    Merci pour ta réponse.

    Je dois justement ajouter une pile de 3750-x sur un lan.

    Je pense passer sur tout les équipements et les passer en rstp, puis ensuite brancher les nouveaux équipements.
    Ainsi, je limiterais le temps d’interruption. Oui/non ? (Car les 3750 ont pour vocation de passer rootbridge)

    Je profite de ton savoir, pas d’effet de bord à basculer de stp vers rstp ?

    En tout cas, encore merci pour ton travail, depuis que j’ai Découvert ton site, j’abuse de tes articles 🙂

    • Valentin Weber dit :

      Le passage du STP au RSTP risque de causer une coupure. Théoriquement les deux protocoles peuvent coexister. C’est à dire qu’un switch en RSTP peut dialoguer avec un switch en STP, mais seulement à la vitesse STP.
      L’idéal est donc de passer tous les switch en RSTP à l’avance, puis d’ajouter les 3750, en configurant les priorités correctement sur tout le réseau, de manière à arriver à la topologie cible.
      De toute évidence, il faut programmer l’intervention à une heure où le réseau n’est pas utilisé.
      Prévoir aussi un accès console aux switchs si jamais cela se passe mal.
      Et comme toujours pour ce type d’intervention, tout préparer à l’avance : le plan de bascule avec chaque étape, les commandes à passer, les vérifications, une procédure de retour arrière si jamais, etc… Et pourquoi-pas tester la tolérance de panne et la bascule RSTP une fois l’infrastructure en place.
      Et bien entendu, si les 3750 passent Root Bridge, il faut qu’ils soient placés stratégiquement sur le réseau, pour qu’ils aient un intérêt à être Root Bridge. Le secondary doit aussi être placé stratégiquement.

  6. Julien dit :

    Noté, la méthode décrite est celle que je mets en place.
    Merci encore pour tes conseils.

  7. ZAKARIA dit :

    SUPER, Merci bcpppp

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Le temps imparti est dépassé. Merci de saisir de nouveau le CAPTCHA.