Avez-vous un compte?
Ce document décrit comment configurer la caractéristique virtuelle d'automatique-reprise de PortChannel (vpc) sur le Nexus 7000.
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
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.
Pourquoi avons-nous besoin de l'Auo-reprise de vpc ?
Il y a deux principales raisons pour cette amélioration de vpc :
Dans la version 5.2(1) et ultérieures, la caractéristique d'automatique-reprise de vpc fusionne ces deux améliorations.
La configuration de l'automatique-reprise de vpc est simple. Vous devez configurer l'automatique-reprise sous le vpc domain sur les deux pairs de vpc.
C'est un exemple de configuration :
Sur le commutateur S1
S1 (config)# vpc domain
S1(config-vpc-domain)# auto-recovery
S1# show vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 5
Peer Gateway : Enabled
Peer gateway excluded VLANs : -
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ --------------------------------------------------
1 Po1 up 1-112,114-120,800,810
vPC status
-----------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
-- ---- ------ ----------- ------ ------------
10 Po40 up success success 1-112,114-1
20,800,810
Sur le commutateur S2
S2 (config)# vpc domain 1
S2(config-vpc-domain)# auto-recovery
S2# show vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : secondary
Number of vPCs configured : 5
Peer Gateway : Enabled
Peer gateway excluded VLANs : -
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Enabled (timeout = 240 seconds)
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ --------------------------------------------------
1 Po1 up 1-112,114-120,800,810
vPC status ----------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
-- ---- ------ ----------- ------ ------------
40 Po40 up success success 1-112,114-1
20,800,810
Comment l'automatique-reprise fonctionne-t-elle vraiment ?
Cette section discute chaque comportement mentionné dans la section Informations générales séparément. La supposition est que l'automatique-reprise de vpc est configurée et enregistrée à la configuration de démarrage sur les Commutateurs S1 et le S2.
Exemple :
Le S1 est mis hors tension. S2 devient le primaire opérationnel comme prévu. le Pair-lien et la pair-keepalive et tous les liens de vpc sont déconnectés du S1. Le S1 n'est pas mis sous tension. Puisque le S1 est complètement isolé, il actionne le vpc sur (bien que les liens physiques sont en baisse) en raison de l'automatique-reprise et joue le rôle de primaire. Maintenant, si le pair-lien ou la pair-keepalive sont connectés entre le S1 et le S2, le S1 garde le rôle de primaire et S2 devient secondaire. Cette configuration fait interrompre S2 son vpc jusqu'à ce que le vpc peer-link et la pair-keepalive soient mis sous tension et le contrôle de cohérence est complet. Ce scénario entraîne le trafic au trou noir puisque le vpc S2 est secondaire et les liens S1 physiques sont éteints.
Est-ce que je devrais activer l'automatique-reprise de vpc ?
Automatique-reprise d'enable d'il est conseillé de dans votre environnement de vpc.
Il y a une légère occasion que la caractéristique d'automatique-reprise de vpc pourrait créer un scénario double-actif. Par exemple, si vous perdiez la première fois le pair-lien et alors vous perdiez la pair-keepalive, vous aurez le scénario double-actif.
Dans cette situation, chaque port membre de vpc continue à annoncer le même ID de Control Protocol d'agrégation de liaisons qu'il a fait avant la panne double-active.
Une topologie de vpc se protège intrinsèquement contre des boucles en cas de scénarios double-actifs. Dans un scénario de le pire des cas, il y a des trames en double. En dépit de ceci, comme mécanisme de boucle-prévention, Bridges Protocol Data Unit de chaque commutateur en avant (BPDU) avec le même ID de passerelle BPDU qu'avant la panne double-active de vpc.
Tandis que non intuitif, il est encore possible et desirable de continuer à expédier le trafic de la couche d'accès à la couche d'agrégation sans baisses pour la circulation en cours, à condition que les tables de Protocole ARP (Address Resolution Protocol) soient déjà remplies sur les deux pairs de gamme 7000 de Cisco Nexus pour tous les serveurs nécessaires.
Si de nouvelles adresses MAC doivent être apprises par la table ARP, les questions pourraient surgir. Les questions surgissent parce que la réponse d'ARP du serveur pourrait être hachée à un périphérique de gamme 7000 de Cisco Nexus et pas à l'autre, qui le rend impossible pour que le trafic circule correctement.
Supposez, cependant, qu'avant la panne dans la situation juste décrite, le trafic a été également distribué aux deux périphériques de gamme 7000 de Cisco Nexus par un PortChannel correct et par une configuration par trajets multiples de coût égal (ECMP). Dans ce cas, le trafic de serveur-à-serveur et de topologie continue la mise en garde qui simple-a relié des serveurs connectés directement à la gamme 7000 de Cisco Nexus ne pourra pas communiquer (pour le manque du lien de pair). En outre, de nouvelles adresses MAC apprises sur la gamme 7000 d'un Cisco Nexus ne peuvent pas être apprises sur le pair, parce que ceci entraînerait le trafic de retour qui arrive sur le périphérique de gamme 7000 de Cisco Nexus de pair pour inonder.
Référez-vous à la page 19 du Logiciel Cisco NX-OS PortChannel virtuel : Pour en savoir plus fondamental de concepts.
Aucune procédure de vérification n'est disponible pour cette configuration.
Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.