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

6

Beaucoup de personnes connaissent mal le procotole spanning-tree car étant actif par défaut sur les switchs, on ne se soucie pas de son fonctionnement.

Malheureusement, comme tout protocole, on peut se retrouver avec des problèmes réseaux à résoudre voir pire des bugs d’implémentation du protocole (surtout dans le cas d’inter-opérabilité avec d’autres constructeurs).

A quoi sert-il?

L’objectif des réseaux est de faire en sorte que les paquets arrivent à destination. Une solution est de dupliquer les équipements physique pour qu’en cas de panne sur l’un d’eux, l’autre équipement prenne le relai; on appelle ça la redondance ou la résilience.

Architecture non redondée

Sur le schéma ci-dessus, on voit bien que si le switch tombe (panne électrique, bug…), plus aucune communication entre les ordinateurs A et B n’est possible.

Architecture redondée

Maintenant que l’on souhaite que les paquets entre les ordinateurs A et B transitent même en cas de panne matériel, créons cette nouvelle architecture:

Avec cette architecture, on voit bien que si le switch du haut ne fonctionne plus, le switch du bas peut tout même transmettre les paquets de A vers B et de B vers A.

Les 3 problèmes à savoir pour le CCNA

Lors de l’examen, vous allez tomber sur des questions propre au fonctionnement intrinsèque du spanning-tree et de ses différentes versions mais aussi sur les problèmes rencontrés par la mise en place d’une redondance physique dans un LAN commuté.

Retenez bien ces 3 problèmes car c’est une question classique du CCNA.

1er problème: Tempète de broadcast

Sur l’architecture redondée précédente, imaginons que la station A envoi un message de broadcast (trame niveau 2 avec comme adresse MAC de destination FFFF.FFFF.FFFF). Que se passe-t-il?

  • Le switch du haut reçoit la trame sur son port, extrait l’adresse MAC de destination (FFFF.FFFF.FFFF) et la duplique sur tous ses ports car c’est une adresse de broadcast. 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’adresse MAC de destination (FFFF.FFFF.FFFF) et la duplique sur tous ses ports car c’est une adresse de broadcast. 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, faisant monter leur CPU à 100% et les font plus ou moins planter (souvent un reboot est nécessaire)
Ce phénomène s’appelle la tempête de broadcast, ou broadcast storm en anglais.

2ème problème: Duplication de trame

Maintenant, imaginons que la station A envoi une trame vers la station B, donc la trame sera forgée avec les informations suivantes:

  • adresse MAC source: A
  • adresse MAC destination: B

Que se passe-t-il?

  • Le switch du haut reçoit la trame sur son port (flèche rouge), extrait l’adresse MAC de destination (B) et la commute sur le port de droite. La station B reçoit bien la trame de la station A
  • Mais le switch du bas reçoit aussi la trame sur son port (flèche orange), extrait l’adresse MAC de destination (B) et la commute sur le port de droite. La station B reçoit donc pour une deuxième fois la trame de la station A
Ce phénomène s’appelle la duplication de trame  (pas top comme optimisation réseau 🙂 )
 

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

Maintenant, regardons un peu ce qu’il se passe côté table CAM – Content Addressable Memory – du switch.

Pour ceux qui ont oublié cette notion, je vous renvoi vers ce chapitre (switch).

Reprenons  la trame précédente (message de A vers B):

  • la trame arrive sur le port 1 du switch du haut. Le switch extrait l’adresse MAC source et l’insère dans sa table CAM [port 1 = adresse MAC A]
  • la trame arrive aussi sur le port 3 du switch du bas. Le switch extrait l’adresse MAC source et l’insère dans sa table CAM [port 3 = adresse MAC A]
Maintenant que chaque switch a extrait l’adresse MAC source pour l’insérer dans sa table, chacun extrait l’adresse MAC de destination (B) et la compare à sa table. Comme aucune entrée n’est trouvée, chaque switch va dupliquer 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’adresse MAC source et l’insère dans sa table CAM [port 2 = adresse MAC A]. Pour cela, il supprime l’entré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’adresse MAC source et l’insère dans sa table CAM [port 4 = adresse MAC A]. Pour cela, il supprime l’entré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énomène s’appelle l’instabilité de la table CAM.

Résolution des 3 problèmes

Pour éviter ces 3 problèmes (tempête de broadcast, duplication de trame et instabilité de la table CAM), le protocole spanning-tree a été créé. Comme ces problèmes proviennent du fait que le réseau commuté est face à une boucle physique, le spanning-tree permet d’identifier cette boucle et de la bloquer “logiciellement”.

Dans notre exemple, tout le trafic passera par le switch du haut pour joindre la station B, le chemin du bas étant bloqué au niveau du port du switch du bas.

Si le switch du haut tombe en panne, le protocole spanning-tree va le détecter et va débloquer le port du bas. A ce moment, tout le trafic passera pour le switch du bas.

Voilà à quoi sert le spanning-tree !

A retenir pour le CCNA

Dans un prochain chapitre, je détaillerai en profondeur le fonctionnement de ce protocole et ses différentes versions jusqu’au MSTP .

Mais pour le moment, retenez que les points suivants pour l’examen:

  • en mettant en place une archiecture redondée, on est face à 3 problèmes majeurs:
    1. tempête de broadcast
    2. duplication de trame
    3. instabilité de la table CAM
  • Pour résoudre ces problèmes, le spanning-tree a été créé et permet d’éviter les boucles physiques en désactivant un port logiciellement, et le réa-active au besoin pour assurer la résilience du réseau

PARTAGER SUR

6 COMMENTAIRES

  1. Merci!
    J’imagine la question ” Choose three statements about the problem can happen on the redundant architecture:”
    A. Broadcast storm
    B. ****
    C. Duplicate of trame
    D. instability of the table cam

    • Bonjour Gilles,
      J’ai pris exprès des numéros de ports différents entre le switch du haut et du bas pour plus de simplicité. Sinon j’aurais du à chaque fois preciser le “port 1 du switch du haut” ou le “port 1 du switch du bas“…

  2. Bonjour,

    Juste pour t’indiquer qu’il y a une erreur dans la partie “3ème problème: Instabilité 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 supprime l’entrée précédente qui était [port 1 = adresse MAC A]

    Ne serait-ce pas plutôt le port 2 ?

    Je découvre ton site, et il m’a l’air plutôt intéressant, merci.

LAISSER UNE RÉPONSE