Comprendre le processus de sélection vPC

Introduction

Ce document décrit le processus de sélection du rôle Virtual PortChannel (vPC) sur les commutateurs de la gamme Nexus.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• vPC sur les commutateurs de la gamme Nexus
• Protocole Spanning Tree (STP)

Components Used

Les informations de ce document sont basées sur la plate-forme de commutation Nexus 9000.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Technologie Virtual PortChannel 

Les vPC (Virtual PortChannels) permettent aux liaisons physiquement connectées à deux commutateurs Cisco différents d'apparaître comme un PortChannel unique vers un troisième périphérique. Le troisième périphérique peut être un commutateur, un serveur ou tout autre périphérique réseau prenant en charge les PortChannels IEEE 802.3ad. vPC permet également la création de PortChannels de couche 2 qui couvrent deux commutateurs. À l'heure actuelle, vPC est mis en oeuvre sur les plates-formes Cisco Nexus 9000, 7000, 5000 et 3000 (avec ou sans extendeurs de fabric Cisco Nexus 2000).

Remarque: Les vPC du logiciel Cisco NX-OS et les systèmes de commutation virtuelle Cisco Catalyst (VSS) sont de technologies similaires. Pour la technologie Cisco EtherChannel, le terme MCEC (Multi-chassis EtherChannel) fait référence à l'une ou l'autre technologie.

Rôle vPC

Bien que les deux commutateurs vPC apparaissent comme un seul commutateur vers un périphérique en aval, deux commutateurs vPC ont entre eux des rôles vPC clairement définis : vPC principal et vPC secondaire.

Les rôles vPC ne sont pas préemptifs, ce qui signifie qu'un périphérique peut être configuré comme périphérique vPC principal, mais fonctionner comme périphérique homologue secondaire vPC. Ceci peut se produire dans ce scénario :

1. Lorsque le périphérique principal d'origine tombe en panne, le périphérique vPC secondaire devient le nouveau périphérique principal.
2. Lorsque le système se rétablit, le périphérique principal précédent est désormais le périphérique secondaire et vice versa. 

Le rôle vPC définit lequel des deux périphériques homologues vPC traite les unités BPDU (Bridge Protocol Data Units) et répond aux requêtes ARP (Address Resolution Protocol). Le rôle vPC définit également un ensemble d'actions à entreprendre par vPC principal et vPC secondaire en réponse à une situation de liaison homologue vPC hors service. 

Priorité de rôle vPC 

Vous pouvez également utiliser role priority dans la commande du mode domaine vPC pour influencer le processus de sélection vPC. La plage de valeurs est comprise entre 1 et 65 636 et la valeur par défaut est 32 667. Une valeur inférieure signifie que ce commutateur a de meilleures chances d'être le vPC principal.

La modification de la priorité des périphériques homologues vPC peut faire monter et descendre les interfaces de votre réseau. Si vous voulez reconfigurer la priorité de rôle pour faire d'un périphérique vPC le périphérique principal, configurez la priorité de rôle sur le périphérique vPC principal avec une valeur de priorité inférieure et sur le périphérique vPC secondaire avec une valeur supérieure. Ensuite, arrêtez la liaison homologue vPC sur les deux périphériques en entrant la commande shutdown et réactivez finalement le port-channel sur les deux périphériques en entrant la commande no shutdown.

Changement de rôle vPC sans heurts

La fonction de changement de rôle sans heurts de vPC fournit un cadre permettant de commuter les rôles vPC entre homologues vPC sans affecter les flux de trafic. Le remplacement de rôle vPC est effectué en fonction de la valeur de priorité de rôle du périphérique sous le domaine vPC. Un périphérique homologue vPC avec une priorité de rôle inférieure est sélectionné comme périphérique vPC principal lorsque la commande vpc role preempt est exécutée.

Pour plus d'informations, consultez Exemple d'utilisation d'un changement de rôle vPC sans heurts.

Comportement des systèmes vPC lorsqu'un Peer-Link vPC est désactivé

Lorsque la liaison homologue vPC tombe en panne et que la liaison homologue keepalive vPC est toujours active, le périphérique homologue secondaire vPC effectue les opérations suivantes :

1. Suspend ses ports membres vPC.
2. Arrête l'interface SVI associée au VLAN vPC.

Ce comportement protecteur de vPC redirige tout le trafic Sud-Nord vers le périphérique principal vPC.

