Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment configurer Backbone Fast. Backbone Fast est une fonctionnalité propriétaire de Cisco qui, une fois activée sur tous les commutateurs d'un réseau ponté, peut sauvegarder un commutateur jusqu'à 20 secondes (max_age) quand il récupère d'une défaillance de liaison indirecte. Après un examen rapide des bases du protocole STP (spanning-tree protocol), vous pouvez consulter le scénario de panne précis auquel Backbone Fast s'applique et savoir comment le configurer pour les commutateurs Catalyst qui exécutent les logiciels CatOS et Cisco IOS® à la fois.
Aucune spécification déterminée n'est requise pour ce document.
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
Commutateurs de la gamme Catalyst 2950 qui exécutent le logiciel Cisco IOS version 12.1(6)EA2 et ultérieure
Commutateurs de la gamme Catalyst 3550 qui exécutent le logiciel Cisco IOS version 12.1(4)EA1 et ultérieure
Commutateurs de la gamme Catalyst 4000 qui exécutent CatOS version 5.1(1a) et ultérieure
Commutateurs de la gamme Catalyst 4500/4000 qui exécutent le logiciel Cisco IOS version 12.1(8a)EW et ultérieure
Commutateurs de la gamme Catalyst 5500/5000 qui exécutent CatOS version 4.1(1) et ultérieure
Commutateurs de la gamme Catalyst 6500/6000 qui exécutent CatOS version 5.1(1)CSX et ultérieure
Commutateurs de la gamme Catalyst 6500/6000 qui exécutent le logiciel Cisco IOS version 12.0-7XE et ultérieure
Les unités BPDU (Bridge Protocol Data Unit) peuvent être strictement classifiées par les champs qu'elles portent. Parmi ces champs il y a l'ID de pont racine, le coût du chemin à la racine et l'ID de pont expéditeur. Un BPDU est considéré préférable à un autre BDPU dans les cas suivants :
Un BPDU porte un meilleur ID de pont racine qu'un autre. Plus la valeur est inférieure, mieux c'est.
Quand les valeurs d'ID de pont racine sont égales, alors le BPDU avec le plus bas coût de chemin à la racine est préférable.
Quand les valeurs d'ID de pont racine sont égales et les coûts à la racine sont identiques, alors le BPDU avec le meilleur ID de pont expéditeur convient mieux. Plus la valeur est inférieure, mieux c'est.
Il y a d'autres variables qui peuvent faire la différence. Cependant, plus un BPDU est performant, plus l'accès au meilleur pont racine sera performant.
Un pont qui reçoit un BPDU sur un meilleur port que le port d'envoi met ce port en mode de blocage, à moins que ce soit son port racine. Ceci signifie que sur le segment connecté à ce port, il y a un autre pont qui est un pont désigné. Un pont enregistre la valeur du BPDU sur un port envoyé par le pont désigné actuel.
Ceci illustre comment STP se comporte quand il doit procéder à un recalcul après une défaillance de liaison indirecte, c.-à-d., quand un pont doit modifier l'état de certains de ses ports en raison d'une panne sur une liaison qui n'est pas directement attachée.
Considérez ce schéma, qui implique trois commutateurs R, B et S dans une topologie entièrement engrenée. Supposez que R est le pont racine et B est le pont racine de secours. S bloque son port P et B est le pont désigné pour la liaison L3.
Si la liaison L1 descend, le commutateur B détecte immédiatement la panne et suppose que c'est la racine. Il commence à envoyer des BPDU à S et prétend être la nouvelle racine.
Quand S reçoit ce nouveau BPDU de B, il réalise qu'il est inférieur à celui qu'il avait enregistré pour le port P et l'ignore.
Lorsque le compteur de max_age expire (20 secondes par défaut), le BPDU enregistré sur S pour le port P expire. Le port passe immédiatement à l'écoute et S commence à envoyer son meilleur BPDU à B.
Dès que B recevra le BPDU de S, il cesse d'envoyer son BPDU.
Le port P passe à l'état de transmission via des états d'écoute et d'apprentissage. Cela prend deux fois la valeur fw_delay, soit 30 secondes supplémentaires. La connectivité totale est alors restaurée.
Elle a pris la valeur max_age (20 secondes) plus deux fois la valeur fw_delay (2x15 secondes) pour récupérer de cette défaillance de liaison indirecte. Soit, 50 secondes avec les paramètres par défaut. La fonctionnalité Backbone Fast propose de sauvegarder max_age (20 secondes). Pour cela, elle expire juste après que le port reçoit des BPDU inférieurs.
Avec l'exemple précédent, STP infirme les informations qui deviennent erronées en raison d'une défaillance de liaison indirecte. Pour cela, il attend passivement le max_age. Afin de se débarrasser de ce retard de max_age, Backbone Fast introduit deux améliorations :
La capacité de détecter une défaillance de liaison indirecte dès que possible. Ceci est réalisé en suivant les BPDU inférieurs qu'un pont désigné envoie quand il connaît une panne de lien direct.
Un mécanisme qui autorise un contrôle immédiat si l'information BPDU enregistrée sur un port est encore valide. Ceci est mis en application avec une nouvelle unité de données de protocole (PDU) et la requête de liaison racine (RQL), mentionnées dans ce document sous le nom de PDU RLQ.
Si une BPDU inférieure est reçue sur un port de notre pont désigné, alors ce pont a perdu la racine et commence à annoncer une racine avec un ID de pont plus élevé, une racine pire que la nôtre.
Le comportement de routage habituel en ce qui concerne les caractéristiques IEEE est d'ignorer simplement tous les BPDU inférieurs. Backbone Fast les utilise parce que dès leur réception, il est certain qu'une panne s'est produite sur le chemin à la racine et que vous devez expirer au moins un port.
Note: Une défaillance de liaison indirecte peut se produire sans aucune génération de BPDU inférieur dans le réseau. Ajoutez simplement un concentrateur dans le schéma précédent :
La défaillance de liaison se produit entre le pont racine R et le concentrateur. B ne détecte pas que la liaison descend et attend le max_age avant de prétende être la nouvelle racine. Souvenez-vous que le mécanisme fonctionne seulement si un pont détecte une panne de lien direct.
Contrôlez seulement les BPDU inférieurs envoyés par le pont désigné. Puisque c'est le BPDU qui est enregistré sur le port. Si, par exemple, un pont qui vient d'être inséré commence à envoyer un BPDU inférieur, il ne démarre pas la fonctionnalité Backbone Fast.
Quand un BPDU inférieur est détecté sur un port non désigné, la deuxième étape de Backbone fast est déclenchée. Au lieu d'attendre passivement le max_age pour expirer les ports qui peuvent être affectés par la panne, une façon proactive de les tester immédiatement est introduite à l'aide de PDU RLQ. Le RLQ est utilisé pour réaliser un genre de ping pour la racine sur un port non désigné et autorisé à confirmer rapidement si le BPDU enregistré sur un port est encore valide ou doit être rejeté.
À la réception d'un BPDU inférieur d'un pont désigné, envoyez un PDU RLQ sur tous les ports non désignés excepté le port où vous avez reçu le BPDU inférieur et les ports en boucle automatique. Cela vise à vérifier que vous entendez toujours la racine sur les ports où vous avez l'habitude de recevoir le BPDU. Le port où vous avez reçu le BPDU inférieur est exclu parce que vous savez déjà compte qu'il a subi une panne, les ports en boucle automatique et désignés ne sont pas utiles, car ils ne mènent pas à la racine.
À la réception d'une réponse RLQ sur un port, si la réponse est négative, le port a perdu la connexion à la racine et vous pouvez expirer son BPDU. En outre, si tous les autres ports non désignés recevaient déjà une réponse négative, la totalité du pont perd la racine et peut commencer le calcul de STP à partir de zéro.
Si la réponse le confirme vous pouvez encore accéder au pont racine par l'intermédiaire de ce port, vous pouvez immédiatement expirer le port sur lequel nous avons reçu initialement le BPDU inférieur.
Dans cet exemple, les ports A, B, D et E sont des ports non désignés pour le commutateur S. A est le port racine et les autres sont bloquants. Quand E reçoit un BPDU inférieur (1), Backbone Fast intervient pour accélérer le recalcul de STP.
Envoyez une requête RLQ qui recherche la racine R sur tous les ports non désignés sauf E (2). Les réponses spécifient quelle racine est accessible par l'intermédiaire de ces ports. La réponse RLQ que D reçoit spécifie que D a perdu son chemin vers le R racine. Déterminez immédiatement son BPDU (3). Les ports A et B reçoivent la confirmation qu'ils ont toujours un chemin de routage à R (4). Comme le commutateur S a toujours une connectivité à la racine, expirez immédiatement le port E et continuez avec les règles STP normales (5).
Dans le cas où le commutateur a reçu seulement des réponses avec une racine différente de R, considérez la racine comme perdue et redémarrez immédiatement le calcul STP à partir de zéro. Notez que ce cas se produit également quand le seul port non désigné (et non en boucle automatique) sur le pont est le port racine, et vous recevez un BPDU inférieur sur ce port.
Les deux formes de RLQ sont des requêtes de routage RLQ et des réponses RLQ.
La requête de routage RLQ est envoyée sur un port où vous recevez habituellement le BPDU, afin de vérifier que vous avez toujours la connectivité à la racine par ce port. Spécifiez dans la requête de routage que le pont est votre racine et la réponse RLQ revient éventuellement avec un pont racine qui peut être accédé par ce port. Si les deux racines sont identiques, la connectivité est encore présente, autrement, elle est perdue.
Un pont qui reçoit une requête de routage RLQ répond immédiatement s'il sait qu'il a perdu la connexion à la racine demandée parce qu'il a un pont racine différent de celui spécifié dans la requête RLQ, et si c'est la racine.
Si ce n'est pas le cas, alors, il transfère la requête vers la racine par son port racine.
Les réponses RLQ sont propagées sur les ports désignés. L'expéditeur de la requête de routage RLQ met son ID de pont dans le PDU. Cela afin de s'assurer que quand il reçoit en retour une réponse à sa propre requête, il ne propage pas la réponse sur ses ports désignés.
Le PDU RLQ a la même structure de paquet qu'un BPDU STP normal. La seule différence est que deux adresses SNAP différentes spécifiques à Cisco sont utilisées : une pour la requête de routage et une pour la réponse.
Voici le format BPDU standard :
DA | SA | Longueur | DSAP | SSAP | CNTL | SNAP | PDU |
---|---|---|---|---|---|---|---|
Le champ PDU est :
Identificateur de protocole | Version | Type de message : | Indicatifs | ID de racine | Coût de chemin racine |
---|---|---|---|---|---|
ID d'expéditeur | ID du port | Âge du message | Âge maximum | Délai Hello | Délai de transmission |
Le type de message utilisé dans le PDU est également différent du BPDU standard.
Les seuls champs utilisés sont l'ID de racine et l'ID de pont expéditeur.
Cette fonctionnalité de routage spécifique à Cisco doit être configurée sur tous les commutateurs dans le réseau afin de traiter ces PDU.
Ce scénario est basé sur le premier exemple, mais, cette fois avec Backbone Fast activé sur les trois commutateurs.
La première phase est exactement identique à celle expliquée précédemment.
Dès que S reçoit le BPDU inférieur de B, il commence à reconfirmer ses ports non désignés au lieu d'attendre le max_age. Il envoie une requête RLQ sur son port racine pour le pont racine R.
Le pont racine R reçoit la requête et répond immédiatement avec une réponse RLQ qui spécifie qu'il y a toujours une racine R dans cette direction.
S a maintenant vérifié tous ses ports non désignés, et il a toujours la connectivité à la racine. Il peut alors expirer immédiatement l'information enregistrée sur le port P. P passe à l'écoute et commence à envoyer des BPDU. À cette étape, vous avez déjà économisé des secondes max_age, et l'algorithme Spanning Tree standard (STA) s'applique alors.
B reçoit le meilleur BPDU de S (une meilleure racine R que B) et considère maintenant les ports qui mènent à L3 comme son port racine.
Une fois utilisé, Backbone Fast doit être activé sur tous les commutateurs dans le réseau parce qu'il exige l'utilisation du mécanisme de requête et de réponse RLQ afin d'informer les commutateurs de la stabilité du chemin racine. Le protocole de routage RLQ est en activité seulement quand Backbone Fast est activé sur un commutateur. En outre, le réseau peut également connaître des problèmes avec la propagation RLQ, si Backbone Fast n'est pas activé sur tous les commutateurs. Par défaut, Backbone Fast est désactivé.
Backbone Fast n'est pas pris en charge sur les commutateurs Catalyst 2900XL et 3500XL. Généralement vous devez activer Backbone Fast si le domaine du commutateur contient ces commutateurs en plus d'autres commutateurs Catalyst le prenant en charge. Quand vous mettez en application Backbone Fast dans des environnements comportant des commutateurs XL et des topologies strictes, vous pouvez activer la fonction à un emplacement au sein duquel le commutateur XL est le dernier commutateur de la ligne et n'est connecté qu'au noyau, à deux endroits. Ne mettez pas en application cette fonction si l'architecture des commutateurs XL est de mode guirlande.
Vous n'avez pas besoin de configurer Backbone Fast avec RSTP ou IEEE 802.1w parce que le mécanisme est inclus de manière native et automatiquement activé dans RSTP. Pour plus d'informations sur RSTP ou IEEE 802.1w, consultez Exemple de configuration de la migration de Spanning Tree de PVST+ à Rapid-PVST.
Pour les commutateurs de la gamme Catalyst 4000, 5000 et 6000 qui exécutent CatOS, employez ces commandes afin d'activer Backbone Fast globalement pour tous les ports et vérifier la configuration.
Console> (enable) set spantree backbonefast enable Backbonefast enabled for all VLANs Console> (enable) show spantree backbonefast ! This command show that the backbonefast feature is enabled. Backbonefast is enabled. Console> (enable)
Afin d'afficher les statistiques de Backbone Fast :
Console> (enable) show spantree summary Summary of connected spanning tree ports by vlan Uplinkfast disabled for bridge. Backbonefast enabled for bridge. Vlan Blocking Listening Learning Forwarding STP Active ----- -------- --------- -------- ---------- ---------- 1 0 0 0 1 1 Blocking Listening Learning Forwarding STP Active ----- -------- --------- -------- ---------- ---------- Total 0 0 0 1 1 BackboneFast statistics ! The show spantree summary command displays all backbonefast statistics. ----------------------- Number of inferior BPDUs received (all VLANs): 0 Number of RLQ req PDUs received (all VLANs): 0 Number of RLQ res PDUs received (all VLANs): 0 Number of RLQ req PDUs transmitted (all VLANs): 0 Number of RLQ res PDUs transmitted (all VLANs): 0 Console> (enable)
Pour les commutateurs Catalyst qui fonctionnent avec le logiciel Cisco IOS, employez ces commandes afin d'activer Backbone Fast globalement pour toutes les interfaces.
CAT-IOS# configure terminal CAT-IOS(config)# spanning-tree backbonefast CAT-IOS(config)# end CAT-IOS#
Afin de vérifier que Backbone Fast est activé et afficher les statistiques :
CAT-IOS# show spanning-tree backbonefast BackboneFast is enabled BackboneFast statistics ----------------------- Number of transition via backboneFast (all VLANs) : 0 Number of inferior BPDUs received (all VLANs) : 0 Number of RLQ request PDUs received (all VLANs) : 0 Number of RLQ response PDUs received (all VLANs) : 0 Number of RLQ request PDUs sent (all VLANs) : 0 Number of RLQ response PDUs sent (all VLANs) : 0 CAT-IOS#