Compréhension du processus d'élection de vpc

Introduction

Ce document explique le processus d'élection virtuel de rôle de PortChannel (vpc) sur des Commutateurs de gamme de Nexus.

Contribué par Nikolay Kartashev, juin Wang, Ken Zheng, ingénieurs TAC Cisco.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• vpc sur des Commutateurs de gamme de Nexus
• Protocole Spanning Tree (STP)

Composants utilisés

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

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Technologie virtuelle de PortChannel 

PortChannels virtuel (vpc) permettent les liens qui sont physiquement connectés à deux Ciscoswitches différent pour apparaître comme PortChannel simple à un troisième périphérique. Le troisième périphérique peut être un commutateur, un serveur, ou n'importe quel autre périphérique réseau qui prend en charge IEEE 802.3ad PortChannels. le vpc permet également la création d'une couche 2 PortChannels qui répartissent deux Commutateurs. À ce moment étant, le vpc est mis en application sur Cisco Nexus 9000, 7000, des Plateformes de gammes 5000 et 3000 (avec ou sans l'Extensions de trame de la gamme Cisco Nexus 2000).

Les vpc de Logiciel Cisco NX-OS et les systèmes de commutation de Cisco CatalystVirtual (VSS) sont des Technologies semblables. Pour la technologie Cisco EtherChannel, le terme le « EtherChannel de Multi-châssis (MCEC) » se rapporte l'un pour l'autre à l'un ou l'autre de technologie.

rôle de vpc

Bien que les deux Commutateurs de vpc apparaissent comme commutateur simple à un périphérique en aval, parmi eux-mêmes deux Commutateurs de vpc ont des rôles bien définis de vpc : vpc primaire et vpc secondaire.

les rôles de vpc sont non préemptifs, qui signifie qu'un périphérique peut être configuré comme vpc primaire, mais fonctionne en tant que périphérique secondaire de pair de vpc. Ceci peut se produire dans le scénario suivant :

1. Quand le périphérique maître d'origine échoue, le périphérique secondaire de vpc devient le nouveau périphérique maître 
2. Quand le système se récupère, précédemment le périphérique maître est maintenant le périphérique secondaire et vice versa. 

le rôle de vpc définit qui du vpc deux scrutent les Bridges Protocol Data Unit de processus de périphériques (les BPDU) et répond aux demandes de Protocole ARP (Address Resolution Protocol). le rôle de vpc définit également un ensemble d'actions d'être pris par le vpc primaire et le vpc secondaire en réponse à la situation de vpc peer-link vers le bas. 

role priority de vpc 

Vous pouvez également utiliser la « role priority » dans la commande de mode de vpc domain d'influencer le processus d'élection de vpc. La plage des valeurs est de 1 à 65636, et la valeur par défaut est 32667. Une valeur inférieure signifie que ce commutateur a une meilleure possibilité d'être le vpc primaire.

Changer la priorité des périphériques de pair de vpc peut faire aller les interfaces dans votre réseau en haut et en bas. Si vous voulez configurer la role priority de nouveau pour faire à un périphérique de vpc le périphérique maître, configurez la role priority sur le périphérique primaire de vpc avec une valeur prioritaire plus basse et le périphérique secondaire de vpc avec la valeur supérieure. Puis, arrêtez le lien de pair de vpc sur les deux périphériques en écrivant la commande shutdown, et réactivez finalement le Port canalisé sur les deux périphériques en n'écrivant l'aucune commande shutdown.

Modification Hitless de rôle de vpc

La caractéristique hitless de modification de rôle de vpc fournit un cadre pour commuter des rôles de vpc entre les pairs de vpc sans affecter la circulation. L'échange de rôle de vpc est fait a basé sur la valeur de role priority du périphérique sous le vpc domain. Un périphérique de pair de vpc avec la role priority inférieure est sélectionné comme périphérique primaire de vpc quand le " rôle de vpc acquièrent " la commande est exécuté.

Veuillez voir le scénario de cas d'utilisation pour le rôle Hitless de vpc changer pour plus de détails.

comportement de systèmes de vpc quand un vpc peer-link descend

Quand le vpc peer-link échoue vers le bas et lien de pair-keepalive de vpc est toujours, le périphérique secondaire de pair de vpc exécute les exécutions suivantes :

1. Interrompt ses ports membres de vpc
2. Arrêtent le SVI associé au vpc VLAN

Ce comportement protecteur de vpc réoriente tout le trafic de sud-à-Nord au périphérique maître de vpc.

Veuillez noter que quand le vpc peer-link est en baisse, les deux pair de vpc que les périphériques ne peuvent se synchroniser plus ainsi le mécanisme conçu de protection mène pour isoler un du périphérique de pair (dans l'occurrence le périphérique secondaire de pair) du chemin de données.

bit "sticky" principal de vpc

le bit "sticky" principal de vpc est un mécanisme programmé de protection introduit pour éviter la modification inutile de rôle (qui entraînerait potentiellement l'interruption sur le réseau) quand le commutateur primaire obtient rechargé inopinément. le vpc le bit "sticky" que principal permet le commutateur actif « colle » à son rôle PRIMAIRE quand un commutateur mort est retour actif ou quand un commutateur d'isolement est intégré de nouveau dans le vpc domain.

Basculer le bit "sticky" principal de vpc :

1. la valeur principale de bit "sticky" de vpc sera placée pour rectifier dans les scénarios suivants :
2. la valeur principale de bit "sticky" de vpc sera placée à FAUX quand un commutateur vpc-activé est redémarré (note : Le bit "sticky" est placé à FAUX par défaut)

• Si en cours les réinitialisations de vpc et le vpc primaires commutent des Commutateurs son rôle du vpc secondaire au vpc primaire.
• Quand la caractéristique de « retard-restauration » est configurée.

le bit principal Rémanent de vpc est signalé sous la structure de composant logiciel de gestionnaire de vpc 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 Master: TRUE
Campus_N7K2-VPC#

restauration de retard de vpc

Après que les recharges d'un périphérique de pair de vpc et se réactive, le protocole de routage a besoin d'heure de reconverge. Le tronçon récupérant de vpc peut le trafic routé de trou noir de l'accès à l'agrégation/au noyau jusqu'à ce que la Connectivité de la couche 3 de liaison ascendante soit rétablie.

la caractéristique de restauration de retard de vpc retarde des vpc que le tronçon apportent- sur le périphérique récupérant de pair de vpc. la restauration de retard de vpc tient compte pour que les protocoles de routage de la couche 3 convergent avant de permettre n'importe quel trafic sur le tronçon de vpc. Ceci a comme conséquence une restauration plus gracieuse et une perte de paquets nulle pendant la phase de reprise (le trafic obtiennent toujours détourné sur le périphérique actif de pair de vpc). Cette caractéristique est activée par défaut avec un minuteur par défaut de restauration de vpc de 30 secondes. Le temporisateur peut être accordé selon une spécification de base spécifique de convergence de la couche 3 de 1 à 3600 secondes.

interface vlan de restauration de retard de vpc

Pour retarder les interfaces VLAN sur le périphérique restauré de pair de vpc de monter, utilisez l'option de « interface-VLAN » de la commande « de restauration de retard ». Cette caractéristique est activée par défaut avec un minuteur par défaut de restauration de vpc de 10 secondes.

processus d'élection de vpc

Dans un système de vpc, un périphérique de pair de vpc est défini comme vpc primaire et on est défini comme vpc secondaire, basé sur ces paramètres et dans cette commande

1. Rémanent-bit principal de vpc réglé à 0 ou à 1
2. Role priority définie par l'utilisateur de vpc (le Logiciel Cisco NX-OS emploie la valeur numérique la plus basse pour élire le périphérique maître)
3. Valeur de MAC address de système (le Logiciel Cisco NX-OS emploie la plus basse adresse MAC pour élire le périphérique maître)

Cet organigramme (le schéma 1) récapitule les étapes que les deux périphériques de pair de vpc interviennent pendant le processus d'élection primaire de commutateur de vpc.

1. Le premier paramètre vérifié entre deux périphériques pendant le processus d'élection primaire de vpc est le bit "sticky" principal de vpc. Si le périphérique de pair de vpc gagne cette comparaison, ce deviendra vpc primaire indépendamment de la valeur de role priority configurée de vpc ou des adresses MAC de système que les deux pairs ont.
2. Si les deux Commutateurs de pair de vpc ont la même valeur de bit "sticky", le processus d'élection poursuivra à l'étape suivante pour comparer la role priority définie par l'utilisateur de vpc.  
3. Si les deux rôles de vpc sont configurés à la même valeur, le processus d'élection poursuivra pour comparer les adresses MAC de système.

Figure 1

Suivant les indications du tableau 1, quand le commutateur de vpc a le bit "sticky" principal de vpc réglé à 1 (état VRAI) et son pair avec le bit "sticky" réglé à 0 (état FAUX), le côté VRAI remportera l'élection et assumera le rôle du vpc primaire.

bit "sticky" du pair 1 de vpc réglé à 1	bit "sticky" du pair 2 de vpc réglé à 1	vpc primaire
Faux (0)	Faux (0)	Lien
Rectifiez (1)	Faux (0)	pair 1 de vpc
Faux (0)	Rectifiez (1)	pair 2 de vpc
Rectifiez (1)	Rectifiez (1)	Lien

 Tableau 1 :

scénario de reprise de vpc

L'importance de comprendre le processus d'élection de vpc ne peut pas être sous-estimée, particulièrement dans des scénarios de reprise de vpc.

La figure 2 affiche une installation typique de VPC, Nexus-01 est le VPC primaire et Nexus-02 est le VPC secondaire. Chacun d'eux a leur remise de bits "sticky" à FAUX par défaut.

  

 Figure 2

Suivant les indications de la figure 3, Nexus-01 maintenant a une panne de courant et a été isolé dans le réseau. Nexus-02 s'est favorisé au bit "sticky" de vpc primaire et réglé de vpc POUR RECTIFIER. 

Et Nexus-02 devient maintenant primaire opérationnel, et le bit "sticky" est maintenant placé POUR RECTIFIER.

                        

 Figure 3

Suivant les indications de la figure 4, quand Nexus-01 revient en ligne après que la panne de courant ait été restaurée, Nexus-02 retiendra le rôle PRIMAIRE opérationnel indépendamment de sa role priority (parce qu'elle a un VÉRITABLE bit "sticky") et Nexus-02 jouera le rôle SECONDAIRE quand il est livré en ligne. Seulement Nexus-01 commencera le processus d'initialisation de VPC tandis que N7K-02 restera comme primaire et expédiera le trafic comme d'habitude. Par conséquent, aucune panne de réseau ne sera vue.

Il y a des infidèles associés avec le processus d'initialisation de vpc sur Nexus-01, qui est maintenant le périphérique secondaire opérationnel de vpc :

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

 En conséquence, vous pouvez s'attendre à un temps de rétablissement 40-second sur Nexus-01 après que Nexus-01 soit réintroduit de nouveau dans le réseau comme périphérique secondaire de vpc. Cependant, puisque Nexus-02 joue le rôle primaire, tout le trafic maintenant traverse Nexus-01 comme mentionné ci-dessus, aucune panne de réseau ne sera vue. 

 Figure 4

Un exemple de panne de réseau concernant pour placer incorrectement le bit "sticky"

La panne de réseau est provoqué par par un bit "sticky" INEXACTEMENT réglé quand un commutateur d'isolement (Nexus-02) est introduit de nouveau au vpc domain

Cependant, une panne de réseau peut se produire après qu'un commutateur d'isolement soit introduit de nouveau au vpc domain si les bits "sticky" ne sont pas placés correctement sur les deux Commutateurs de Nexus. Avant qu'un commutateur d'isolement soit introduit de nouveau au vpc domain, son bit "sticky" doit être placé à FAUX. (Les procédures pour remplacer un châssis N7K, voient s'il vous plaît le https://www.cisco.com/c/en/us/support/docs/interfaces-modules/nexus-7000-series-supervisor-1-module/119033-technote-nexus-00.html#anc11)

Suivant les indications de la figure 5, Nexus-01 est configuré avec une role priority plus élevée de VPC que Nexus-02, et Nexus-02has son bit "sticky" réglé POUR RECTIFIER. Le lien E1/1 et E1/2 de Nexus-01 sont dans l'état d'expédition tandis qu'E1/1 et E1/2 dans l'état arrêté. 

 Figure 5

Quand le lien PKA et de pair sont restaurés, Nexus-02 jouera le rôle PRIMAIRE indépendamment de sa role priority (parce qu'il a un VÉRITABLE bit "sticky") et forcer Nexus-01 pour devenir SECONDAIRE et le processus d'initialisation de VPC commencera sur Nexus-01. Par conséquent, le lien E1/1 et E1/2 de Nexus-01 sera interrompu par VPC et sera livré en ligne après que les temporisateurs de restauration de relais (40 secondes par défaut) expirent.  Dans ce cas, une panne de réseau 40-second sera vue après le PKA et le pair que le lien sont restaurés, suivant les indications de la figure 6.

 Figure 6

Note

En réintroduisant un Nexus de nouveau au vpc domain, nous devons nous assurer qu'il n'y aura aucun changement de rôle de vpc du périphérique actif de vpc. Pour éviter un rôle de vpc changez quand les bits "sticky" des deux Commutateurs sont placés à la même valeur, le périphérique actif de vpc doit avoir une role priority plus élevée pour qu'elle retienne son rôle PRIMAIRE. Veuillez se référer à la figure 1 en cet article pour plus d'informations sur le processus d'élection de rôle de VPC.