Notez que lorsque la liaison homologue vPC est désactivée, les deux périphériques homologues vPC ne peuvent plus se synchroniser les uns avec les autres, de sorte que le mécanisme de protection conçu conduit à l'isolement d'un des périphériques homologues (en cas d'occurrence le périphérique homologue secondaire) du chemin de données.

Bit rémanent maître vPC

Le bit Master Sticky vPC est un mécanisme de protection programmé introduit afin d'éviter tout changement de rôle inutile (susceptible de perturber le réseau) lorsque le commutateur principal est rechargé de manière inattendue. Le bit rémanent vPC Master permet au commutateur actif de conserver son rôle PRINCIPAL lorsqu'un commutateur inactif revient actif ou lorsqu'un commutateur isolé est réintégré dans le domaine VPC.

Bit rémanent principal vPC :

  1. La valeur du bit rémanent vPC Master est définie sur TRUE dans ce scénario :

• Lorsque le vPC principal actuel redémarre et que le commutateur compatible vPC bascule son rôle de vPC secondaire à vPC opérationnel principal. Le bit rémanent n'est pas défini si le rôle passe de vPC Operational Secondary à vPC Primary.
• Lorsqu'un commutateur compatible vPC bascule son rôle de Aucun défini à vPC Principal lorsque le temporisateur de restauration de rechargement (240 secondes par défaut) expire.

  2. La valeur du bit rémanent vPC Master est FALSE dans ces scénarios :

• Lorsqu'un commutateur compatible vPC est redémarré (Remarque : Le bit rémanent est défini sur FALSE par défaut).
• Lorsque la priorité du rôle vPC est modifiée ou saisie à nouveau.

Le bit maître rémanent vPC est signalé sous la structure des composants logiciels vPC Manager et peut être vérifié avec cette commande en mode d'exécution NX-OS.

Campus_N7K2-VPC# show system internal vpcm info global | include ignore-case sticky
        Sticky Master: TRUE
Campus_N7K2-VPC#

Délai de restauration vPC

Après le rechargement et la réactivation d'un périphérique homologue vPC, le protocole de routage a besoin de temps pour reconverger. La partie vPC restaurante peut contenir du trafic routé par trou noir de l'accès à l'agrégation/au coeur jusqu'à ce que la connectivité de la couche 3 de la liaison ascendante soit rétablie.

La fonctionnalité de restauration du délai vPC retarde la mise en route des segments vPC sur le périphérique homologue vPC en récupération. La restauration du délai vPC permet aux protocoles de routage de couche 3 de converger avant d'autoriser tout trafic sur le segment vPC. Cela se traduit par une restauration plus gracieuse et une perte de paquets nulle pendant la phase de récupération (le trafic est toujours détourné sur le périphérique homologue vPC actif). Cette fonctionnalité est activée par défaut avec un temporisateur de restauration vPC de 30 secondes. Le minuteur peut être réglé en fonction d'une ligne de base de convergence de couche 3 spécifique de 1 à 3 600 secondes.

Vlan d'interface de restauration de délai vPC

Pour empêcher la mise en route des interfaces VLAN sur le périphérique homologue vPC restauré, utilisez l'option interfaces-vlan de la commande delay restore. Cette fonctionnalité est activée par défaut avec un temporisateur de restauration vPC de 10 secondes.

Restauration du délai vPC lors de l'utilisation de l'installation SVI évolutive de 4000 SVI

Une nouvelle commande delay restore interface-VLAN batch <1-4094> est présentée pour configurer le protocole de manière à activer les interfaces VLAN ou domaine de pont dans un lot de 200 SVI à la fois. La commande delay restore <Timeout value> doit être configurée avec une valeur supérieure à la somme de tous les compteurs de lot configurés. Ceci est fait pour que la jambe VPC ne soit activée qu'une fois que toutes les SVI ont complètement monté pour éviter tout trou noir de trafic.

Exemple : 4 000 Vlan, 200 lots, délai de 15 secondes  

délai de restauration > (4000/200)x 15

Processus de sélection vPC

Dans un système vPC, un périphérique homologue vPC est défini comme vPC principal et un périphérique secondaire vPC, en fonction de ces paramètres et dans cet ordre

1. VPC master sticky-bit défini sur 0 ou 1.
2. Priorité de rôle vPC définie par l'utilisateur (le logiciel Cisco NX-OS utilise la valeur numérique la plus faible pour sélectionner le périphérique principal).
3. Valeur d'adresse MAC système (le logiciel Cisco NX-OS utilise l'adresse MAC la plus basse pour sélectionner le périphérique principal).

Ce diagramme de flux (Image 1) récapitule les étapes que les deux périphériques homologues vPC passent au cours du processus de sélection du commutateur principal vPC.

1. Le premier paramètre vérifié entre deux périphériques lors du processus de sélection primaire vPC est le bit rémanent vPC Master. Si le périphérique homologue vPC gagne cette comparaison, il devient principal vPC indépendamment de la valeur de priorité de rôle vPC configurée ou des adresses MAC système que les deux homologues ont.
2. Si les deux commutateurs homologues vPC ont la même valeur de bit rémanent, le processus de sélection passe à l'étape suivante pour comparer la priorité de rôle vPC définie par l'utilisateur.  
3. Si les deux rôles vPC sont configurés avec la même valeur, le processus de sélection se poursuit pour comparer les adresses MAC système.

Image 1

