User Tools

Site Tools


informatique:cisco:stp

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
informatique:cisco:stp [2009/10/05 09:21] – créée pteuinformatique:cisco:stp [2016/02/15 15:41] (current) – [STP Root Guard] pteu
Line 5: Line 5:
 Le **Spanning-Tree Protocol** ou **CST** (Common Spanning-Tree) est un protocole de niveau 2 normalisé par l'IEEE en tant que **802.1D**. Il permet de découvrir la topologie du réseau, d'en détecter les changements et d'éviter les boucles en établissant un chemin unique d'un point à un autre du réseau grâce à un algorithme d'arbre recouvrant (spanning tree). Le **Spanning-Tree Protocol** ou **CST** (Common Spanning-Tree) est un protocole de niveau 2 normalisé par l'IEEE en tant que **802.1D**. Il permet de découvrir la topologie du réseau, d'en détecter les changements et d'éviter les boucles en établissant un chemin unique d'un point à un autre du réseau grâce à un algorithme d'arbre recouvrant (spanning tree).
  
-Les communications entre les commutateurs se font par des paquets appelés BPDUs, qui sont notamment composés du "bridge priority" sur 2 octets suivi de la MAC adresse du commutateur qui parle (donc au total 2 + 6 = 8 octets). Ces 8 octets forment le BID (bridge ID) et servent à déterminé qui sera le **root bridge**. **La priorité la plus basse est la meilleure** ; à priorité égale, le switch qui a la plus petite @ MAC devient le root bridge. A partir de son élection, tous les autres switchs du réseau vont déterminer le chemin le plus court vers celui-ci, en additionnant les coûts des liens traversés :+Les communications entre les commutateurs se font par des paquets appelés BPDUs, qui sont notamment composés du "bridge priority" sur 2 octets suivi de la MAC adresse du commutateur qui parle (donc au total 2 + 6 = 8 octets). Ces 8 octets forment le BID (bridge ID) et servent à déterminer qui sera le **root bridge**. **La priorité la plus basse est la meilleure** ; à priorité égale, le switch qui a la plus petite @ MAC devient le root bridge. A partir de son élection, tous les autres switchs du réseau vont déterminer le chemin le plus court vers celui-ci, en additionnant les coûts des liens traversés :
  
   * 100 pour 10 Mbps   * 100 pour 10 Mbps
Line 13: Line 13:
  
 On peut influer sur l'algorithme STP en modifiant manuellement le coût d'une interface : en l'augmentant, on "oblige" le commutateur à prendre un chemin moins coûteux (ici le coût du lien sur l'interface fa0/1 du switch passe de 19 à 200) : On peut influer sur l'algorithme STP en modifiant manuellement le coût d'une interface : en l'augmentant, on "oblige" le commutateur à prendre un chemin moins coûteux (ici le coût du lien sur l'interface fa0/1 du switch passe de 19 à 200) :
