Comprendre et configurer

Slides:



Advertisements
Présentations similaires
– Spanning Tree Protocol (STP)‏
Advertisements

CFI_Site_Paris1 TP - Spanning-Tree - Per-VLAN Spanning-tree.
Soutenance TP Réseau Sujet 10 Plateforme de commutation multi-niveaux Catalyst 8540 Gilles Bricier & Paul ChauchisFévrier 2006.
Effacer la Configuration LWAPP sur un LAP
Terminaux virtuels (VTY)
bgp always-compare-med
Optimisation des Timers
Hot Standby Router Protocol (HSRP) - Partage de charge
show dialer interface bri
OSPF - Comment OSPF génère les routes par défaut
LAN Médias cch_ccnp.
QoS - Propagation de la Politique de QoS via BGP
Configurer le protocole Spanning-Tree
Registre de Configuration (Configuration Register)
Sécurité - VPN - Configurer la mise à jour du client
Configuration EIGRP et IGRP
Protocole R-STP.
Configuration Routeur SOHO77
Plateformes supportées d'adresse MAC unique sur des interfaces VLAN
Ce videoclip produit par l’Ecole Polytechnique Fédérale de Lausanne
BGP - Configuration iBGP et eBGP avec ou sans adresse de Loopback
Configuration BGP de base
Cisco Catalyst 3550 Configuration IGMP Snooping & MVR
Commande show standby ccnp_cch ccnp_cch.
(Switch Database Management)
OSPF - Configuration initiale sur Liaisons Non-Broadcast
Master Réseaux et Systèmes Distribués (RSD)
Spanning-Tree classique
TP - Spanning-Tree - Per-VLAN Spanning-tree
Routage S 3 - Questionnaire N°1
Rapid Spanning-Tree Protocol (802.1w)
TP Hot Standby Router Protocol (HSRP)
Hot Standby Router Protocol standby preempt et standby track
Routage S 7 - Questionnaire N°1
Sécurité - Configuration de
Commande show ip eigrp topology
Routage S 5 - Questionnaire N°1
Proxy ARP ccnp_cch ccnp_cch.
CCNP Routage Chapitre 4 - Questionnaire N°1
Configuration NAT Utilisation de la commande outside source list
Support de NAT pour IPSec ESP Phase II
Configuration de Voice VLAN
OSPF - Commande show ip ospf neighbor.
Sécurité - Configuration de -
Pile IGMPv3 de Host.
Changer les critères de nommage
RIP - Configuration des Extensions.
Comment fonctionne RADIUS?
SONET - Bref aperçu de Packet Over SONET APS
CCNP Routage Chapitre 5 - Questionnaire N°1
Equilibrage de charge VLAN entre trunks en utilisant
Configuration de routes Statiques Flottantes
Configuration OSPF Virtual Link
Commande show dialer ccnp_cch ccnp_cch.
TP - Spanning-Tree - Multiple Spanning-tree
Routage S 3 - Questionnaire N°1
OSPF - Routage Inter-Area
show ip ospf virtual-links
Configuration EIGRP - Agrégation de routes
Comprendre les problèmes
Commande show vtp ccnp_cch ccnp_cch.
QoS - Configuration de NBAR (Network-Based Application Recognition)
Configurer la fonctionnalité
QoS - Configuration Fragmentation
EtherChannel et 802.1Q Trunking entre
QoS - Configuration de COPS pour RSVP
Configuration NAT Dynamique
OSPF - Redistribution des réseaux directement connectés
Collaborateurs & managers
Protocoles d'administration réseau CDP, LLDP
Transcription de la présentation:

Comprendre et configurer Backbone Fast sur les commutateurs Cisco Catalyst

