Le protocole STP (Spanning-Tree Protocol)

Le protocole STP

Introduction

Le but du Spanning-Tree est d’obtenir une architecture LAN SANS BOUCLE.

Le premier protocole permettant de faire du Spanning-Tree est le protocole STP (Spanning-Tree Protocol). Pour transformer une architecture maillée en architecture sans boucle,  STP va devoir désactiver certaines liaisons. Pour ce faire, il a la possibilité de mettre les ports d’un switch dans un de ces deux états (state) stables :

Forwarding (FWD) :

  • fonctionnement normal du port

Blocking (BLK) :

  • le port n’émet rien sauf des trames STP
  • le port reçoit tous mais ne traite que les trames STP

Pour prendre ce type de décision, il va falloir que tous les switchs se mettent d’accord sur l’architecture logique à adopter. Nos switchs vont échanger des informations STP via des trames BPDU, pour qu’il soit tous d’accord, ils vont dans un premier temps devoir élire un chef !!

Le Chef sera appelé le root-bridge !

Le protocole STP

LE COURS EN VIDéo

Chapitre 1

Élection des BRIDGE

Comment le root bridge est élu ?

Grâce au Bridge ID (BID).

Comment est généré le Bridge-ID ?

Le Bridge ID est généré automatiquement par nos switchs. Il est composé de 2 choses:

Bridge Priority

  • sur 2 octets
  • peut-être modifié par l’administrateur
  • compris entre 0 et 65 535
  • possède un pas de 4096 (4096, 8192, 12228, …,  57344 ou 61440)
  • par défaut : 32 768

MAC Address

  • sur 6 octets
  • correspond à l’adresse MAC de notre switch

Quel est le rôle des trames BPDU ?

Grâce aux trames BPDU, nos switchs vont chercher l’équipement actif possédant la valeur de Bridge Priority la plus faible. Si tout le monde à la même valeur de bridge priority. Ils vont chercher qui à la MAC Address la plus faible.

Par défaut, le switch possédant l’adresse Mac la plus faible va être le root bridge !

Conclusion :

