Notes Rapides sur le Spanning-tree ...
- Afin d’éviter les boucles dans les Réseaux LAN sans aucune intervention manuelle, le spanning-tree est activé et fonctionne par défaut sur les équipements L2 Cisco. Cela peut engendrer des chemins non optimaux et des ports bloqués non désirés. Dans ce cas, un Tuning est nécessaire.
- Il est souvent conseillé de configurer les switches Cœurs/Agrégation en Root Bridges (la priorité la plus faible : soit un 0 soit avec la commande « root »). S’ils sont deux cœurs, alors l’un d’eux est Primary, l’autre est Secondary avec les deux priorités successives les plus faibles. Cela permet d’éviter d’avoir des ports bloqués au niveau switches cœurs.
Si on utilise le HSRP, il est fortement recommandé d’aligner l’Active HSRP avec le Root STP et le Standby HSRP avec le Secondary STP.
Commandes :
Switch-Core-01(config)# spanning-tree vlan x-y root primary
Switch-Core-02(config)# spanning-tree vlan x-y root secondary
- Par défaut, les switches Cisco utilisent le Per Vlan STP classique (PVST). Ce mode est trop lent (Timers : 15 secondes pour l’Etat Listening, 15 secondes pour l’Etat Learning et 20 secondes Max pour l’Aging Time). Il est très conseillé de passer au mode Rapid VPST (IEEE 802.1w).
Comme l’indique son nom, ce mode est « rapide » : il améliore la convergence en utilisant les Alternate Paths/Ports et des Timers bcp moins élevés. La commande est la suivante :
spanning-tree mode rapid-pvst
- Lorsqu’il est possible, on peut utiliser les Multi-Chassis Port-channels (MC-LAG) entre les Equipements, et c’est afin d’éviter la présence des boucles et la hausse du nombre des ports bloqués. Les exemples les plus connus qui le permettent entre les différentes couches Access-Aggregation-Cores sont : Stack, VSS, VPC …
- La commande pour visualiser l’état du spanning-tree pour un Vlan x (Bridge ID, Root ID, rôles et états des ports…) est la suivante :
Switch# show spanning-tree vlan x
- Il est recommandé d’activer les fonctionnalités de Portfast et de BPDU Guard sur les interfaces qui mènent vers des End Points (Laptops, Imprimantes, APs, Caméras,…). Le Portfast permet le passage direct de l’Etat Disabled à l’état Forwarding sans faire les 30 sec de Listening et Learning.
Le BPDU Guard est utilisé en parallèle avec le Portfast afin d’éviter qu’un End User – par accident ou de mauvaise foi - envoie des trames BPDU et contribue par suite au calcul du spanning-tree (Exp : prendre le rôle Root, créer des boucles et changer de topologie, …). En cas de violation : Err-Disable State (intervention manuelle avec un shut/no shut obligatoire).
Commandes sous les interfaces concernées :
spanning-tree portfast spanning-tree bpduguard enable
- Il est conseillé d’activer la fonctionnalité de « Spanning-tree Root Guard » sous toutes les interfaces des Root Primary et Secondary qui mènent vers les autres Equipements d’Access L2. Cela évite qu’un switch au-dessous de la couche Agg/Cœur (avec un Bridge ID minimal) prenne le rôle « Root » dans la Topologie.
En cas de violation : Root-inconsistent State (Retour à la normale automatiquement si le problème est corrigé).
Commande sous les interfaces concernées :
spanning-tree guard root
- Short Path Cost vs Long Path Cost:
Classiquement, le Spanning-tree utilise le champ « Root Path Cost » de deux octets (16 bits) pour calculer le Cost total cumulé vers le Root. C’est le Short Path Cost. Les valeurs de Cost par défaut pour les différents types de Speed des interfaces sont les suivantes :
| Link Speed | Cost |
|---|---|
| 10 G | 2 |
| 1 G | 4 |
| 100 Mbits/s | 19 |
| 10 Mbits/s | 100 |
C’est la méthode ancienne… Actuellement, dans plusieurs nouveaux DCs, certains liens sont au-delà de 10 Gi. En suivant le tableau précédent, ils vont tous avoir le même Cost 2 ! Le calcul du STP n’est pas très correct.
Solution : Modification du champ « Root Path Cost » avec passage à la taille de 4 Octets (32 bits) au lieu de 2 octets. C’est le « Long Path Cost ».
Avec les 32 bits, on obtient le tableau suivant :
| Link Speed | Cost |
|---|---|
| 10 T | 2 |
| 1 T | 20 |
| 100 G | 200 |
| 10 G | 2000 |
| 1 G | 20 000 |
| 100 Mbits/s | 200 000 |
| 10 Mbits/s | 2 000 000 |
La commande est la suivante :
spanning-tree pathcost method long
Conclusion : Lorsqu’on a un nuage Layer 2 avec des liens de 10G et plus, il faut passer à la méthode Long Path Cost, sinon, le calcul du STP n’est pas fiable.
Remarque : Le mode MST (Multiple Spanning-tree) utilise systématiquement et par défaut la méthode Long Path Cost.
Ce contenu t’a plu ? T'as trouvé utile ?
Tu peux m’offrir alors un Super Café ☕☕:)
Ton soutien me permet de continuer à créer des ressources gratuites et utiles :)
✔ Soutien volontaire
✔ Aucun abonnement
✔ Paiement 100% sécurisé
🔒 Paiement sécurisé via Stripe
Ajouter un commentaire
Commentaires