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

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

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

Composants utilisés

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

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 pour 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 s'étendent sur deux commutateurs. Actuellement, 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 (VSS) Cisco Catalyst utilisent des technologies similaires. Pour la technologie Cisco EtherChannel, le terme Multi-chassis EtherChannel (MCEC) désigne indifféremment l'une ou l'autre technologie.

Rôle vPC

Bien que les deux commutateurs vPC apparaissent comme un seul commutateur pour un périphérique en aval, deux commutateurs vPC ont 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 principal vPC, mais fonctionner comme homologue secondaire vPC. Cela 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, l'ancien périphérique principal devient 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 Unit) et répond aux demandes ARP (Address Resolution Protocol). Le rôle vPC définit également un ensemble d'actions à entreprendre par le principal vPC et le secondaire vPC en réponse à une situation d'interruption de liaison entre homologues vPC. 

Priorité du rôle vPC 

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

Lorsque vous modifiez la priorité des périphériques homologues vPC, les interfaces de votre réseau peuvent monter et descendre. Si vous souhaitez 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 à la fois sur le périphérique vPC principal avec une valeur de priorité inférieure et sur le périphérique vPC secondaire avec la valeur supérieure. Ensuite, arrêtez la liaison entre homologues vPC sur les deux périphériques et entrez la commande shutdown, puis réactivez le port-channel sur les deux périphériques et entrez la commande no shutdown.

Changement de rôle vPC sans heurt

La fonctionnalité de changement de rôle sans heurt vPC fournit une structure pour commuter les rôles vPC entre les homologues vPC sans impact sur les flux de trafic. L'échange de rôles 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.

Consultez Scénario d'utilisation pour le changement de rôle vPC sans heurt pour plus de détails.

Comportement des systèmes vPC lorsqu'une liaison entre homologues vPC est interrompue

Lorsque la liaison d'homologue vPC tombe en panne et que la liaison de keepalive d'homologue 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 de protection de vPC redirige tout le trafic sud-nord vers le périphérique principal vPC. 

Bit rémanent principal vPC

Le bit de rémanence principal vPC est un mécanisme de protection programmé mis en place pour éviter tout changement de rôle inutile (susceptible de provoquer une interruption sur le réseau) lorsque le commutateur principal est rechargé de manière inattendue. Le bit de rémanence principal vPC permet au commutateur actif de conserver son rôle PRINCIPAL lorsqu'un commutateur inactif redevient 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 principal vPC est définie sur TRUE dans ce scénario :

• Le vPC principal actuel redémarre et le commutateur compatible vPC change son rôle de vPC secondaire en vPC principal opérationnel. Le bit rémanent n'est pas défini si le rôle passe de secondaire opérationnel vPC à principal vPC.
• Un commutateur compatible vPC change son rôle, passant de Aucun établissement à vPC principal lorsque le minuteur de restauration de rechargement (240 s par défaut) expire.

  2. La valeur du bit rémanent principal vPC est définie sur FALSE dans les scénarios suivants :

• Un commutateur compatible vPC est redémarré (le bit rémanent est défini sur FALSE par défaut).
• La priorité du rôle vPC a été modifiée ou a été saisie à nouveau.

Le bit principal rémanent vPC est signalé sous la structure du composant logiciel vPC Manager et peut être vérifié à l'aide de cette commande du mode d'exécution NX-OS.

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

Restauration du délai vPC

Une fois qu'un périphérique homologue vPC est rechargé et rétabli, le protocole de routage a besoin de temps pour reconverger. La branche de récupération des vPC peut bloquer le trafic routé de l'accès à l'agrégation/au coeur jusqu'à ce que la connectivité de couche 3 de liaison ascendante soit rétablie.

La fonction de restauration différée vPC retarde l'activation du tronçon vPC sur le périphérique homologue vPC qui récupère. La restauration différée vPC permet aux protocoles de routage de couche 3 de converger avant d'autoriser tout trafic sur le tronçon vPC. Il en résulte une restauration plus élégante et une perte de paquets nulle pendant la phase de récupération (le trafic est toujours dévié sur le périphérique homologue vPC actif). Cette fonctionnalité est activée par défaut avec un compteur par défaut de restauration vPC de 30 secondes. Le minuteur peut être réglé sur une ligne de base de convergence de couche 3 spécifique de 1 à 3 600 secondes.

