Commutation LAN : Protocole Spanning Tree

Présentation du protocole Rapid Spanning Tree (STP) (802.1w)

30 juillet 2013 - Traduction automatique
Autres versions: PDFpdf | Anglais (24 octobre 2006) | Commentaires


Contenu


Introduction

La norme Spanning Tree Protocol (STP)/802.1D a été conçue à un moment où la reprise de la connectivité après une panne dans un délai d'environ une minute était considérée comme des performances adéquates. Avec l'arrivée de la commutation de couche 3 dans les environnements LAN, le pontage concurrence maintenant les solutions routées où les protocoles tels que Open Shortest Path First (OSPF) et Enhanced Interior Gateway Routing Protocol (EIGRP) peuvent fournir une autre voie en moins de temps.

Cisco a amélioré les spécifications 802.1D initiales avec des fonctionnalités telles que Uplink Fast, Backbone Fast et Port Fast pour accélérer le temps de convergence d'un réseau ponté. L'inconvénient est que ces mécanismes sont propriétaires et ont besoin d'une configuration supplémentaire.

Rapid Spanning-Tree Protocol (RSTP ; IEEE 802.1w) peut être considéré plus comme une évolution de la norme 802.1D qu'une révolution. La terminologie 802.1D reste principalement la même. La plupart des paramètres ont été laissés inchangés, de sorte que les utilisateurs familiarisés avec le protocole 802.1D peuvent rapidement et facilement configurer le nouveau protocole. Dans la plupart des cas, RSTP est plus performant que les extensions propriétaires de Cisco sans configuration supplémentaire. Le protocole 802.1w peut également se reconvertir en protocole 802.1D afin d'interagir avec les ponts existants port par port. Cela réduit les avantages qu'il introduit.

La nouvelle édition de la norme 802.1D, IEEE 802.1D-2004, intègre les normes IEEE 802.1t-2001 et IEEE 802.1w.

Ce document fournit des informations relatives aux améliorations ajoutées par RSTP à la norme 802.1D précédente.

Support de RSTP pour les commutateurs Catalyst

Ce tableau montre le support de RSTP pour les commutateurs Catalyst et la configuration logicielle minimale requise pour ce support.

Plate-forme Catalyst MST avec RSTP RPVST+ (également connu sous le nom de PVRST+)
Catalyst 2900XL/3500XL Non disponible. Non disponible.
Catalyst 2940 12.1(20)EA2 12.1(20)EA2
Catalyst 2950/2955/3550 12.1(9)EA1 12.1(13)EA1
Catalyst 2970/3750 12.1(14)EA1 12.1(14)EA1
Catalyst 3560 12.1(19)EA1 12.1(19)EA1
Catalyst 3750 Metro 12.1(14)AX 12.1(14)AX
Catalyst 2948G-L3/4908G-L3 Non disponible. Non disponible.
Catalyst 4000/2948G/2980G (CatOS) 7,1 7,5
Catalyst 4000/4500 (IOS) 12.1(12c)EW 12.1(19)EW
Catalyst 5000/5500 Non disponible. Non disponible.
Catalyst 6000/6500 7,1 7,5
Catalyst 6000/6500 (IOS) 12.1(11b)EX, 12.1(13)E, 12.2(14)SX 12.1(13)E
Catalyst 8500 Non disponible. Non disponible.

Nouveaux états de port et rôles de port

Le protocole 802.1D définit les cinq états de port suivants :

  • handicapé

  • écoute

  • apprendre

  • blocage

  • transmission

Consultez le tableau dans la section États de port de ce document pour plus d'informations.

L'état du port est mixte, qu'il bloque le trafic ou le transmette, et quel que soit son rôle dans la topologie active (port racine, port désigné, etc.). Par exemple, du point de vue opérationnel, il n'y a aucune différence entre un port à l'état blocking et un port à l'état listening. Les deux ports écartent les trames et n'apprennent pas les adresses MAC. La différence réelle réside dans le rôle que le spanning-tree affecte au port. Il peut être supposé sans risque qu'un port à l'état listening est désigné ou racine et va passer à l'état forwarding. Malheureusement, une fois à l'état forwarding, il n'y a aucun moyen de savoir avec l'état du port si le port est racine ou désigné. Cela contribue à démontrer les failles de cette terminologie basée sur l'état. RSTP dissocie le rôle et l'état d'un port pour résoudre ce problème.