Comme l'illustre l'image, lorsque le bit rémanent vPC du commutateur vPC est défini sur 1 (condition VRAI) et son homologue avec le bit rémanent défini sur 0 (condition FALSE), le côté VRAI remporte l'élection et assume le rôle de principal vPC.

Bit rémanent vPC Peer 1 défini sur 1	Bit rémanent vPC Peer 2 défini sur 1	vPC principal
Faux (0)	Faux (0)	Attache
Vrai (1)	Faux (0)	homologue vPC 1
Faux (0)	Vrai (1)	homologue vPC 2
Vrai (1)	Vrai (1)	Attache

Scénario de récupération vPC

L'importance de comprendre le processus de sélection vPC ne peut être sous-estimée, en particulier dans les scénarios de récupération vPC.

L'image 2 montre une configuration VPC classique, Nexus-01 est le VPC principal et Nexus-02 est le VPC secondaire. Par défaut, les deux bits réactivés sont définis sur FALSE.

  

 Image 2

Comme l'illustre cette image, Nexus-01 a maintenant une panne de courant et a été isolé du réseau. Nexus-02 s'est promu en vPC Primary et a défini le bit de rémanence vPC sur TRUE. 

Et Nexus-02 devient Operational Primary et le bit rémanent est maintenant défini sur TRUE.

                        

 Image 3

Comme l'illustre cette image, lorsque Nexus-01 revient en ligne après la restauration de la coupure de courant, Nexus-02 conserve le rôle PRIMAIRE opérationnel indépendamment de sa priorité de rôle (parce qu'il a un VRAI bit collant) et Nexus-02 prend le rôle SECONDAIRE lorsqu'il se connecte. Seul Nexus-01 commence le processus d'initialisation VPC alors que N7K-02 reste comme principal et transmet le trafic comme d'habitude. Par conséquent, aucune panne de réseau n'est visible.

Deux temporisateurs sont associés au processus d'initialisation vPC sur Nexus-01, qui est maintenant le périphérique secondaire opérationnel vPC :

• SVI de restauration de délai (10 secondes par défaut) 
• Délai de restauration (30 secondes par défaut)

 Par conséquent, vous pouvez vous attendre à un délai de récupération de 40 secondes sur Nexus-01 après la réintroduction de Nexus-01 dans le réseau en tant que périphérique secondaire vPC. Cependant, puisque Nexus-02 joue le rôle principal, tout le trafic passe maintenant par Nexus-01 comme mentionné ci-dessus, aucune panne de réseau n'est visible. 

 Image 4

Exemple de panne de réseau pertinente pour un bit rémanent

La panne de réseau est causée par un bit rémanent INCORRECTEMENT défini lorsqu'un commutateur isolé (Nexus-02) est introduit de nouveau dans le domaine VPC

Cependant, une panne de réseau peut survenir après qu'un commutateur isolé est de nouveau introduit dans le domaine VPC si les bits rémanents ne sont pas définis correctement sur les deux commutateurs Nexus. Avant qu'un commutateur isolé ne soit réintroduit dans le domaine VPC, son bit rémanent doit être défini sur FALSE. (Procédures de remplacement d'un châssis N7K, voir https://www.cisco.com/c/en/us/support/docs/interfaces-modules/nexus-7000-series-supervisor-1-module/119033-technote-nexus-00.html#anc11)

Comme l'illustre l'image 5, Nexus-01 est configuré avec une priorité de rôle VPC supérieure à Nexus-02 et Nexus-02 a son bit rémanent défini sur TRUE. Les liaisons E1/1 et E1/2 de Nexus-01 sont en état de transmission alors que E1/1 et E1/2 sont en état d'arrêt. 

 Image 5

Lorsque la PKA et la liaison d'homologue sont restaurées, Nexus-02 prend le rôle PRINCIPAL indépendamment de sa priorité de rôle (parce qu'il a un TRUE sticky bit) et force Nexus-01 à devenir SECONDAIRE et le processus d'initialisation VPC commence sur Nexus-01. Par conséquent, la liaison E1/1 et E1/2 de Nexus-01 est suspendue par VPC et est mise en ligne après l'expiration des temporisateurs de restauration de relais (40 secondes par défaut).  Dans ce cas, une panne de réseau de 40 secondes est observée après la restauration de l'infrastructure de clés publiques et de la liaison d'homologue, comme illustré à l'image 6.

 Image 6

Remarque: Lorsqu'un Nexus est réintroduit dans le domaine vPC, vous devez vous assurer qu'il n'y a pas de changement de rôle vPC dans le périphérique vPC actif. Pour éviter un changement de rôle vPC lorsque les bits rémanents des deux commutateurs ont la même valeur, le périphérique vPC actif doit avoir une priorité de rôle plus élevée pour conserver son rôle PRIMAIRE. Reportez-vous à l'image 1 de ce document pour plus d'informations sur le processus de sélection des rôles VPC.