-  Switch(config)#int fa0/1 +<code bash> 
-  Switch(config-if)#spanning-tree cost 200+Switch(config)#int fa0/1 
 +Switch(config-if)#spanning-tree cost 200 
 +</code> 
 + 
 + 
 +====Extended System ID==== 
 + 
 +Pour les commutateurs qui utilisent le **Per-VLAN STP** (= constituer un arbre recouvrant pour chaque VLAN), il faut distinguer chaque BPDU en fonction de son VLAN ; on utilise donc dans ce cas l'**extended system ID**, c'est à dire qu'on transforme le champ "bridge priority" de 16 bits en 4 bit de bridge priority + 12 bits codant le VLAN ID (ne pas modifier la taille de ce champ permet une compatibilité ascendante). 4 bits pour configurer la priorité c'est 2^4 = 16 possibilités ; et en tenant compte du poids (fort) de ces 4 bits dans le champ de 16 bits, cela donne les valeurs décimales suivantes pour la priorité : 4096, 8192, etc... jusqu'à 61440 (ce sont ces chiffres qui apparaissent donc comme priorité dans les configurations des commutateurs). 
 + 
 +Contenu d'un BPDU : 
 +<code bash> 
 +Sans activer l'extended system-id : 2^16 valeurs pour configurer la priorité : 
 ++-------------------------------------------------------------------------+---------------//----------+ 
 +| Bridge-ID : 2 octets                                                    | @ MAC du switch : 6 octets | 
 ++-------------------------------------------------------------------------+---------------//-----------+ 
 + 
 +En activant l'extended system-id : 2^4 valeurs pour coder la priorité + 12 bits codant le VLAN ID 
 ++--------------------------+----------------------------------------------+---------------//-----------+ 
 +| Bridge Priority : 4 bits | Extended System ID : 12 bits (= VLAN ID)     | @ MAC du switch : 6 octets | 
 ++--------------------------+----------------------------------------------+---------------//-----------+ 
 +</code> 
 + 
 +Un exemple pour comprendre : je veux configurer un commutateur pour être root-bridge sur le VLAN 100 avec une priorité de 4096, et ne pas être prioritaire pour le VLAN 200 avec une priorité de 16384 : 
 +<code bash> 
 +# activation du per-vlan rapid STP 
 +spanning-tree mode rapid-pvst 
 + 
 +# activation de l'extended system id 
 +spanning-tree extend system-id 
 + 
 +# je configure une priorité de 4096 (en décimal : "0001" sur les 4 bits 
 +# de poids fort du champs de 16 bits) pour le VLAN 100 et 16384 pour le VLAN 200 
 +spanning-tree vlan 100 priority 4096 
 +spanning-tree vlan 200 priority 16384 
 +</code> 
 + 
 +La priorité du commutateur (la valeur des 2 octets du champ "bridge priority" de mes BPDUs = Bridge Priority + Extended System) sera différente pour chaque VLAN (normal, c'est du PVST !) : 
 +  * pour le VLAN 100 elle vaudra (en décimal) 4096 + 100 = 4196 
 +  * pour le VLAN 200 elle vaudra (en décimal) 16384 + 200 = 16584
  
  
 ====STP BPDU Guard==== ====STP BPDU Guard====
 +
 Désactive le port sur lequel il reçoit des BPDUs si le portfast est activé sur le port. Il faut réactiver manuellement le port. Désactive le port sur lequel il reçoit des BPDUs si le portfast est activé sur le port. Il faut réactiver manuellement le port.
 Pour activer le BPDU guard, on se met en config-if : Pour activer le BPDU guard, on se met en config-if :
-''spanning-tree bpduguard enable''+<code bash> 
 +spanning-tree bpduguard enable 
 +</code>
  
-NB : on peut activer par défaut sur tous les ports __configurés en portfast__ avec la commande globale ''spanning-tree portfast bpduguard default''+NB : on peut activer par défaut sur tous les ports __configurés en portfast__ avec la commande globale 
 +<code bash> 
 +spanning-tree portfast bpduguard default 
 +</code>
  
 ====STP BPDU filter==== ====STP BPDU filter====
-''spanning-tree bpdufilter enable'' permet d'ignorer les BPDUs venant de cette interface (drop) sans pour autant la désactiver. 
  
-NB : on peut activer par défaut sur tous les ports __configurés en portfast__ avec la commande globale ''spanning-tree portfast bpdufilter default''.+Il permet d'ignorer les BPDUs venant de cette interface (drop) sans pour autant la désactiver. 
 +<code bash> 
 +spanning-tree bpdufilter enable 
 +</code> 
 + 
 +NB : on peut activer par défaut sur tous les ports __configurés en portfast__ avec la commande globale 
 +<code bash> 
 +spanning-tree portfast bpdufilter default 
 +</code>
  
 ====STP Root Guard==== ====STP Root Guard====
 +
 Désactive le port si un BPDU de plus faible priorité est reçu (= si le switch de l'autre coté tente de devenir root) ; le port se réactive automatiquement lorsque l'équipement cesse de recevoir des BPDUs supérieurs. Désactive le port si un BPDU de plus faible priorité est reçu (= si le switch de l'autre coté tente de devenir root) ; le port se réactive automatiquement lorsque l'équipement cesse de recevoir des BPDUs supérieurs.
  
 Pour activer le root guard, on se met en config-if : Pour activer le root guard, on se met en config-if :
-''spanning-tree guard root''+<code bash> 
 +spanning-tree guard root 
 +</code>
  
 http://www.cisco.com/warp/public/473/74.html http://www.cisco.com/warp/public/473/74.html
  
 ====Loop guard==== ====Loop guard====
 +
 Le **loop guard** est une sécurité supplémentaire pour éviter les boucles ST. Lorsqu'un port "blocking" cesse de recevoir des BPDUs, il passe normalement aux états listening-learning et forwarding. Si le loop guard est activé, ce dernier passera à l'état loop-inconsistent blocking et le message suivant sera écrit dans les logs : Le **loop guard** est une sécurité supplémentaire pour éviter les boucles ST. Lorsqu'un port "blocking" cesse de recevoir des BPDUs, il passe normalement aux états listening-learning et forwarding. Si le loop guard est activé, ce dernier passera à l'état loop-inconsistent blocking et le message suivant sera écrit dans les logs :
  
-  SPANTREE-2-LOOPGUARDBLOCK: No BPDUs were received on port 3/2 in vlan 3. Moved to loop-inconsistent state.+<code bash> 
 +SPANTREE-2-LOOPGUARDBLOCK: No BPDUs were received on port 3/2 in vlan 3. Moved to loop-inconsistent state. 
 +</code>
  
 Lorsque le port recevra à nouveau des BPDUs, il se débloquera automatiquement. Lorsque le port recevra à nouveau des BPDUs, il se débloquera automatiquement.
Line 47: Line 104:
 Permet à un switch de basculer rapidement sur un port alternatif vers le root bridge lorsque son root port tombe. Typiquement, les switchs sur lesquels on activera cette option sont les switchs d’accès. Permet à un switch de basculer rapidement sur un port alternatif vers le root bridge lorsque son root port tombe. Typiquement, les switchs sur lesquels on activera cette option sont les switchs d’accès.
  
-  (config-if)#spanning-tree uplinkfast+<code bash> 
 +(config-if)#spanning-tree uplinkfast 
 +</code>
  
 C'est une fonctionnalité qui est reprise dans le RST. C'est une fonctionnalité qui est reprise dans le RST.
Line 56: Line 115:
 Cette fonctionnalité Cisco au switch de détecter la perte du root port de son voisin quand il reçoit des BPDUs inférieurs de sa part, ceci avant le Max age (qui est de 20 secondes) et de provoquer une renégociation ST immédiate. Cette fonctionnalité Cisco au switch de détecter la perte du root port de son voisin quand il reçoit des BPDUs inférieurs de sa part, ceci avant le Max age (qui est de 20 secondes) et de provoquer une renégociation ST immédiate.
  
-  (config-if)#spanning-tree backbonefast+<code bash> 
 +(config-if)#spanning-tree backbonefast 
 +</code> 
  
 =====RST===== =====RST=====
  
-Le **Rapid Spanning-Tree** (normalisé **802.1w**) est une modification du ST qui permet une convergence bien plus rapide que le standart initial : on passe de 50 secondes à quelques secondes lors d'une perte d'un lien. C'est devenu un standart lui aussi.+Le **Rapid Spanning-Tree** (normalisé **802.1w**) est une modification du ST qui permet une convergence bien plus rapide que le standard initial : on passe de 50 secondes à quelques secondes lors d'une perte d'un lien. C'est devenu un standard lui aussi.
  
 Par rapport au simple ST, le RST apporte un état supplémentaire : Par rapport au simple ST, le RST apporte un état supplémentaire :
Line 66: Line 128:
  
 Cependant les IOS actuels affichent l'état //blocking// et non //discarding// : Cependant les IOS actuels affichent l'état //blocking// et non //discarding// :
-  Po22                Altn BLK 1         128.1676 P2p +<code bash> 
 +Po22                Altn BLK 1         128.1676 P2p 
 +</code>
  
 ... ainsi que des rôles de ports supplémentaires : ... ainsi que des rôles de ports supplémentaires :
-  * **alternative** : c'est un port qui offre un chemin alternatif vers le root bridge ; il est à l'état __discarding__ en temps normal. Il n'est présent que sur les switchs non-désignés.+  * **alternate** : c'est un port qui offre un chemin alternatif vers le root bridge ; il est à l'état __discarding__ en temps normal. Il n'est présent que sur les switchs non-désignés.
   * **backup** : c'est un port additionnel présent sur un switch désigné qui possède un lien redondant vers le segment sur le lequel il est désigné. C'est donc le cas quand un switch a 2 ports sur le même segment : si l'un devient le port désigné du segment, l'autre deviendra le backup. Son état, dans une topologie stable, est __discarding__.   * **backup** : c'est un port additionnel présent sur un switch désigné qui possède un lien redondant vers le segment sur le lequel il est désigné. C'est donc le cas quand un switch a 2 ports sur le même segment : si l'un devient le port désigné du segment, l'autre deviendra le backup. Son état, dans une topologie stable, est __discarding__.
  
Line 88: Line 151:
 États des ports (schémas trouvés chez [[http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml#roles|Cisco]]) : États des ports (schémas trouvés chez [[http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml#roles|Cisco]]) :
  
-{{http://www.cisco.com/image/gif/paws/24062/146-b.gif}}+{{:informatique:cisco:root_port.gif|}}
  
-{{http://www.cisco.com/image/gif/paws/24062/146-c.gif}}+{{:informatique:cisco:designated_port.gif|}}
  
-{{http://www.cisco.com/image/gif/paws/24062/146-d.gif}}+{{:informatique:cisco:alternate_port.gif|}}
  
-{{http://www.cisco.com/image/gif/paws/24062/146-e.gif}}+{{:informatique:cisco:backup_port.gif|}}
  
 C'est actuellement cette version de ST qui est utilisée partout. Partout vous dis-je. C'est actuellement cette version de ST qui est utilisée partout. Partout vous dis-je.
Line 103: Line 166:
 Le **Per VLAN Spanning-Tree** est une amélioration propriétaire de Cisco qui permet d'avoir une instance ST par VLAN (ça permet de faire de la répartition de flux puisqu'on peut ainsi définir un root bridge différent pour chaque VLAN). Le **Per VLAN Spanning-Tree** est une amélioration propriétaire de Cisco qui permet d'avoir une instance ST par VLAN (ça permet de faire de la répartition de flux puisqu'on peut ainsi définir un root bridge différent pour chaque VLAN).
  
-Cependant son inconvénient est que ce n'est pas un standart (donc concrètement ça ne tourne qu'entre équipements Cisco) et qui cela consomme beaucoup de ressources (CPU et réseau).+Cependant son inconvénient est que ce n'est pas un standard (donc concrètement ça ne tourne qu'entre équipements Cisco) et qui cela consomme beaucoup de ressources (CPU et réseau).
  
 Comme ce protocole utilise une instance par VLAN, chaque BID doit contenir le numéro de VLAN : la priorité du STP (**bridge priority**, sur 16 bits) a été décomposée en 2 champs pour devenir l'**extented bridge priority** 4+12 bits : 4 pour la priorité du switch et 12 bits pour identifier le VLAN (2^12 = 4096, le compte est bon). Cela permet donc de ne pas changer le format du champs, mais implique d'utiliser une priorité multiple de 4096 (on joue sur les 4 bits de poids fort du BID). Comme ce protocole utilise une instance par VLAN, chaque BID doit contenir le numéro de VLAN : la priorité du STP (**bridge priority**, sur 16 bits) a été décomposée en 2 champs pour devenir l'**extented bridge priority** 4+12 bits : 4 pour la priorité du switch et 12 bits pour identifier le VLAN (2^12 = 4096, le compte est bon). Cela permet donc de ne pas changer le format du champs, mais implique d'utiliser une priorité multiple de 4096 (on joue sur les 4 bits de poids fort du BID).
Line 120: Line 183:
  
 On active le RPVST : On active le RPVST :
-  Switch1(config)#spanning-tree mode rapid-pvst +<code bash> 
-  Switch2(config)#spanning-tree mode rapid-pvst+Switch1(config)#spanning-tree mode rapid-pvst 
 +Switch2(config)#spanning-tree mode rapid-pvst 
 +</code>
  
 La priorité par défaut est de 32768 : on va déclarer le Switch1 en "root primaire" et le 2 en "root secondaire" backup, ce qui va avoir comme effet de passer la priorité du Switch1 à 24576 et du Switch2 à 28672. La priorité par défaut est de 32768 : on va déclarer le Switch1 en "root primaire" et le 2 en "root secondaire" backup, ce qui va avoir comme effet de passer la priorité du Switch1 à 24576 et du Switch2 à 28672.
-  Switch1(config)#spanning-tree vlan 445 root primary +<code bash> 
-  Switch2(config)#spanning-tree vlan 445 root secondary+Switch1(config)#spanning-tree vlan 445 root primary 
 +Switch2(config)#spanning-tree vlan 445 root secondary 
 +</code>
  
 NB : quand on configure un switch en ''root primary'' sur un vlan, il va modifier dynamiquement sa priorité pour devenir root sur ce VLAN ; en revanche la commande ''root secondary'' __fixe__ une priorité statique de 28672 (juste prioritaire à la priorité d'un switch lambda configuré par défaut). NB : quand on configure un switch en ''root primary'' sur un vlan, il va modifier dynamiquement sa priorité pour devenir root sur ce VLAN ; en revanche la commande ''root secondary'' __fixe__ une priorité statique de 28672 (juste prioritaire à la priorité d'un switch lambda configuré par défaut).
  
 On aurait pu gérer les priorités statiques à la main : On aurait pu gérer les priorités statiques à la main :
-  Switch1(config)#spanning-tree vlan 445 priority 8192 +<code bash> 
-  Switch2(config)#spanning-tree vlan 445 priority 16384+Switch1(config)#spanning-tree vlan 445 priority 8192 
 +Switch2(config)#spanning-tree vlan 445 priority 16384 
 +</code>
  
 Vérification : Vérification :
-  Switch1#sh spanning-tree vlan 445 +<code bash> 
 +Switch1#sh spanning-tree vlan 445 
 +</code>
  
 =====MSTP===== =====MSTP=====
Line 159: Line 229:
 On va créer 2 instances dans la région region1 avec un n° de révision de 1 : On va créer 2 instances dans la région region1 avec un n° de révision de 1 :
  
-  Switch(config)#spanning-tree mst configuration +<code bash> 
-  Switch(config-mst)#instance 1 vlan 1-500 +Switch(config)#spanning-tree mst configuration 
-  Switch(config-mst)#instance 2 vlan 501-1000 +Switch(config-mst)#instance 1 vlan 1-500 
-  Switch(config-mst)#revision 1 +Switch(config-mst)#instance 2 vlan 501-1000 
-  Switch(config-mst)#name region1 +Switch(config-mst)#revision 1 
-  Switch(config-mst)#exit+Switch(config-mst)#name region1 
 +Switch(config-mst)#exit 
 +</code>
  
 Puis on active le MST : Puis on active le MST :
  
-  Switch(config)#spanning-tree mode mst+<code bash> 
 +Switch(config)#spanning-tree mode mst 
 +</code>
  
-Chaque commutateur doit avoir la même configuration de région sous peine de ne pas pouvoir communiquer avec les autres commutateurs "régionnaux".+Chaque commutateur doit avoir la même configuration de région sous peine de ne pas pouvoir communiquer avec les autres commutateurs "régionaux".
  
 Pour réinitialiser la détection des protocoles ST, il faut passer la commande : Pour réinitialiser la détection des protocoles ST, il faut passer la commande :
  
-  clear spanning-tree detected-protocols+<code bash> 
 +clear spanning-tree detected-protocols 
 +</code>
  
 Dans certains cas (à déterminer) il faut passer la directive suivante sur les interfaces physiques reliées à certains commutateurs : Dans certains cas (à déterminer) il faut passer la directive suivante sur les interfaces physiques reliées à certains commutateurs :
  
-  Switch(config-if)#spanning-tree mst pre-standart+<code bash> 
 +Switch(config-if)#spanning-tree mst pre-standart 
 +</code>
  
  
 ====Vérification==== ====Vérification====
  
-  show spanning-tree mst configuration +<code bash> 
-  show spanning-tree mst+show spanning-tree mst configuration 
 +show spanning-tree mst 
 +</code> 
 + 
 + 
 +=====Désactiver le STP===== 
 + 
 +On peut désactiver le Spanning-tree sur un VLAN donné (par ex. le 2) avec la commande : 
 +<code bash> 
 +no spanning-tree vlan 2 
 + 
 +# vérification 
 +show spanning-tree vlan 2 
 +Spanning tree instance(s) for vlan 2 does not exist. 
 +</code>
informatique/cisco/stp.1254734466.txt.gz · Last modified: 2013/10/14 20:52 (external edit)