États du port

Il y a seulement trois états de port dans RSTP qui correspondent aux trois états opérationnels possibles. Les états 802.1D disabled, blocking et listening sont fusionnés en un état unique discarding 802.1w.

État de port STP (802.1D) État de port RSTP (802.1w) Le port est-il inclus dans la topologie active ? Le port apprend-il les adresses MAC ?
Handicapé Rejet Non Non
Blocage Rejet Non Non
Écoute Rejet Oui Non
Apprendre Apprendre Oui Oui
Transmission Transmission Oui Oui

Rôles de port

Le rôle est maintenant une variable affectée au port donné. Les rôles de port racine et de port désigné demeurent, alors que le rôle de port blocking est réparti en rôles de port de secours et alternatifs. Le Spanning Tree Algorithm (STA) détermine le rôle d'un port en fonction des Bridge Protocol Data Units (BPDU). Afin de simplifier les choses, ce qu'il faut se rappeler sur un BPDU est qu'il y a toujours une méthode pour comparer deux BPDU et décider si l'un est plus utile que l'autre. Cela se base sur la valeur enregistrée dans le BPDU et parfois sur le port sur lequel les BPDU sont reçus. Ceci vu, les informations de cette section expliquent les approches pratiques des rôles de port.

Rôles de port racine

  • Le port qui reçoit le meilleur BPDU sur un pont est le port racine. C'est le port qui est le plus proche du pont racine en termes de coût de chemin. Le STA élit un seul pont racine dans le réseau ponté total (par VLAN). Le pont racine envoie les BPDU qui sont plus utiles que ceux qu'envoie tout autre pont. Le pont racine est le seul pont du réseau qui n'a pas de port racine. Tous les autres ponts reçoivent les BPDU sur au moins un port.

/image/gif/paws/24062/146-b.gif

Rôle du port désigné

  • Le port est dit désigné s'il peut envoyer le meilleur BPDU sur le segment auquel il est connecté. Les ponts 802.1D relient différents segments, tels que des segments Ethernet pour créer un domaine ponté. Sur un segment donné, il peut seulement y avoir un chemin vers le pont racine. S'il y en a deux, il y a une boucle de pontage sur le réseau. Tous les ponts connectés à un segment donné écoutent les BPDU de chacun et conviennent du pont qui envoie le meilleur BPDU en tant que pont désigné pour le segment. Le port de ce pont qui correspond est le port désigné pour ce segment.

/image/gif/paws/24062/146-c.gif

Rôles des ports alternatifs et de secours

  • Ces deux rôles de port correspondent à l'état blocking de la norme 802.1D. Un port bloqué est défini comme n'étant pas le port désigné ou le port racine. Un port bloqué reçoit un BPDU plus utile que celui qu'il envoie sur son segment. Rappelez-vous qu'un port a absolument besoin de recevoir des BPDU pour rester bloqué. RSTP introduit ces deux rôles à cet effet.

  • Un port alternatif reçoit plus de BPDU utiles d'un autre pont et est un port bloqué. Ceci est montré dans le schéma suivant :

/image/gif/paws/24062/146-d.gif

  • Un port de secours reçoit plus de BPDU utiles du pont où il est et est un port bloqué. Ceci est montré dans le schéma suivant :

/image/gif/paws/24062/146-e.gif

Cette distinction est déjà faite intérieurement dans la norme 802.1D. C'est essentiellement comme cela que fonctionne Cisco UplinkFast. Le raisonnement est qu'un port alternatif fournit un autre chemin au pont racine et peut donc remplacer le port racine s'il a une défaillance. Naturellement, un port de secours fournit une connectivité redondante au même segment et ne peut pas garantir une connectivité alternative au pont racine. Par conséquent, il est exclu du groupe de liaisons ascendantes.

En conséquence, RSTP calcule la topologie finale pour le spanning-tree qui utilise les mêmes critères que la norme 802.1D. Il n'y a absolument aucun changement dans la façon dont les différentes priorités de pont et de port sont utilisées. L'adjectif blocking est utilisé pour l'état discarding dans l'implémentation Cisco. CatOS versions 7.1 et ultérieures affichent encore les états listening et learning. Ceci fournit même plus d'informations sur un port que la norme IEEE exige. Cependant, la nouvelle caractéristique est il y a maintenant une différence entre le rôle que le protocole détermine pour un port et son état actuel. Par exemple, il est maintenant parfaitement valable pour un port d'être désigné et blocking en même temps. Comme ceci se produit typiquement pendant des périodes très courtes, cela signifie simplement que ce port est dans un état transitoire avant de passer à l'état forwarding.