Vlan D'Interface De Restauration Du Délai VPC

Pour retarder l'apparition 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 compteur par défaut de restauration vPC de 10 secondes.

Délai de restauration vPC avec configuration SVI évolutive de 4000 SVI

Une nouvelle commande delay restore interface-VLAN batch <1-4094> est présentée pour configurer l'espaceur pour activer les interfaces VLAN ou bridge-domain dans un lot de 200 SVI à la fois. La commande delay restore timer delay restore <Timeout value> peut être configurée sur une valeur supérieure à la somme de tous les compteurs de lots configurés. Ceci est fait de sorte que la branche VPC est levée seulement après que tous les SVI ont complètement levé pour éviter tout trou noir du trafic.

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

délai de restauration > (4 000/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 autre comme vPC secondaire, sur la base de ces paramètres et dans cet ordre

1. Bit rémanent principal vPC 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).

Cet organigramme (Image 1) résume les étapes que les deux périphériques homologues vPC doivent suivre pendant le processus de sélection du commutateur principal vPC.

1. Le premier paramètre vérifié entre deux périphériques pendant le processus de sélection principal vPC est le bit rémanent principal vPC. Si le périphérique homologue vPC gagne cette comparaison, il devient vPC principal, quelle que soit la valeur de priorité de rôle vPC configurée ou les adresses MAC système des deux homologues.
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 sur la même valeur, le processus de sélection continue pour comparer les adresses MAC système.

Image 1

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

Bit rémanent de l'homologue 1 vPC défini sur 1	Bit rémanent de l'homologue 2 vPC défini sur 1	vPC principal
Faux (0)	Faux (0)	Cravate
Vrai (1)	Faux (0)	Homologue vPC 1
Faux (0)	Vrai (1)	Homologue vPC 2
Vrai (1)	Vrai (1)	Cravate

Scénario de récupération vPC

Il est important de comprendre le processus d'élection vPC et il ne peut pas être sous-estimé, en particulier dans les scénarios de récupération vPC.

L'image 2 montre une configuration VPC typique, Nexus-01 est le VPC principal et Nexus-02 est le VPC secondaire. Par défaut, les bits rémanents des deux périphériques sont réinitialisés sur FALSE.

  

 Image 2

Comme l'illustre cette image, le commutateur Nexus-01 subit désormais une panne de courant et a été isolé du réseau. Nexus-02 s'est promu en tant que vPC principal et a défini le bit rémanent vPC sur TRUE. 

Et Nexus-02 devient maintenant Operational Primary, et le bit d'accrochage est maintenant défini sur TRUE.

                        

 Image 3

Comme l'illustre cette image, lorsque Nexus-01 se remet en ligne après la restauration de la coupure de courant, Nexus-02 conserve le rôle OPERATIONNEL PRIMAIRE, quelle que soit la priorité de son rôle (car il possède un bit VRAI rémanent) et Nexus-01 prend le rôle SECONDAIRE lorsqu'il se met en ligne. Seul Nexus-01 lance le processus d'initialisation VPC, tandis que Nexus-02 reste PRIMARY et transfère le trafic comme d'habitude. Par conséquent, aucune panne réseau n'est observée.

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

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

Par conséquent, vous pouvez vous attendre à un temps 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 désormais par Nexus-01 comme mentionné ci-dessus, aucune panne réseau n'est observée. 

 Image 4

Exemple de panne réseau liée à un bit rémanent mal défini

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

Cependant, une panne réseau peut se produire après qu'un commutateur isolé a été ré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. (Pour connaître les procédures de remplacement d'un châssis N7K, reportez-vous à la Procédure de remplacement du châssis Nexus 7000.)

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

 Image 5

Lorsque le PKA et le Peer Link sont restaurés, Nexus-02 prend le rôle PRIMARY indépendamment de sa priorité de rôle (car il a un bit rémanent VRAI) et force Nexus-01 à devenir SECONDARY 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 se met en ligne après l'expiration des minuteurs de restauration du relais (40 secondes par défaut).  Dans ce cas, une panne réseau de 40 secondes est observée après la restauration de la PKA et de la liaison 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 aucun 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 sont définis sur 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 PRINCIPAL. Reportez-vous à l'image 1 de ce document pour plus d'informations sur le processus de sélection de rôle VPC.