Sommaire • Introduction - Versions de matériels et de logiciels • Comment comparer les BPDUs? • Comment Spanning-tree récupère la connectivité après la défaillance d'une liaison indirecte • Améliorations apportées par Backbone Fast par rapport au Spanning-tree standard - Détection de défaillances de liaison indirecte - Réaction aux défaillances de liaison indirecte • La PDU "Root Link Query" • Scénario avec Backbone Fast validé • Configuration de Backbone Fast pour CatOS et IOS Cisco Intégré (Mode natif) - Configuration pour CatOS - Configuration pour IOS Cisco Intégré(Mode natif) (Catalyst 6000, Catalyst 4000, Catalyst série 2950, Catalyst série 3550)

Comment comparer les BPDUs? Introduction Backbone Fast est une fonctionnalité propriétaire Cisco qui, une fois validée sur tous les commutateurs d'un réseau, peut faire gagner 20 secondes sur un commutateur lors de la récupération de connectivité après défaillance d'une liaison indirecte. Après une brève revue des bases du Spanning-tree, nous verrons quel est le scénario exact de défaillance de liaison auquel Backbone Fast s'applique et comment le configurer sur les différents commutateurs Catalyst avec CatOS ou IOS Cisco . Versions de matériels et de logiciels Les informations contenues dans ce document sont basées sur les versions de matériels et de logiciels suivants : • Commutateur de la série Catalyst 2950 12.1(6)EA2 et suivantes • Commutateur de la série Catalyst 3550 12.1(4)EA1 et suivantes • Commutateur de la série Catalyst 4000 5.1(1a) et suivantes • Commutateur de la série Catalyst 4000 avec IOS Cisco(mode natif) 12.1(8a)EW et suivantes • Commutateur de la série Catalyst 5000 CatOS Version 4.1(1) et suivantes • Commutateur de la série Catalyst 6000 CatOS Version 5.1(1)CSX et suivantes • Commutateur de la série Catalyst 6000 avec IOS Cisco(mode natif) Version 12.0-7XE et suivantes Comment comparer les BPDUs? Les Bridge Protocol Data Unit (BPDU) peuvent être classées très rigoureusement selon les champs qu'elles contiennent. Parmi ces champs il y a le "Root Bridge ID", le coût de chemin vers la racine et le "Bridge ID" de l'émetteur. Une BPDU est considérée meilleure qu'une autre pour les raisons suivantes : • Quand une BPDU transporte un meilleur "Bridge ID" racine qu'une autre . (Plus la valeur est petite , mieux cela est) • Quand les "Bridge ID" racine sont égaux, la BPDU avec le coût de chemin qui a le coût de chemin vers la racine le plus bas est la mailleure. • Quand les "Bridge ID" racine et les coûts de chemin vers la racine sont égaux alors la BPDU avec le Bridge ID" émetteur le plus petit est la meilleure. Il y a d'autres paramètres qui peuvent servir à départager les BPDU, cependant, meilleure est une BPDU meilleur sera l'accès vers la racine. Un commutateur qui reçoit une BPDU sur un port meilleur que celui sur lequel il aurait transmise, met ce port dans l'état "Bloqué" à moins que celui-ci ne soit son propre port racine. Cela signifie que sur ce segment connecté sur ce port, il y a un autre commutateur qui est un commutateur désigné. Un commutateur stocke la BPDU reçue sur un port et transmise par le commutateur désigné courant.

recalculer le chemin après la défaillance d'une liaison indirecte. Comment Spanning-tree récupère la connectivité lors de la défaillance d'une liaison indirecte Ci-dessous, le schéma illustre comment Spanning-tree se comporte quand il doit recalculer le chemin après la défaillance d'une liaison indirecte. C'est-à-dire quand un commutateur doit changer l'état de certains de ses ports à cause de la défaillance d'une liaison qui ne lui est pas directement attachée. R Racine B S L2 L1 L3 Liaison défaillante BPDU Racine B P 1. Ma liaison vers la racine est hors service. Je n'ai pas de chemin alternatif. Je suis la nouvelle racine et j'envoie une BPDU sur tous mes ports 2. Je reçoit une BPDU inférieure à celle que j'ai stockée pour ce port. (B inférieur à R) Je n'en tiens pas compte. Racine R L2 L3 P B S BPDU Racine B 4. Je reçoit une BPDU meilleure que la mienne Cela sera mon port racine 3. Je n'ai pas reçu de BPDU égale à celle que j'ai stockée depuis max-age sur le port P. Je la dévalide je passe le port P en mode "Ecoute" et je transmet ma BPDU sur le port P. 5. Après les états "Ecoute" et "Apprentissage" personne n'a émis une BPDU meilleure que la mienne sur le port P. Le port P passe en mode "Acheminement"