Nouveau format BPDU

Peu de modifications ont été introduites par RSTP au format BPDU. Seulement deux indicateurs, Topology Change (TC) et TC Acknowledgment (TCA), sont définis dans 802.1D. Cependant, RSTP utilise maintenant chacun des six bits de l'octet d'indicateur qui demeurent afin d'exécuter les opérations suivantes :

  • Encoder le rôle et l'état du port qui initie le BPDU

  • gérer le mécanisme de proposition/d'accord

/image/gif/paws/24062/146-f.gif

Une autre modification importante est que le BPDU RSTP est maintenant de type 2, version 2. Cela implique que les ponts existants doivent supprimer cette nouvelle BPDU. Cette propriété permet facilement au pont 802.1w de détecter les ponts existants qui lui sont connectés.

Nouvelle gestion des BPDU

Les BPDU sont envoyées à chaque intervalle Hello

Les BPDU sont envoyés à chaque intervalle hello et ne sont plus simplement relayés. Avec la norme 802.1D, un pont non racine ne génère des BPDU que quand il en reçoit une sur le port racine. En fait, un pont relaie plus de BPDU qu'il n'en produit réellement. Ce n'est pas le cas avec la norme 802.1w. Désormais un pont envoie une BPDU avec ses informations actuelles toutes les <intervalle-hello> secondes (2 par défaut) même s'il n'en reçoit pas du pont racine.

Vieillissement plus rapide des informations

Sur un port donné, si les hellos ne sont pas reçus trois fois consécutives, les informations de protocole peuvent être immédiatement périmées (ou si max_age expire). En raison de la modification de protocole précédemment mentionnée, les BPDU sont maintenant utilisées comme mécanisme keep-alive entre les ponts. Un pont considère qu'il perd la connectivité avec sa racine voisine directe ou le pont désigné s'il manque trois BPDU sur une ligne. Ce vieillissement rapide des informations permet une détection rapide des défaillances. Si un pont manque de recevoir les BPDU d'un voisin, il est certain que la connexion à ce voisin est perdue. Ceci est contraire au protocole 802.1D où le problème peut avoir lieu n'importe où sur le chemin vers la racine.

Remarque: Les pannes sont même détectées beaucoup plus rapidement dans le cas de défaillances de liaisons physiques.

Accepte des BPDU inférieures

Ce concept est ce qui compose le noyau du moteur BackboneFast. Le comité IEEE 802.1w a décidé d'incorporer un mécanisme semblable dans RSTP. Quand un pont reçoit des informations inférieures de son pont désigné ou racine, il les accepte immédiatement et remplace celles enregistrées précédemment.

/image/gif/paws/24062/146-g.gif

Puisque le pont C sait encore que la racine est vivante et opérationnelle, il envoie immédiatement une BPDU au pont B qui contient les informations sur le pont racine. En conséquence,le pont B n'envoie pas ses propres BPDU et accepte le port qui mène au pont C comme nouveau port racine.

Transition rapide vers l'état forwarding

La transition rapide est la fonctionnalité la plus importante introduite par 802.1w. Le STA existant a attendu passivement que le réseau converge avant de passer un port à l'état forwarding. La réalisation d'une convergence plus rapide a été l'occasion de régler les paramètres par défaut conservateurs (délai de transmission et temporisateurs max_age) et a souvent mis la stabilité du réseau en jeu. Le nouveau STP rapide peut confirmer activement qu'un port peut passer en toute sécurité à l'état forwarding sans compter sur une configuration de temporisateur. Il y a maintenant un mécanisme de feedback réel qui a lieu entre les ponts compatibles RSTP. Pour réaliser la convergence rapide sur un port, le protocole repose sur deux nouvelles variables : les ports d'extrémité et le type de liaison.

Ports d'extrémité