Ce sera donc le switch le plus vieux de votre réseau qui sera le chef de votre topologie de niveau 2 ! Il est primordial de mettre votre cœur de réseau en tant que root bridge (#chef) en jouant sur son bridge priority. Dès que le “root bridge” est élu, tous les liens vont se mettre soit en forwarding, soit en blocking, en suivant la logique suivante :

Protocole STP - Root Bridge
Protocole STP – Root bridge
  • Tous les ports du switch “root bridge(#chef) vont être obligatoirement dans l’état forwarding
  • Le port de chaque “non root bridge(#lesautresswitchs) qui a le coût administratif le plus petit pour aller vers le “root bridge” est dans l’état forwarding
  • Les autres liaisons seront inactives. Sur une liaison inactive, il y aura toujours un port dans l’état forwarding et un autre dans l’état blocking.

Si un lien actif tombe, il sera remplacé par un lien inactif en suivant la logique ci-dessus.

Comment les non-root bridge sont élu ?

Les switchs qui ne seront pas ROOT-BRIDGE seront des NON-ROOT-BRIDGE 😉
Chapitre 2

Le rôles des ports dans une architecture STP

Nous avons vu que les ports de nos switchs peuvent prendre 2 états :

  • forwarding
  • blocking

Le protocole STP va aussi définir un rôle pour chaque port, il existe 3 rôles :

  • root port
  • designated port
  • blocking port

Pour définir quel port de notre switch va devenir le root-port ->

  • Le coût administratif le plus bas

Si égalité

  • La valeur du Bridge ID la plus faible

Si égalité

  • Le numéro de port le plus faible.

Comment se définit le root-port ?

L’élection du root-port va se dérouler de cette manière : 

  • Le coût administratif le plus bas

Si égalité

  • La valeur du Bridge ID la plus faible

Si égalité

  • Le numéro de port le plus faible.

Comment se définissent les designated-port ?

Un port qui a le rôle de “designated port” est dans l’état forwarding.
Tous les ports du root bridge (#chef) ont le rôle de “designated port”.
Seules les liaisons entre “root port” et “designated port” seront actives.

Protocole STP - Designated port
Protocole STP – Designated port

Les autres liaisons posséderont un port en “designated port” et un port en “blocking port”. Afin de déterminer lequel des deux ports aura le rôle de “designated port”, on va définir lequel des deux switchs possède :

  • La liaison avec le coût le plus faible pour atteindre le “root bridge” (root path cost)

En cas d’égalité

  • La Priorité la plus faible ( Bridge ID : par défaut 32 768)

En cas d’égalité

  • L’adresse MAC la plus faible
Protocole STP - Designated Port - Schéma 01
Protocole STP – Designated port – Schéma 01

Les autres ports seront dans l’état Blocking :

Protocole STP - Designated Port - Schéma 02
Protocole STP – Designated port – Schéma 02

 

Comment se définissent les blocking-port ?

C’est les autres ports

Chapitre 3

Élection des rôles

Le coût administratif le plus bas

Nous avons vu plus haut que chaque switchs “non-root bridge” va mettre le port qui a le coût administratif le plus bas pour discuter avec le root- bridge dans l’état “forwarding”. Ce port aura le rôle de  “root port”.

Comment calcule-t-il le coût administratif ? En prenant en compte le tableau suivant :

  • 10 Mbps = 100
  • 100 Mbps = 19
  • 1 Gbps = 4
  • 10 Gbps = 2

Étape 1 :

Le root bridge envoie une trame BPDU sur tous ces ports avec une valeur de “root path cost” (coût du chemin vers le root bridge) égale à 0.

Étape 2 :

Les switchs recevant cette trame BPDU mettent cette valeur de “path cost” sur l’interface physique de réception.

Étape 3 :

Ces derniers renvoient sur leurs autres interfaces une trame BPDU avec un “root path cost” égale à 0 + la valeur de l’interface de sortie.

Exemple :

Le switch 1 possède uniquement des interfaces FastEthernet. Il reçoit sur l’interface FastEthernet 0/1 un message BPDU possédant un “root path cost” égal à 0. Il va donc envoyer une trame BPDU sur ces autres ports FastEthernet avec une valeur de “root path cost” égale à 19 (0+19).

L’interface physique de chaque “non-root switch” possédant la valeur “root path cost” la plus faible aura le rôle de “root-port”.

Pour illustrer cela , nous allons nous baser sur la même architecture vu précédemment.

Le seul point qui va différer sur les deux architectures est le coût des liaisons.

Protocole STP - Coût administratif - Schema 01
Protocole STP – Coût administratif – Schema 01

Maintenant, mettons sur ces architectures nos “root-port” :

Protocole STP - Coût administratif - Schema 01
Protocole STP – Coût administratif – Schema 02

Les switchs C et D ont trouvé un chemin plus court en passant respectivement vers B et E.

La valeur du Bridge ID la plus faible

Protocole STP - Bridge ID
Protocole STP – Bridge ID

Imaginons ce cas de figure :

Un de nos switchs reçoit sur deux de ses ports une trame BPDU possédant le même coût administrative. Du coup quelle liaison va-t-il choisir de mettre en mode Forwarding ?

Dans notre trame BPDU, nous avons vu plus haut que chaque switch intègre son Bridge ID.

Vu que le coût administratif est égal pour ces deux trames BPDU, notre switch va regarder la valeur du Bridge ID de ces deux trames et va décider de mettre en mode forwarding l’interface qui a reçu le BDPU avec le Bridge ID le plus faible.

Dans notre cas, tout notre Bridge ID ont une valeur par défaut.

Le switch B possède une adresse mac plus faible que le switch C.
Le switch D va donc passer par le switch B afin d’atteindre le root bridge.

Le numéro de port le plus faible

Notre switch D reçoit deux trames BPDU sur 2 ports différents :

  • Les coûts administratifs sont égaux
  • Les bridges ID sont égaux (vu qu’ils proviennent du même switch).

Notre switch va donc devoir choir une liaison a mettre en forwarding et l’autre en blocking.

Le numéro de port le plus faible sera mis en actif.

Chapitre 4

État des ports STP

État des ports STP

Nos ports STP peuvent prendre plusieurs états. Il existe de différents types d’états :

État stable

  • disabled(avec la commande shutdown)
  • blocking(le protocole a pris la décision de bloquer ce port pour éviter une boucle, il reçoit et traite toujours les trames BPDU qu’il reçoit)
  • forwarding(le port est actif)

État transitoire

  • listening (le port peut envoyer et recevoir des trames BPDU) = 15s
  • learning(idem que l’état “listening”, sauf qu’il va en même temps remplir sa table ARP) = 15s
Etats des ports STP
États des ports STP

Communication STP

Nos switchs échanges des informations concernant le STP via des trames BPDU (Bridge Protocol Data Units). Il existe 2 types de trames BPDU :

Configuration BPDU :

  • Permet de tenir au courant ses voisins de l’état de santé de la topologie STP.

Topologie Change Notification BPDU (TCN BPDU) :

  • Permet d’annoncer un changement de topologie STP.

Par défaut , un Switchs envoie une trame BPDU toutes les 2 secondes sur tous ses ports .

En cas de panne

Afin de maintenir notre architecture à jour et à prêt à basculer en cas de panne , le “root bridge” envoie sur tous ses ports et toutes les 2 secondes une trame “Hello BPDU“.

Cette trame contient :

  • le root Bridge ID
  • le Bridge ID (dans ce cas , il sera identique au root Bridge ID)
  • le coût pour atteindre le root bridge (dans ce cas, il sera égal à zéro)

Chaque non Root Bridge (#paschef) remplace le Bridge ID et le coût pour atteindre le root bridge (#chef) par les siens et retransmet cette trame sur tous ses ports “designated port”.

Si un switch ne reçoit plus de trame Hello BPDU pendant 20secondes (10 x 2sec) , il va commencer à essayer de changer la topologie STP. Cet intervalle de temps s’appelle le “MaxAge“.

Lorsque la topologie STP commence à changer et que cela nécessite qu’un port précédemment en mode blocking doive passer en mode forwarding. Il va passer dans les stades d’écoute (listening) et d’apprentissage (learning).

fDans le guide officiel du CCNA 200-125 , nous pouvons trouver ce tableau :

Il nous indique que les états blocking, forwarding et disable (shutdown, éteint) sont des états stables et que les états listening et learning sont des états transitoires. Chacun de ses états transitoires dure 15 secondes.

Il va falloir 50 secondes (20+15+15) à notre topologie STP afin de pallier à une panne réseau.

Ce temps est beaucoup trop important. Le protocole RSTP (Rapid STP) est né.

Sur le même thème :

Merci de votre soutien et de votre fidélité ! Ce site existe grâce à vous et je ne vous remercierais jamais assez !

Les liens Trunk : Présentation et configuration

Les objectifs pédagogiques de cette leçon sont :

  • Différencier le protocole ISL et 802.1q.
  • Pourquoi les liens TRUNK ont été inventés.
  • Configurer un lien trunk sur un Switch CISCO.
Les liens trunk

Introduction

Trunk = Tronc en anglais

  • lien physique qui permet de faire transiter desVLANs
  • conserve l’identification VLAN faite sur une trame

Pour faire simple, un port trunk :

  • fait partie de tous les VLANs du switch donc tout le monde peut communiquer avec lui
  • indique dans chaque trame envoyée le numéro deVLAN
  • regarde dans toutes les trames reçues s’il n’y avait pas un numéro de VLAN
Chapitre 1

Les liens trunk en théorie

dans un monde sans trunk

Nous voulons que :

  • le VLAN 10 du SWITCH_01 puisse discuter avec le VLAN 10 du SWITCH_02.
  • le VLAN 20 du SWITCH_01 puisse discuter avec le VLAN 20 du SWITCH_02.
  • le VLAN 30 du SWITCH_01 puisse discuter avec le VLAN 30 du SWITCH_02.

Bon bah essayons plusieurs méthodes :

Test 01 : Je ne configure pas le port FastEthernet 0/8 du SWITCH_01 et du SWITCH_02.
Résultat : Ces derniers seront dans le VLAN 1. Les VLANs 10,20 et 30 ne pourront pas utiliser ce port.

Test 02 : Je mets le port FastEthernet 0/8 du SWITCH_01 et du SWITCH_02 dans le VLAN 10,
Résultat : les VLANs 20 et 30 ne pourront pas utiliser ce port.

Test 03 : Je mets le port FastEthernet 0/8 du SWITCH_01 et du SWITCH_02 dans le VLAN 20,
Résultat : les VLANs 10 et 30 ne pourront pas utiliser ce port.

Test 04 : Je mets le port FastEthernet 0/8 du SWITCH_01 et du SWITCH_02 dans le VLAN 30,
Résultat : les VLANs 10 et 20 ne pourront pas utiliser ce port.

Nous pouvons voir qu’il nous faut quelque chose de supplémentaire pour faire fonctionner tout ça !

Ce qu’il faut c’est un lien trunk !

dans un monde avec trunk

LES PROTOCOLES ISL et 802.1q

Pour mettre en place un lien trunk, il existe deux protocoles :

ISL (Inter-Switch Link)

  • protocole CISCO
  • encapsule la trame
  • ajoute 30 octets

IEEE 802.1Q

  • protocole normalisé
  • tague la trame
  • ajoute 4 octets
Chapitre 2

Le protocole ISL

Le protocole ISL (Inter-Switch Link) est une technique de trunking utilisée pour transporter les VLAN à travers le réseau. Ce protocole a été développé par Cisco pour permettre aux commutateurs  de reconnaître les différents VLAN transportés sur la liaison trunk.

Le protocole ISL fonctionne en encapsulant chaque trame Ethernet d’un VLAN dans une autre trame Ethernet plus grande qui contient des informations supplémentaires sur le VLAN. Cette trame Ethernet plus grande est ensuite transportée sur la connexion trunk entre les switchs. À chaque extrémité de la connexion trunk, la trame Ethernet plus grande est déencapsulée et la trame Ethernet d’origine est envoyée au commutateur approprié en fonction du VLAN ID contenu dans les informations supplémentaires.

Le protocole ISL présente également quelques inconvénients. :

  • Tout d’abord, il est incompatible avec les commutateurs d’autres fabricants que Cisco, limitant ainsi la flexibilité et l’interopérabilité du réseau.
  • De plus, le protocole ISL peut avoir un impact sur les performances du réseau, car chaque trame Ethernet doit être encapsulée dans une trame plus grande, ce qui peut entraîner une augmentation de la charge de travail pour les commutateurs réseau.

Fonctionnement d'ISL

ISL encapsule chaque trame entre un header (en-tête) de 26 octets et un trailer (en-queue) de 4 octets.

Encapsulation ISL en détail
Encapsulation ISL en détail

L’institut IEEE a sorti une norme afin que tous les équipements réseau de marques différentes puissent échanger leurs informations VLAN. Cisco privilégie la norme IEEE 802.1Q et abandonne son protocole ISL. Ce protocole n’est plus implémenté dans les nouveaux équipements réseau Cisco. Toutes trames qui transitent par un lien trunk ISL vont être encapsulées (il n’y a pas de notions de VLAN natif).

Pour résumé

  • ISL = Inter-Switch Link
  • propriétaire Cisco
  • développé bien avant le protocole IEEE 802.1Q
  • ajoute 30 octets à chaque trame
Chapitre 3

Le protocole 802.1q

Présentation

Le protocole 802.1Q :

  • protocole normalisé IEEE
  • créé afin d’uniformiser les liaisons trunk
  • couramment appelé Dot1q (802.1q = .1q = dot1q / traduction : dot = point)

Ce protocole va ajouter un Tag 802.1Q juste après les adresses MAC destination et source de nos trames.

Tag Vlan
Tag VLAN
Tag Vlan en détail
Tag VLAN en détail

Vlan natif

Le protocole IEEE 802.1q ajoute un tag sur chaque trame sauf sur les trames appartenant au VLAN natif ! Si un port trunks utilisant ce protocole normalisé reçoit une trame non taguée, il en déduit que cette trame fait partie du VLAN natif.

Le VLAN natif par défaut est le VLAN 1.

Mais pourquoi l’IEEE a-t-il créé le VLAN natif ?

Il y a fort longtemps, l’utilisation d’un hub était courante. Ils pouvaient être placés sur une liaison trunk. Les utilisateurs finals connectés sur ces hubs recevaient des trames 802.1q et ne les comprenez pas… S’ils font partie du VLAN natif, la trame n’est pas taguée et devient compréhensible par les utilisateurs finals.

Depuis la sortie de Windows XP, les utilisateurs finals comprennent les trames 802.1q sans tenir compte du marquage VLAN. Le VLAN natif reste important vu que les trames non taguées reçues par un port trunk 802.1q vont être placé dans le VLAN natif.

Imaginez un cas de figure :

  • tous nos clients sont dans le VLAN 20
  • le VLAN natif est le VLAN 20

Toutes nos trames générées par nos switchs (CDP, LLDP, DTP) vont donc être placées dans notre VLAN client (pas cool niveau sécurité). Il est donc fortement conseillé de créer un VLAN réservé au VLAN natif.

Chapitre 4

CONFIGURATION D'UNE LIAISON TRUNK

configuration de base

Sw(config)# interface FastEthernet 0/24
Sw(config-if)# description VERS_SWITCH_001
Sw(config-if)# switchport mode trunk
Sw(config-if)# switchport trunk encapsulation dot1q

Si la ligne contenant “dot1q” ne passe pas, ce n’est pas grave. Cela veux dire que le protocole ISL n’existe plus pour le Switch

Cette configuration est à mettre sur tous les ports d’interconnexion SWITCH < > SWITCH.

Configuration d'un lien trunk en vidéo

configuration en détail

Pour configurer un port en mode trunk, il est important de voir comment un port est configuré par défaut. Si on allume un switch pour la première fois et qu’on fait un “show running-configuration“, nous pouvons voir ceci :

Interface FastEthernet 0/1
!
Interface FastEthernet 0/2
 !
 etc.

A priori, nos ports n’ont aucune configuration, sauf que nos équipements n’affichent pas les paramètres par défaut. S’ils les affichaient, nous verrions :

Interface FastEthernet 0/1
  switchport mode dynamic auto
  switchport trunk encapsulation negotiate
  switchport trunk native VLAN 1
  switchport trunk allowed VLAN all
  switchport access VLAN 1
 !
 Interface FastEthernet 0/2
 ect.

Une interface switch peut prendre 3 modes :

  • access
  • trunk
  • dynamic

Le mode access est détaillé dans l’article VLAN; Le mode trunk est détaillé dans le sous-chapitre “Manuel”; le mode dynamic est détaillé dans le sous-chapitre “Dynamic Trunking Protocol”

Le mode trunk

Mettre un port en mode trunk :

Switch(config-if)# switchport mode trunk

Il faut que les deux ports de la liaison trunk soient en mode trunk.

le mode dynamic

DTP = Dynamic Trunking Protocol

  • protocole propriétaire Cisco
  • permet de configurer dynamiquement les deux ports d’une liaison trunk (ISL ou 802.1q)

Mettre un port en mode dynamic :

Switch(config-if)# switchport mode dynamic [ auto | desirable ]

Si le port d’en face est configuré en mode manuel, il va se mettre dans le même mode.

Il existe deux modes dynamic :

  1. Auto : Le port va se mettre en mode trunk si l’autre port de la liaison lui demande.
    Si le port d’en face est en mode trunk ou dynamic desirable, les deux ports de cette liaison seront en mode trunk.
    Dans le cas contraire, les deux ports seront en mode access.
  2. Desirable : Le port va essayer activement de mettre cette liaison en mode trunk.
    Si le port d’en face est en mode trunk , dynamic auto ou dynamic desirable, les deux ports de cette liaison seront en mode trunk.
    Dans le cas contraire, les deux ports seront en mode access.

On peut donc en conclure le tableau suivant :

Pour le désactiver :

switch(config-if)# switchport nonegotiate
Chapitre 5

CONFIGURATION des options

Allowed vlan

Par défaut, tous les VLANs sont autorisés à transiter sur notre lien trunk.
Afin de sécuriser notre réseau, nous pouvons autoriser uniquement les VLANs que nous souhaitons.

Exemple : Nous voulons autoriser les VLANs de 10 à 20 et de 40 à 50.

Switch(config-if)# switchport trunk allowed vlan 10-20, 40-50

ou

Switch(config-if)# switchport trunk allowed VLAN 10-50
Switch(config-if)# switchport trunk allowed VLAN remove 21-39

Vlan natif

(Ne concerne que le protocole 802.1q)

Comme expliqué plus haut, il est conseillé de créer un VLAN spécialement pour le VLAN natif.

Nous allons voir comment faire :

Switch(config)# VLAN 3
Switch(config-VLAN)# name NATIVE
Switch(config-VLAN)# exit

Switch(config)# interface GigaBitEthernet 0/1
Switch(config-if)# switchport trunk native VLAN 3

Toutes les trames non taguées seront donc placées dans le VLAN 3 par le port trunk de réception.

Encapsulation

Nous avons vu qu’il est possible d’utiliser les protocoles ISL et 802.1q pour mettre en place un lien trunk.

Sw(config-if)# switchport trunk encap [ isl | dot1q | negotiate ]

Par défaut, tous nos ports sont en mode negotiate. Si les deux ports de notre liaison sont en mode negotiate et que nos deux équipements supportent les deux protocoles,  ISL sera choisi… Il est donc important de choisir, soi-même, sont protocole trunk.

Configuration de ISL

Switch(config-if)# switchport trunk encapsulation isl

Configuration de 802.1q

Switch(config-if)# switchport trunk encapsulation dot1q
Chapitre 6

Vérification de la configuration TRunk

Vérifier l’état de nos ports :

Switch# show interfaces FastEthernet 0/1 switchport

Sur l’image ci-dessus, nous pouvons voir que :

  • le port 0/1 du Switch_A est en mode dynamic auto (par défaut)
  • le port 0/1 du Switch_B est en mode trunk
Switch# show interfaces trunk

Port        Mode             Encapsulation  Status        Native vlan
Fa0/24      on               802.1q         trunking      1

Port        Vlans allowed on trunk
Fa0/24      1-4094

Port        Vlans allowed and active in management domain
Fa0/24      1,10,20,30

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/24      1,10,20,30

La ligne “operational mode” s’est donc mis en mode trunk

Sur le même thème :