Améliorations apportées par Backbone Fast par rapport au Considérons le schéma précédent comprenant trois commutateurs R, B et S dans une topologie totalement maillée. Supposons que R est le commutateur racine et B est le commutateur racine alternatif. S bloque son port P et B est le commutateur désigné pour la liaison L3. 1. Si la liaison L1 passe hors service, le commutateur B détecte immédiatement la défaillance et suppose qu'il est le commutateur racine. Il commence à transmettre des BPDUs au commutateur S indiquant qu'il est le nouveau commutateur racine. 2. Quand S reçoit cette nouvelle BPDU du commutateur B, il trouve que celle-ci est inférieure à celle qu'il a stockée pour le port P et l'ignore. 3. Après l'expiration du timer max-age (20 sec par défaut), la BPDU stockée par le port P sur le commutateur S n'est plus valide. Le port P passe à l'état "Ecoute" et le commutateur S commence à transmettre sa meilleure BPDU au commutateur B. 4. Dès que le commutateur B reçoit la BPDU du commutateur S, il arrête de transmettre sa BPDU. 5. Le port P passe à l'état "Acheminement" après ête passé par les états "Ecoute" et "Apprentissage". Cela a pris 30 secondes, deux fois la valeur du timer Forward_delay. La connectivité est restaurée. Pour restaurer la connectivité à partir de la défaillance de liaison indirecte, il faut 20 sec(Max-age) plus deux fois la valeur du Forward_delay(2x15 sec). Ces 50 secondes correspondent à l'utilisation des paramètres par défaut. La fonctionnailté Backbone Fast fait propose de diminuer de 20 secondes (max-age) ce temps en dévalidant la BPDU stockée dès qu'une BPDU inférieure est reçue sur le port. Améliorations apportées par Backbone Fast par rapport au Spanning-tree standard Avec l'exemple précédent, le Spanning-tree dévalide l'information, qui devient fausse à cause de la défaillance d'une liaison indirecte, en attendant passivement l'expiration du timer max-age. Pour passer outre ce délai max-age, Backbone Fast introduit deux améliorations: • La capacité de détecter une défaillance de liaison indirecte. Ceci est réalisé en détectant les BPDUs inférieures que le commutateur désigné transmet quand il détecte une défaillance de liaison indirecte. • Un mécanisme autorisant de vérifier immédiatement si une BPDU stockée par un port est toujours valide. Ceci est réalisé en introduisant une nouvelle PDU(Protocol Data Unit) et la fonction Root Link Query.

