AccueilCCNACCNA coursComment le Spanning-Tree vous évite bien des soucis!

Comment le Spanning-Tree vous évite bien des soucis !

Beau­coup de per­sonnes connaissent mal le pro­co­tole span­ning-tree car étant actif par défaut sur les switchs, on ne se sou­cie pas de son fonctionnement.

Mal­heu­reu­se­ment, comme tout pro­to­cole, on peut se retrou­ver avec des pro­blèmes réseaux à résoudre voir pire des bugs d’im­plé­men­ta­tion du pro­to­cole (sur­tout dans le cas d’in­ter-opé­ra­bi­li­té avec d’autres constructeurs).

A quoi sert-il ?

L’ob­jec­tif des réseaux est de faire en sorte que les paquets arrivent à des­ti­na­tion. Une solu­tion est de dupli­quer les équi­pe­ments phy­sique pour qu’en cas de panne sur l’un d’eux, l’autre équi­pe­ment prenne le relai ; on appelle ça la redon­dance ou la rési­lience.

Architecture non redondée

Sur le sché­ma ci-des­sus, on voit bien que si le switch tombe (panne élec­trique, bug…), plus aucune com­mu­ni­ca­tion entre les ordi­na­teurs A et B n’est possible.

Architecture redondée

Main­te­nant que l’on sou­haite que les paquets entre les ordi­na­teurs A et B tran­sitent même en cas de panne maté­riel, créons cette nou­velle architecture :

Avec cette archi­tec­ture, on voit bien que si le switch du haut ne fonc­tionne plus, le switch du bas peut tout même trans­mettre les paquets de A vers B et de B vers A.

Les 3 problèmes à savoir pour le CCNA

Lors de l’exa­men, vous allez tom­ber sur des ques­tions propre au fonc­tion­ne­ment intrin­sèque du span­ning-tree et de ses dif­fé­rentes ver­sions mais aus­si sur les pro­blèmes ren­con­trés par la mise en place d’une redon­dance phy­sique dans un LAN commuté.

Rete­nez bien ces 3 pro­blèmes car c’est une ques­tion clas­sique du CCNA.

1er problème : Tempète de broadcast

Sur l’ar­chi­tec­ture redon­dée pré­cé­dente, ima­gi­nons que la sta­tion A envoi un mes­sage de broad­cast (trame niveau 2 avec comme adresse MAC de des­ti­na­tion FFFF.FFFF.FFFF). Que se passe-t-il ?

  • Le switch du haut reçoit la trame sur son port, extrait l’a­dresse MAC de des­ti­na­tion (FFFF.FFFF.FFFF) et la duplique sur tous ses ports car c’est une adresse de broad­cast. La trame sort donc du switch du haut et se dirige vers le switch du bas
  • idem pour le switch du bas ; il reçoit la trame sur son port, extrait l’a­dresse MAC de des­ti­na­tion (FFFF.FFFF.FFFF) et la duplique sur tous ses ports car c’est une adresse de broad­cast. La trame sort donc du switch du bas et se dirige vers le switch du haut
  • et ces trames tournent sans arrêt entre les 2 switchs, fai­sant mon­ter leur CPU à 100% et les font plus ou moins plan­ter (sou­vent un reboot est nécessaire)
Ce phé­no­mène s’ap­pelle la tem­pête de broad­cast, ou broad­cast storm en anglais.

2ème problème : Duplication de trame

Main­te­nant, ima­gi­nons que la sta­tion A envoi une trame vers la sta­tion B, donc la trame sera for­gée avec les infor­ma­tions suivantes :

  • adresse MAC source : A
  • adresse MAC des­ti­na­tion : B

Que se passe-t-il ?

  • Le switch du haut reçoit la trame sur son port (flèche rouge), extrait l’a­dresse MAC de des­ti­na­tion (B) et la com­mute sur le port de droite. La sta­tion B reçoit bien la trame de la sta­tion A
  • Mais le switch du bas reçoit aus­si la trame sur son port (flèche orange), extrait l’a­dresse MAC de des­ti­na­tion (B) et la com­mute sur le port de droite. La sta­tion B reçoit donc pour une deuxième fois la trame de la sta­tion A
Ce phé­no­mène s’ap­pelle la dupli­ca­tion de trame (pas top comme opti­mi­sa­tion réseau 🙂 )

3ème problème : Instabilité de la table CAM

Main­te­nant, regar­dons un peu ce qu’il se passe côté table CAM – Content Addres­sable Memo­ry – du switch.

Pour ceux qui ont oublié cette notion, je vous ren­voi vers ce cha­pitre (switch).

Repre­nons la trame pré­cé­dente (mes­sage de A vers B):

  • la trame arrive sur le port 1 du switch du haut. Le switch extrait l’a­dresse MAC source et l’in­sère dans sa table CAM [port 1 = adresse MAC A]
  • la trame arrive aus­si sur le port 3 du switch du bas. Le switch extrait l’a­dresse MAC source et l’in­sère dans sa table CAM [port 3 = adresse MAC A]
Main­te­nant que chaque switch a extrait l’a­dresse MAC source pour l’in­sé­rer dans sa table, cha­cun extrait l’a­dresse MAC de des­ti­na­tion (B) et la com­pare à sa table. Comme aucune entrée n’est trou­vée, chaque switch va dupli­quer la trame sur tous ses ports :
  • le switch du haut envoi la trame sur son port 2
  • le switch du bas envoi la trame sur son port 4