Le concept de port d'extrémité est déjà bien connu par les utilisateurs de spanning-tree, car il correspond fondamentalement à la fonctionnalité PortFast. Tous les ports directement connectés aux stations d'extrémité ne peuvent pas créer de boucles de pontage sur le réseau. Par conséquent, le port d'extrémité passe directement à l'état forwarding, et saute les états listening et learning. Ni les ports d'extrémité ni les ports PortFast activés ne produisent de modifications de topologie quand la liaison bascule. Un port d'extrémité qui reçoit une BPDU perd immédiatement l'état de port d'extrémité et devient un port spanning-tree normal. À ce stade, il y a une valeur configurée par l'utilisateur et une valeur opérationnelle pour l'état de port d'extrémité. L'implémentation Cisco maintient que le mot clé PortFast soit utilisé pour la configuration de port d'extrémité. Cela simplifie le passage à RSTP.

Type de liaison

RSTP peut seulement réaliser le passage rapide à l'état forwarding sur les ports d'extrémité et les liaisons point à point. Le type de liaison est automatiquement dérivé du mode duplex d'un port. Un port qui fonctionne en mode duplex est supposé être point à point, alors qu'un port semi-duplex est considéré par défaut comme un port partagé. Cette valeur de type de liaison automatique peut être remplacée par une configuration explicite. Dans les réseaux commutés actuels, la plupart des liaisons fonctionnent en mode duplex intégral et sont traitées comme des liaisons point à point par RSTP. Cela leur permet de passer rapidement à l'état forwarding.

La convergence avec le protocole 802.1D

Ce diagramme illustre comment le protocole 802.1D traite une nouvelle liaison ajoutée à un réseau ponté :

/image/gif/paws/24062/146-h.gif

Dans ce scénario, une liaison est ajoutée entre le pont racine et le pont A. Supposez qu'il y a déjà une connexion indirecte entre le pont A et le pont racine (via C - D dans le diagramme). Le STA bloque un port et désactive la boucle de pontage. Lorsqu'ils sont activés, les deux ports sur la liaison entre la racine et le pont A passent à l'état listening. Le pont A peut maintenant entendre la racine directement. Il propage immédiatement ses BPDU sur les ports désignés vers les feuilles de l'arbre. Dès que les ponts B et C reçoivent ces nouvelles information supérieures du pont A, elles les retransmettent immédiatement vers les feuilles. En quelques secondes, le pont D reçoit une BPDU de la racine et bloque immédiatement le port P1.

/image/gif/paws/24062/146-i.gif

Le spanning-tree est très efficace dans la façon dont il calcule la nouvelle topologie du réseau. Le seul problème est maintenant que deux fois le délai de transmission doit s'écouler avant que la liaison entre la racine et le pont A finisse par passer à l'état forwarding. Ceci signifie 30 secondes d'interruption de trafic (la partie entière A, B et C du réseau est isolée) car l'algorithme 8021.D manque de mécanisme de feedback pour informer clairement que le réseau converge dans quelques secondes.

La convergence avec le protocole 802.1w

Maintenant, vous pouvez voir comment RSTP traite une situation semblable. Rappelez-vous que la topologie finale est exactement identique à celle calculée par la norme 802.1D (c'est-à-dire, un port bloqué au même endroit qu'avant). Seules les étapes utilisées pour atteindre cette topologie ont changé.

Les deux ports sur la liaison entre A et la racine passent à l'état blocking dès qu'ils sont activés. Jusqu'ici, tout se comporte comme dans un environnement 802.1D pur. Cependant, à ce stade, une négociation a lieu entre le commutateur A et le pont racine. Dès que le commutateur A reçoit la BPDU du pont racine, il bloque les ports désignés qui ne sont pas des ports d'extrémité. Cette opération s'appelle la synchronisation. Une fois ceci fait, le pont A autorise explicitement le pont racine à passer son port à l'état forwarding. Ce schéma illustre le résultat de ce processus sur le réseau. La liaison entre le commutateur A et le pont racine est bloquée et les deux ponts échangent des BPDU.

/image/gif/paws/24062/146-j.gif

Lorsque le commutateur A bloque ses port désignés qui ne sont pas des ports d'extrémité, la liaison entre le commutateur A et la racine passe à l'état forwarding et la situation suivante apparaît :

/image/gif/paws/24062/146-k.gif