Détection des défaillances de liaison indirecte Si une BPDU inférieure est reçue sur un port venant de notre commutateur désigné, ce commutateur a : 1. Perdu la connexion avec la racine et commence à diffuser une BPDU comme racine avec un "Bridge ID" supérieur (racine moins bonne que existante). 2. Son chemin vers le la racine a un coût plus élevé que le notre. B, 0 ,B coût de port 10 R S B 1. Dans ce cas, B a perdu la racine et transmet une BPDU avec "root ID" B, coût de chemin égal à 0 et "Bridge ID" B. Elle est inférieure à celle stockée par S car R est une meilleur racine que B. coût de port 10 S B R R, 100 ,B coût de port 100 12. Dans ce cas, B a toujours la racine mais la défaillance implique une augmentation du coût de 10 à 100. La BPDU transmise est inférieure à celle stockée par S car le coût de chemin stocké 10 est inférieur à 100. Le comportement usuel d'après le standard IEEE est simplement d'ignorer les BPDU inférieures. Backbone Fast va les utiliser car dès qu'une de ces BPDU est reçue, il est certain qu'une défaillance est survenue sur le chemin vers la racine et le commuta- teur devra dévalider au moins un port. Note: Une défaillance de liaison indirecte peut se produire sans qu'aucune BPDU inférieure soit générée dans le réseau. Simplement ajouter un hub dans le schéma précédent. S B HUB R La défaillance de liaison se produit entre le commutateur racine R et le Hub. Le commutateur B ne détecte pas de liaison passant hors service et attendra le délai max-age avant de se réclamer nouvelle racine. Rappelez-vous que le mécanisme fonctionnera uniquement si un commutateur détecte une défaillance de liaison directe. Garder seulement la trace des BPDU transmises par le commutateur désigné. Tant que c'est la BPDU stockée par le port, si par exemple un nouveau commutateur est inséré et transmet des BPDU inférieures, il n'utilisera pas la fonctionnalité Backbone Fast.

Réaction aux défaillances de liaison indirecte Quand une BPDU inférieure a été détectée sur un port non-désigné, la seconde phase de Backbone Fast est déclenchée. Au lieu d'attendre passivement l'expiration du délai max-age qui dévalidera les ports pouvant être affectés par une défaillance, une action active de test est introduite par la PDU Root Link Query. Cette PDU est utilisée pour réaliser une sorte de ping pour une racine sur un port non-désigné et permet ainsi de confirmer rapidement si la BPDU stockée par un port est toujours valide ou doit être dévalidée. BPDU inférieure reçue sur un port Avons-nous d'autres ports non-désignés qui ne sont pas auto-bouclés La connexion avec la racine est perdue. Commencer le calcul du chemin avec Spanning-tree Non Oui Transmettre une RLQ Query sur ces ports Attente de la réponse sur chacundes ports sur lesquels la RLQ a été transmise Réponse négative Dévalider la BPDU de ce port Avons-nous reçu une réponse de chaque port? Oui Non Réponse positive La racine est toujours accessible via ce port Non Oui Nous avons toujours la connectivité avec la racine, on peut dévalider le port sur lequel la BPDU inférieure a été reçue. Avons-nous reçue une réponse pour chaque port? Est-ce que toutes les réponses sont négatives? Non , Terminé A la réception d'une BPDU inférieure d'un commutateur désigné, transmettre une PDU RLQ sur tous les ports non-désignés excepté le port sur lequel la BPDU inférieure a été reçue et les ports auto-bouclés. Le port sur lequel la BPDU inférieure a été reçue est exclus car vous devez vous rappelez que ce port est sous l'influence d'une défaillance. Les ports non-désignés et les ports auto-bouclés ne sont pas utiles car ils ne mènent pas à la racine. A la réception d'une réponse à root Link Query sur un port, si la réponse est négative le port a perdu la connexion avec la racine, la BPDU de ce port peut être dévalidée. De plus, si tous les autres ports non-désignés ont déjà tous reçu une réponse négative, le commutateur dans sa totalité a perdu la connexion avec la racine et peut activer la procédure de calcul de chemin depuis le début. Si la réponse confirme que vous pouvez accèder au commutateur racine via ce port, vous pouvez immédiatement dévalider ce port sur lequel la BPDU inférieure a été reçue.

