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 de la série Nexus
• Protocole Spanning Tree (STP)

Composants utilisés

L’information contenue dans ce document repose sur la plateforme de commutateurs 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 Channel-port virtuel 

Les Channel-ports virtuels (vPC) permettent à des liens qui sont physiquement connectés à deux commutateurs Cisco différents d’apparaître comme un seul canal de port 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 de réseau compatible à la norme d'agrégation de liens IEEE 802.3ad.PortChannels. Le vPC permet également la création de ports-channels de couche 2 qui s’étendent sur deux commutateurs. À l’heure actuelle, vPC est mis en œuvre sur les plateformes Cisco Nexus 9000, 7000, 5000 et 3000 (avec ou sans extension de structure Cisco Nexus de la série 2000).

Remarque : Les vPC du logiciel Cisco NX-OS et les systèmes de commutation virtuelle (VSS) Cisco Catalyst sont des technologies similaires. Pour la technologie Cisco EtherChannel, l'expression Multi-chassis EtherChannel (MCEC) désigne de manière interchangeable les deux technologies.

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 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é en tant que périphérique vPC principal, mais fonctionner en tant que périphérique homologue vPC secondaire. Cela peut se produire dans le scénario suivant :

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écupère, l’appareil principal est devenu à présent le périphérique secondaire, et inversement. 

Le rôle vPC définit lequel des deux périphériques homologues vPC traite les BPDU (Bridge Protocol Data Unit) et répond aux demandes ARP (Address Resolution Protocol). Le rôle de vPC définit également un ensemble d’actions à entreprendre par le vPC principal et le vPC secondaire en réponse à une situation de panne du lien homologue 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 augmenter ou diminuer. Si vous souhaitez configurer à nouveau 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 la plus élevée. Ensuite, fermez le lien homologue vPC sur les deux périphériques et saisissez la commande shutdown, puis réactivez le canal de port sur les deux périphériques et saisissez la commande no shutdown.

Changement de rôle vPC sans interruption

Comportement des systèmes vPC en cas de panne d'un lien homologue vPC

Lorsque le lien homologue vPC dysfonctionne et que le lien homologue de maintien d’activité (keepalive) est toujours actif, le périphérique homologue secondaire vPC effectue ces opérations :

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

Ce comportement protecteur du vPC redirige tout le trafic sud-nord vers le périphérique principal vPC. 