Et c’est là où ça devient cocasse car chaque switch recoit la trame de l’autre switch…
  • le switch du haut reçoit sur son port 2 la trame du switch du bas
    • le switch extrait l’a­dresse MAC source et l’in­sère dans sa table CAM [port 2 = adresse MAC A]. Pour cela, il sup­prime l’en­trée pré­cé­dente qui était [port 1 = adresse MAC A]
  • le switch du bas reçoit sur son port 4 la trame du switch du haut 
    • le switch extrait l’a­dresse MAC source et l’in­sère dans sa table CAM [port 4 = adresse MAC A]. Pour cela, il sup­prime l’en­trée pré­cé­dente qui était [port 3 = adresse MAC A]

On voit ici que les switchs mettent à jour leur table CAM à chaque fois qu’ils reçoivent une trame.

Ce phé­no­mène s’ap­pelle l’insta­bi­li­té de la table CAM.

Résolution des 3 problèmes

Pour évi­ter ces 3 pro­blèmes (tem­pête de broad­cast, dupli­ca­tion de trame et insta­bi­li­té de la table CAM), le pro­to­cole span­ning-tree a été créé. Comme ces pro­blèmes pro­viennent du fait que le réseau com­mu­té est face à une boucle phy­sique, le span­ning-tree per­met d’i­den­ti­fier cette boucle et de la blo­quer « logiciellement ».

Dans notre exemple, tout le tra­fic pas­se­ra par le switch du haut pour joindre la sta­tion B, le che­min du bas étant blo­qué au niveau du port du switch du bas.

Si le switch du haut tombe en panne, le pro­to­cole span­ning-tree va le détec­ter et va déblo­quer le port du bas. A ce moment, tout le tra­fic pas­se­ra pour le switch du bas.

Voi­là à quoi sert le spanning-tree !

A retenir pour le CCNA

Dans un pro­chain cha­pitre, je détaille­rai en pro­fon­deur le fonc­tion­ne­ment de ce pro­to­cole et ses dif­fé­rentes ver­sions jus­qu’au MSTP .

Mais pour le moment, rete­nez que les points sui­vants pour l’examen :

  • en met­tant en place une archiec­ture redon­dée, on est face à 3 pro­blèmes majeurs :
    1. tem­pête de broadcast
    2. dupli­ca­tion de trame
    3. insta­bi­li­té de la table CAM
  • Pour résoudre ces pro­blèmes, le span­ning-tree a été créé et per­met d’é­vi­ter les boucles phy­siques en désac­ti­vant un port logi­ciel­le­ment, et le réa-active au besoin pour assu­rer la rési­lience du réseau

10 Commentaires

  1. Bon­jour, je ne com­prends pas bien le sché­ma de l’ar­chi­tec­ture redon­dée, est-ce que les switchs sont connec­tés entre eux via un câble ? 

    Mer­ci d’avance

    • Bon­jour Alex,
      oui les switchs sont bien connec­tés entre via un câble. Cela per­met d’a­voir une redon­dance dans le cas ou si un switch tombe en panne alors le second switch peut conti­nuer à trans­mettre les paquets reseau.

  2. Bon­jour pro­fes­seur, j’ai pris le ICDN1 guide pour mettre toutes les chances d emon coté, mais aus­si pr vous remer­cier et sup­por­ter votre site

    Bon article, ce serait bien d’a­voir un article simi­laire trai­tant du span­ning tree avec 2,3 com­mandes de bases à connaitre

    Le STP est bien dans le pro­gramme du CCENT / ICDN 1 ?

    car il est noté « Confi­gure, veri­fy, and trou­ble­shoot VLANs (nor­mal range) span­ning mul­tiple switches »

    ?

    • Bon­jour,
      Mer­ci pour ce commentaire !
      Oui c’est en cours de rédac­tion pour un article sur le spanning-tree.
      Le STP est bien dans ICND1 pour l’examen.

  3. Mer­ci !
    J’i­ma­gine la ques­tion » Choose three sta­te­ments about the pro­blem can hap­pen on the redun­dant architecture : »
    A. Broad­cast storm
    B. ****
    C. Dupli­cate of trame
    D. insta­bi­li­ty of the table cam

    • Bon­jour Gilles,
      J’ai pris exprès des numé­ros de ports dif­fé­rents entre le switch du haut et du bas pour plus de sim­pli­ci­té. Sinon j’au­rais du à chaque fois pre­ci­ser le « port 1 du switch du haut » ou le « port 1 du switch du bas »…

  4. Bon­jour,

    Juste pour t’in­di­quer qu’il y a une erreur dans la par­tie « 3ème pro­blème : Insta­bi­li­té de la table CAM » :

    Et c’est là où ça devient cocasse car chaque switch recoit la trame de l’autre switch…
    le switch du haut reçoit sur son port 3 la trame du switch du bas
    le switch extrait l’adresse MAC source et l’insère dans sa table CAM [port 3 = adresse MAC A]. Pour cela, il sup­prime l’entrée pré­cé­dente qui était [port 1 = adresse MAC A]

    Ne serait-ce pas plu­tôt le port 2 ?

    Je découvre ton site, et il m’a l’air plu­tôt inté­res­sant, merci.

    • Bon­jour Fred,

      Tu as tout à fait rai­son, il a une coquille qui s’est glis­sée en écri­vant l’article.
      Je viens de la cor­ri­ger. Mer­ci pour ton œil de Lynx !

Répondre à Cyril Annuler la réponse

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici

Les plus populaires