racine R stockée sur les ports Dans l'exemple suivant, les ports A, B, D et E sont non-désignés pour le commutateur S. A est le port racine et les autres sont bloqués. Quand le le port E reçoit une BPDU inférieure (1), Backbone Fast accélère la procédure Spanning-tree. Transmettre une Root Link Query, recherche de la racine sur tous les ports non-désignés sauf E(2). Les réponses vont indiquer quelle racine est accessible via ces ports. La réponse RLQ que le commutateur D reçoit indique que D a perdu la connexion avec la racine R. le commutateur D dévalide la BPDU(3) immédiatement. Les ports A et B reçoivent confirmation qu'ils ont toujours un chemin vers la racine(4). Comme le commutateur a toujours un chemin vers la racine, il dévalide le port E et active la procédure standard du Spanning-tree. 1 A Racine R port racine B Racine R Bloqué E Racine R Bloqué C désigné D S BPDU Z Le port E reçoit une BPDU inférieure, publiant une racine Z au lieu de la racine R stockée sur les ports 2 A Racine R port racine B Racine R Bloqué E Racine R Bloqué C désigné D S RLQ R Le commutateur S est obligé de revérifier tous ces ports non-désignés. Il transmet une RLQ request pour la racine R sur les ports A, B et D.

BPDU stockée sur le port E peut être dévalidée. 3 A Racine R port racine B Racine R Bloqué E Racine R Bloqué C désigné D S RLQ X Le port D est le premier à recevoir une réponse RLQ d'un commutateur X se proclamant racine. C'est une réponse négative. Le port D a perdu la connexion avec la racine R. La BPDU stockée sur le port D est immédiatement dévalidée et le port passe en mode "Ecoute". Comme nous ne savons pas si nous avons toujours la connectivité avec la racine R, le port E reste validé. A Racine R port racine B Racine R Bloqué E Racine R Bloqué C désigné D Ecoute S RLQ R 4 Les ports A et B reçoivent des réponses RLQ confirmant que R est toujours la racine. Comme le commutateur S a toujours la connectivité avec la racine, la BPDU stockée sur le port E peut être dévalidée.

5 A Racine R port racine B Racine R Bloqué E Racine R Ecoute C désigné D Ecoute S Le port E passe à l'état "Ecoute" sans attendre le délai "max-age". Les règles usuelles du Spanning-tree s'appliquent ensuite pour déterminer qui du port D ou du port E passe à l'état "Acheminement" ou "Bloqué". Dans le cas où le commutateur reçoit des réponses avec une racine différente de R, le commutateur consifère qu'il a perdu la connexion avec la racine et celui-ci va activer la procédure Spanning-tree depuis le début. Notez que ce cas peut aussi se produire quand seul le port non-désigné (ou non-auto-bouclé) sur le commutateur est le port racine et qu'une BPDU inférieure est reçue sur ce port. La PDU Root Link Query Les deux formes de RLQ sont les requêtes RLQ et les réponses RLQ. La requête RLQ est transmise sur un port, sur lequel des BPDU sont normalement reçues, dans le but de vérifier si la connexion avec la racine est toujours possible via ce port. Le commutateur racine est indiqué dans la requête et la réponse doit revenir avec le commutateur racine qui peut être accédé via ce port. Si les deux racines sont les mêmes, la connexion existe toujours sinon la connexion avec la racine est perdue. Un commtateur qui reçoit une requête RLQ répond immédiatement s'il sait qu'il a perdu la connexion avec la racine requise( car il a un commutateur racine différent de celui indiqué dans la requête RLQ) et s'il est la racine. Si ce n'est pas le cas, le commutateur réachemine la requête vers la racine via son port racine. Les réponses RLQ sont diffusées sur les ports désignés. L'émetteur de la requête RLQ indique son "Bridge ID" dans la PDU. Ceci est fait pour s'assurer que lorsque le commutateur recevra la réponse à sa requête, il ne diffusera pas la réponse sur ses ports désignés. La PDU RLQ à la même structure de paquet qu'une BPDU standard. La seule différence est que deux adresses SNAP Cisco différentes sont utilisées: une pour la requête et une pour la réponse.

