Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit le processus de sélection du rôle Virtual PortChannel (vPC) sur les commutateurs de la gamme Nexus.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
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.
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).
Note: 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, le terme Multi-chassis EtherChannel (MCEC) désigne indifféremment l'une ou l'autre technologie.
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 principal vPC mais fonctionner comme homologue secondaire vPC. Cela peut se produire dans ce scénario :
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.
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 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.
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.
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 :
Ce comportement de protection de vPC redirige tout le trafic sud-nord vers le périphérique principal vPC.
Veuillez noter que 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, de sorte que le mécanisme de protection conçu entraîne l'isolation de l'un des périphériques homologues (en l'occurrence le périphérique homologue secondaire) du chemin de données.
Le bit rémanent principal vPC est un mécanisme de protection programmé introduit 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 mort revient actif ou lorsqu'un commutateur isolé est intégré de nouveau dans le domaine VPC.
Basculement du bit rémanent du maître vPC :
1. La valeur du bit rémanent principal vPC est TRUE dans ce scénario :
2. La valeur du bit rémanent principal vPC est définie sur FALSE dans les scénarios suivants :
Le bit principal du pense-bête 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 Master: TRUE Campus_N7K2-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 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 é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.
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.
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 pour que la branche VPC soit levée seulement après que tous les SVI soient complètement sortis 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
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
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.
Image 1
Comme l'illustre l'image, lorsque le bit rémanent principal vPC du commutateur vPC est défini sur 1 (condition VRAI) et que son homologue avec le bit rémanent est défini sur 0 (condition FAUX), le côté VRAI gagne la sélection et assume le rôle de principal vPC.
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 |
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 ont la valeur 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-02 prend le rôle SECONDAIRE lorsqu'il se met en ligne. Seul Nexus-01 lance le processus d'initialisation VPC, tandis que N7K-02 reste comme principal 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 :
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
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 de réintroduire un commutateur isolé dans le domaine VPC, son bit rémanent doit être défini sur FALSE. (Procédures de remplacement d'un châssis N7K, consultez 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 à 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 la liaison homologue 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 de relais (40 secondes par défaut). Dans ce cas, une panne réseau de 40 secondes est observée après la restauration de PKA et Peer Link, comme illustré à l'image 6.
Image 6
Note: 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 des rôles VPC.
Révision | Date de publication | Commentaires |
---|---|---|
2.0 |
20-Jul-2022 |
Mise à jour de l'article pour avis de non-responsabilité, fonds, traduction automatique, exigences de style, etc. pour se conformer aux directives de Cisco. |
1.0 |
26-Dec-2017 |
Première publication |