Remarque : Lorsque la liaison entre homologues vPC est désactivée, les deux périphériques homologues vPC ne peuvent plus se synchroniser l'un avec l'autre. Le mécanisme de protection conçu permet donc d'isoler l'un des périphériques homologues (en l'occurrence, le périphérique homologue secondaire) du chemin de données.

Bit rémanent principal vPC

Le bit de rémanence principale vPC est un mécanisme de protection programmé mis en place pour éviter tout changement de rôle inutile (qui pourrait entraîner une interruption sur le réseau) lorsque le commutateur principal est rechargé de manière inattendue. Le bit rémanent principal vPC 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.

Basculement du bit rémanent principal vPC :

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

• Le vPC principal actuel redémarre et le commutateur activé pour vPC change de rôle de vPC secondaire à celui de vPC opérationnel principal. Le bit rémanent n’est pas défini si le rôle passe de vPC opérationnel secondaire à vPC principal.
• Un commutateur compatible vPC change son rôle de Aucun établi à vPC principal lorsque la minuterie de restauration par rechargement (240 secondes 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 activé pour vPC est redémarré (le bit rémanent est défini sur FALSE par défaut).
• La priorité de rôle vPC est modifiée ou saisie à nouveau.

Le bit principal rémanent du vPC est signalé dans la structure des composants logiciels de vPC Manager et peut être vérifié avec cette commande de 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

Après le rechargement et le redémarrage d’un périphérique homologue vPC, le protocole de routage a besoin de temps pour reconverger. La section des vPC en récupération peut obtenir un trou noir pour le trafic routé de l’accès à l’agrégation/au cœur jusqu’à ce que la connectivité de couche 3 de liaison ascendante soit rétablie.

La fonction Délai de restauration vPC retarde l'activation du tronçon vPC sur le périphérique homologue vPC qui récupère. La restauration du délai 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 progressive et aucune perte de paquet 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 une minuterie de restauration vPC par défaut de 30 secondes. La minuterie peut être réglée sur une référence de convergence de couche 3 spécifique de 1 à 3600 secondes.

VLAN de l'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 minuteur par défaut de restauration vPC de 10 secondes.

Restauration du délai vPC lors de l’utilisation de la configuration de SVI à l’échelle de 4000 SVI

Une nouvelle commande delay restore interface-VLAN batch <1-4094> est introduite pour configurer le rythmeur de façon à ce qu’il affiche les interfaces VLAN ou de domaine de pont par lot de 200 SVI à la fois. La commande de minuterie de restauration du délai vPC delay restore<Timeout value> peut être définie sur une valeur supérieure à la somme de tous les minuteurs de lot configurés. Ceci afin que le segment de VPC ne soit activé qu’après que tous les SVI sont complètement activés 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 autre comme vPC secondaire, en fonction de ces paramètres et dans cet ordre

1. Bit rémanent principal vPC défini à 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 basse pour choisir le périphérique principal).
3. Valeur de l’adresse MAC du système (le logiciel Cisco NX-OS utilise l’adresse MAC la plus basse pour élire le périphérique principal).

Ce diagramme (image 1) résume les étapes par lesquelles 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 pendant le processus de sélection principale vPC est le bit rémanent principale vPC. Si le périphérique homologue vPC gagne cette comparaison, il devient le vPC principal, quelles que soient la valeur de priorité de rôle vPC configurée ou les adresses MAC du 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é du rôle vPC défini par l’utilisateur.  
3. Si les deux rôles vPC sont configurés à la même valeur, le processus de sélection se poursuit pour comparer les adresses MAC du système.

Image 1

Comme le montre l’image, lorsque le commutateur vPC a le bit rémanent principal vPC défini sur 1 (condition TRUE) et son homologue avec le bit rémanent défini sur 0 (condition FALSE), le côté TRUE gagne lors de ce choix et assume le rôle de vPC principal.

Scénario de récupération vPC

Il est important de comprendre le processus de sélection vPC et il ne peut ê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 éléments rémanents des deux éléments persistants sont réinitialisés sur FALSE.

 Image 2

Comme le montre l’image ci-dessous, le Nexus-01 connaît maintenant 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. Nexus-02 devient maintenant Opérationnel principal et le bit rémanent est maintenant défini sur TRUE.

 Image 3

Comme le montre l’image ci-dessous, lorsque Nexus-01 est remis en ligne après le rétablissement du courant à la suite d'une panne, le Nexus-02 conserve le rôle d'élément opérationnel PRINCIPAL, quelle que soit sa priorité (car il a un bit persistant TRUE), et Nexus-01 prend le rôle SECONDAIRE lorsqu’il est 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 le Nexus-01, qui est maintenant le périphérique secondaire vPC opérationnel :

• delay restore SVI (10 secondes par défaut) 
• delay restore (30 secondes par défaut)

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

 Image 4

Exemple de panne réseau liée à un bit rémanent défini de manière incorrecte

La panne du 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 de réseau peut se produire après la réintroduction d’un commutateur isolé 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, la valeur de son bit rémanent doit être réglée sur FALSE. (Pour les procédures de remplacement d’un châssis N7K, consultez laProcédure de remplacement du châssis Nexus 7000.)

Comme le montre l’image 5, Nexus-01 est configuré avec une priorité de rôle VPC plus élevée que celle de Nexus-02, et la valeur du bit rémanent de Nexus-02 est définie sur TRUE. Les liens E1/1 et E1/2 du Nexus-01 sont en état de transfert, tandis que E1/1 et E1/2 sont à l'é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 (parce qu'il a un bit TRUE sticky) 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 de relais (40 secondes par défaut).  Dans ce cas, une panne de réseau de 40 secondes se produira après la restauration de la PKA et du lien homologue, comme le montre 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 comporter une priorité de rôle plus élevée pour qu’il conserve son rôle PRINCIPAL. Reportez-vous à l’image 1 de ce document pour en savoir plus sur le processus de sélection de rôle VPC.