Il ne peut pas encore y avoir de boucle. Au lieu de bloquer au-dessus du commutateur A, le réseau bloque maintenant au-dessous du commutateur A. Cependant, la boucle de pontage éventuelle est coupée à un autre endroit. Cette coupe voyage en bas de l'arborescence avec les nouveaux BPDU lancés par la racine par le commutateur A. à ce stade, les ports nouvellement bloqués sur le commutateur A sont en pourparlers également une transition rapide à l'état d'expédition avec leurs ports voisins sur le commutateur B et le C ces chacun des deux de commutateur initient une exécution de sync. Outre le port racine vers A, seul le commutateur B a des ports désignés qui sont des ports d'extrémité. Par conséquent, il n'a aucun port à bloquer pour autoriser le commutateur A à passer à l'état forwarding. De même, seul le commutateur C doit bloquer son port désigné vers D. L'état montré dans ce schéma est maintenant atteint :

/image/gif/paws/24062/146-l.gif

Rappelez-vous que la topologie finale est exactement identique à l'exemple 802.1D, ce qui signifie que le port P1 sur D finit par se bloquer. Cela signifie que la topologie finale du réseau est atteinte, juste dans le temps nécessaire pour que les nouveaux BPDU descendent l'arborescence. Aucun temporisateur n'est impliqué dans cette convergence rapide. Le seul nouveau mécanisme introduit par RSTP est l'accusé de réception qu'un commutateur peut envoyer à son nouveau port racine pour permettre son passage immédiat à l'état forwarding et qui contourne les délais des états listening et learning qui sont deux fois plus longs que le délai de l'état forwarding. L'administrateur n'a besoin de se soucier que des points suivants pour tirer parti de la convergence rapide :

  • Cette négociation entre les ponts n'est possible que si les ponts sont connectés par des liaisons point à point (c'est-à-dire des liaisons duplex, à moins qu'une configuration de port explicite n'ait été définie).

  • Les ports d'extrémité jouent un rôle encore plus important maintenant que PortFast est activé sur les ports en 802.1D. Par exemple, si l'administrateur réseau ne configure pas correctement les ports d'extrémité sur B, leur connectivité est affectée par le lien qui est généré entre A et le pont racine.

BPDU de proposition/message d'entente

Quand un port est sélectionné par le STA pour devenir un port désigné, le protocole 802.1D attend toujours pendant deux fois la valeur d'un délai de transmission (forward delay) (2x15 secondes par défaut) avant de le passer à l'état forwarding. Avec RSTP, cette condition correspond à un port désigné à l'état bloqué. Les schémas ci-dessous illustrent comment la transition rapide est réalisée étape par étape. Supposons qu'un nouveau lien est créé entre le pont racine et le commutateur A. Chaque port de ce lien passe à l'état désigné bloqué jusqu'à ce qu'il reçoive une BPDU de l'autre port.

/image/gif/paws/24062/146-m.gif

Quand un port désigné est à l'état discarding ou learning (et seulement dans ce cas), il active le bit de proposition des BPDU qu'il envoie. C'est ce qui se produit pour le port p0 du pont racine, comme le montre l'étape 1 du schéma ci-dessus. Étant donné que le commutateur A reçoit des informations supérieures, il sait immédiatement que p1 est le nouveau port racine. Le commutateur A démarre alors une synchronisation pour vérifier que tous ses ports sont synchronisés avec ces nouvelles informations. Un port est dit synchrone s'il remplit l'une ou l'autre des conditions suivantes :

  • Le port est à l'état bloqué, ce qui veut dire mis à l'écart dans une topologie stable.

  • Le port est un port d'extrémité.