Scénario avec Backbone Fast validé Format d'une BPDU standard : DA SA Length DSAP SSAP CNTL SNAP PDU Les champs inclus dans PDU sont: Protocol ID Version Flags Message Type Root ID Root Path Cost Sender ID Port ID Max age Message agee Hello time Forward delay Le "Message Type" utilisé dans PDU est différent de celui d'une BPDU standard Les seuls champs utilisés sont "Root ID" et "Sender ID". Les fonctionnalités spécifiques Cisco doivent être configurées sur tous les commutateurs du réseau pour que ces PDUs soient traitées. Scénario avec Backbone Fast validé Le scénario suivant est basé sur le premier exemple mais avec Backbone Fast validé sur les trois commutateurs. 1. La première étape est identique à celle de l'exemple précédent 2. Dès que le commutateur S reçoit la BPDU inférieure du commutateur B, il commence par reconfirmer ses ports non-désignés au lieu d'attendre le délai "max-age". Il transmet une requête RLQ sur son port racine pour le commutateur racine R. 3. Le commutateur racine R reçoit la requête et répond immédiatement avec une réponse RLQ indiquant qu'il y a toujours une racine R dans cette direction. 4. Le commutateur S a maintenant vérifié tous ses ports non-désignés et il a toujours la connectivité avec la racine. Il peut immédiatement dévalider la BPDU stockée sur le port P. Le port P passe dans l'état "Ecoute" et commence à trans- mettre des BPDUs. A ce stade, le temps économisé correspond est égal à max-age et ensuite la procédure standard du Spanning-tree est appliquée. 5. B reçoit une BPDU reçoit une BPDU meilleure venant du commutateur S (R meilleure racine que B) et considère maintenant que le port menant à L3 est son port racine.

2 RLQ Req 1 BPDU Root B R B S R 3 RLQ Res B S 4 BPDU Root R Liaison défaillante L1 L2 2 RLQ Req 1 BPDU Root B Port P R B S 1. Ma liaison vers la racine R est passée hors-service. Je n'ai pas de chemin alternatif. Je suis la nouvelle racine et je transmet ma BPDU sur tous mes ports. 2.Je reçoit une BPDU inférieure sur le port P.Je vérifie tous mes autres ports non-désignés en transmettant une RLQ query pour ma racine R sur tous ces ports 3.Je reçoit une RLQ request pour R. Je sius la racine R. Je transmet immédiatement une "RLQ Response" R 3 RLQ Res Liaison défaillante L1 L2 L3 B Port P S 4 BPDU Root R 5. Je reçois une BPDU meilleure que la mienne. Ce port est maintenant mon port racine 4.J'ai eu la confirmation que le chemin vers la racine R existe toujours. Je peux dévlider la BPDU stockée pour le port P. Le port P est passé dans l'état "Ecoute" et je transmet ma BPDU sur le port P.

Configuration de Backbone Fast pour CatOS et IOS Cisco Intégré (Mode natif) Pour les commutateurs Catalyst des séries 4000, 5000, 6000 avec le CatOS, utilisez les commandes suivantes pour valider globalement Backbone Fast sur tous les ports et pour vérifier la configuration. Configuration pour CatOS Console>(enable) set spantree backbonefast enable Backbonefast enabled for all VLANs Console>(enable) show spantree backbonefast ! Cette commande montre que backbonefast est validé Backbonefast is enabled. Console>(enable) Pour afficher les statistiques 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 ! La command show spantree summary affiche toutes les statistiques backbonefast ----------------------- 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) Configuration pour IOS Cisco Intégré(Mode natif) (Catalyst 6000, Catalyst 4000, Catalyst série 2950, Catalyst série 3550) Pour les commutateurs de la série Catalyst 6000, Catalyst 4000, Catalyst série 2950, Catalyst série 3550 utilisez les commandes suivantes: SW_IOS# configure terminal SW_IOS(config)# spanning-tree backbonefast SW_IOS(config)# end SW_IOS#

Pour vérifier que backbone fast est validé et afficher les statistiques : SW_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 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 SW_IOS#