Pour illustrer l'effet du mécanisme de synchronisation sur les différents types de ports, supposons qu'il existe un port alternatif p2, un port p3 désigné à l'état forwarding et un port d'extrémité p4 sur le commutateur A. Notez que p2 et p4 remplissent déjà une des conditions. Pour être synchrone (voir l'étape 2 du schéma précédent), il suffit que le commutateur A bloque le port p3 et lui assigne l'état mis à l'écart. Maintenant que tous ses ports sont synchrones, le commutateur peut débloquer son port racine p1 nouvellement sélectionné et lui envoyer en réponse un message d'entente. (voir l'étape 3). Ce message est une copie de la BPDU de proposition, avec le bit d'entente activé au lieu du bit de proposition. Cela garantit que le port p0 sait exactement à quelle proposition correspond l'entente qu'il reçoit.

/image/gif/paws/24062/146-n.gif

Une fois que le port p0 a reçu cette entente, il peut immédiatement passer à l'état forwarding. Il s'agit de l'étape 4 de la figure précédente. Notez que le port p3 est laissé à l'état désigné mis à l'écart après la synchronisation. À l'étape 4, ce port est exactement dans la même situation que le port p0 à l'étape 1. Il lance alors une proposition à son voisin et tente de passer rapidement à l'état forwarding.

  • Le mécanisme de proposition/entente est très rapide, car il ne repose pas sur les temporisateurs. Cette vague d’ententes mutuelles se propage rapidement d'un bout du réseau à l'autre et restaure rapidement la connectivité après un changement de topologie.

  • Si un port désigné mis à l'écart ne reçoit pas d'accord après avoir envoyé une proposition, il passe lentement à l'état forwarding en retrouvant les mécanisme classiques du protocole 802.1D avec la séquence écoute-apprentissage. Cela peut se produire si le pont distant ne comprend pas les BPDU RSTP ou que le port du pont distant se bloque.

  • Cisco a introduit une amélioration dans le mécanisme de synchronisation, qui permet à un pont de passer seulement son ancien port racine à l'état mis à l'écart quand il synchronise. Détailler le fonctionnement de ce mécanisme sort du cadre de ce document. Cependant, on peut sans risque supposer qu'il est appelé dans la plupart des cas communs de reconvergence. Le scénario décrit dans la section La convergence avec le protocole 802.1w de ce document devient extrêmement efficace, car seuls les ports sur le chemin qui mène au port bloqué final sont temporairement perturbés.

/image/gif/paws/24062/146-o.gif

UplinkFast

Une autre forme de passage immédiat à l'état forwarding inclus dans le RSTP est semblable à l'extension propriétaire de Cisco du STP appelée UplinkFast. Habituellement, quand un pont perd son port racine, il peut passer son meilleur port alternatif directement à l'état forwarding (ce que l’on retrouve également dans RSTP). La commutation d’un port alternatif en nouveau port racine provoque un changement de topologie du réseau. Le mécanisme de modification de topologie du protocole 802.1w efface les entrées appropriées des tables de mémoire adressable (CAM : Content Addressable Memory) du pont en amont. Cela évite la propagation d’un « multicast » issue du mécanisme d’UplinkFast.

Uplinkfast n'a pas besoin d'être configuré, car il est inclus nativement et activé automatiquement dans RSTP.

Nouveaux mécanismes de modification de topologie

Quand un pont 802.1D détecte une modification de topologie, il utilise un mécanisme fiable pour en informer d'abord le pont racine. Ceci est montré dans le schéma suivant :

/image/gif/paws/24062/146-p.gif

Une fois que le pont racine se rend compte d'un changement dans la topologie du réseau, il active le drapeau TC sur les BPDU qu'il envoie, qui sont alors acheminées à tous les ponts du réseau. Quand un pont reçoit une BPDU avec le bit du drapeau TC activé, il réduit le délai de vieillissement de sa table de pontage pour le ramener à la valeur du délai d'acheminement. Cela garantit une actualisation rapide des informations périmées. Référez-vous à Présentation des modifications de la topologie de protocole Spanning Tree pour plus d'informations sur ce processus. Ce mécanisme de modification de topologie a été profondément remanié avec RSTP. La détection d'une modification de topologie et sa propagation sur le réseau ont évolué.

Détection d'une modification de topologie

Avec RSTP, seuls les ports autres que des ports d'extrémité qui passent à l'état forwarding provoquent une modification de topologie. Cela signifie qu'une perte de connectivité n'est plus considérée comme une modification de topologie, contrairement au protocole 802.1D (c'est-à-dire, un port qui passe à l'état bloqué ne génère plus de TC). Quand un pont RSTP détecte une modification de topologie, il procède de la façon suivante :

  • Il lance le temporisateur TC avec une valeur égale à deux fois l'intervalle hello pour tous ses ports désignés autres que des ports d'extrémité et pour son port racine s'il y a lieu.

  • Il actualise les adresses MAC associées à tous ces ports.

Remarque: Tant que le temporisateur TC est exécuté sur un port, les BPDU envoyées depuis ce port ont le bit TC activé. Des BPDU sont également envoyées sur le port racine lorsque le temporisateur est actif.

Propagation d'une modification de topologie

Quand un pont reçoit une BPDU avec le bit TC activé depuis un voisin, il procède comme suit :

  • Il efface les adresses MAC apprises sur tous ses ports, sauf sur celui qui reçoit la modification de topologie.

  • Il lance le temporisateur TC et envoie des BPDU avec le bit TC activé sur tous ses ports désignés et sur son port racine (RSTP n'utilise plus la BPDU TCN spécifique, sauf si un pont existant a besoin d'être informé).

De cette façon, la TCN circule se répand très rapidement sur tout le réseau. La propagation TC est maintenant un processus sur une étape. En fait, l'initiateur de la modification de topologie répand ces informations sur tout le réseau, ce qui n'était pas le cas avec le protocole 802.1D où seule la racine le faisait. Ce mécanisme est beaucoup plus rapide que le mécanisme équivalent 802.1D. Il n'y a aucun besoin d'attendre que le pont racine soit prévenu et de maintenir ensuite la modification de topologie pour l'intégralité du réseau pendant une durée égale à <max age plus forward delay> secondes.

/image/gif/paws/24062/146-q.gif

En seulement quelques secondes (un petit multiple des intervalles hello), la plupart des entrées des tables CAM du réseau entier (VLAN) s'actualisent. Cette approche a pour conséquence une inondation temporaire du réseau, mais d'un autre côté, elle efface les éventuelles informations périmées pouvant limiter la convergence rapide du réseau.

Compatibilité avec le protocole 802.1D

RSTP peut interagir avec les protocoles STP existants. Cependant, il est important de noter que les avantages de convergence rapide inhérents au protocole 802.1w sont perdus quand il interagit avec les ponts existants.

Chaque port met à jour une variable qui définit le protocole à exécuter sur le segment correspondant. Un temporisateur de délai de migration de trois secondes démarre également lorsque le port est activé. Quand ce temporisateur est exécuté, le mode STP ou RSTP en cours associé au port est verrouillé. Dès que le délai de migration expire, le port s'adapte au mode correspondant à la prochaine BPDU qu'il reçoit. Si le port change de mode de fonctionnement suite à la BPDU reçue, le délai de migration est relancé. Cela limite la fréquence de changement de mode possible.

/image/gif/paws/24062/146-r.gif

Par exemple, supposons que les ponts A et B de la figure précédente exécutent tous deux RSTP avec le commutateur A désigné pour le segment. Un pont C STP existant est introduit sur cette liaison. Étant donné que les ponts 802.1D ignorent les BPDU RSTP et les suppriment, C pense qu'il n'y a aucun autre pont sur le segment et se met à envoyer ses BPDU inférieures de format 802.1D. Le commutateur A reçoit ces BPDU et, après un délai maximal égal à deux fois l'intervalle hello, remplace son mode par 802.1D sur ce seul port. En conséquence, C comprend maintenant les BPDU du commutateur A et accepte celui-ci comme pont désigné pour ce segment.

/image/gif/paws/24062/146-s.gif

Notez que, dans ce cas particulier, si le pont C est supprimé, le pont A fonctionne en mode STP sur ce port même s'il peut mieux fonctionner en mode RSTP avec son seul voisin B. C'est parce que le pont A ne sait pas que le pont C est supprimé du segment. Pour ce cas (rare) particulier, l'intervention de l'utilisateur est nécessaire pour relancer manuellement la détection du protocole du port.

Quand un port est en mode de compatibilité 802.1D, il peut également gérer les BPDU (TCN) de notification des modifications de topologie et les BPDU avec le bit TC ou TCA activé.

Conclusion

RSTP (IEEE 802.1w) inclut dans sa version native la plupart des améliorations propriétaires Cisco du protocole Spanning Tree 802.1D, par exemple BackboneFast, UplinkFast et PortFast. RSTP peut réaliser une convergence beaucoup plus rapide sur un réseau correctement configuré, parfois dans un délai de quelques centaines de millisecondes. Les temporisateurs 802.1D classiques, comme le forward delay et le max_age, sont seulement utilisés en secours et ne doivent pas être nécessaires si les liaisons point à point et les ports d'extrémité sont correctement identifiés et activés par l'administrateur. En outre, les temporisateurs ne doivent pas être nécessaires s'il n'y a aucune interaction avec les ponts existants.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 24062