Este documento describe cómo configurar la característica virtual de la auto-recuperación de PortChannel (vPC) en el nexo 7000.
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
¿Por qué necesitamos la Auo-recuperación del vPC?
Hay dos razones principales para esta mejora del vPC:
En la versión 5.2(1) y posterior, la característica de la auto-recuperación del vPC combina estas dos mejoras.
La configuración de la auto-recuperación del vPC es directa. Usted necesita configurar la auto-recuperación bajo dominio del vPC en ambos pares del vPC.
Esto es un ejemplo de configuración:
En el s1 del Switch
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
En el s2 del Switch
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
¿Cómo la auto-recuperación trabaja realmente?
Esta sección discute cada comportamiento mencionado en la sección de información previa por separado. La suposición es que la auto-recuperación del vPC está configurada y guardado a la configuración de inicio en ambos conmuta el s1 y el s2.
Por ejemplo:
El s1 se acciona apagado. El s2 se convierte en el primario operativo como se esperaba. el Par-link y el par-keepalive y todos los links del vPC son disconnected del s1. El s1 no se acciona encendido. Puesto que el s1 se aísla totalmente, acciona el vPC en (aunque los vículos físicos están abajo) debido a la auto-recuperación y toma el papel de primario. Ahora, si el par-link o el par-keepalive está conectado entre el s1 y el s2, el s1 guarda el papel de primario y el s2 llega a ser secundario. Esta configuración hace el s2 suspender su vPC hasta que el par-link y el par-keepalive del vPC se accionen encendido y la Verificación de consistencia es completa. Este escenario causa el tráfico al agujero negro puesto que el vPC del s2 es secundario y los vículos físicos del s1 están apagados.
¿Debo habilitar la auto-recuperación del vPC?
Es una práctica adecuada habilitar la auto-recuperación en su entorno del vPC.
Hay un caso improbable que la característica de la auto-recuperación del vPC pudo crear un escenario dual-activo. Por ejemplo, si usted primero perdió el par-link y entonces usted perdió el par-keepalive, usted tendrá escenario dual-activo.
En esta situación, cada puerto de miembro del vPC continúa haciendo publicidad del mismo protocolo link aggregation control ID que hizo antes del error dual-activo.
Una topología del vPC protege intrínseco contra los loopes en caso de los escenarios dual-activos. En un peor de los casos, hay tramas duplicados. A pesar de esto, como mecanismo de la loop-prevención, Unidades de cada Switch adelante (BPDU) con el mismo Bridge ID BPDU que antes del error dual-activo del vPC.
Mientras que es no intuitivo, es todavía posible y deseable continuar remitiendo el tráfico de la capa de acceso a la capa de la agregación sin los descensos para los flujos de tráfico actuales, a condición de que las tablas del Address Resolution Protocol (ARP) se pueblan ya en ambos pares de las 7000 Series del nexo de Cisco para todos los host necesarios.
Si las nuevas direcciones MAC necesitan ser aprendidas por la tabla ARP, los problemas pudieron presentarse. Los problemas se presentan porque la respuesta ARP del servidor se pudo desmenuzar a un dispositivo de las 7000 Series del nexo de Cisco y no al otro, que hace imposible para que fluya el tráfico correctamente.
Suponga, sin embargo, que antes del error en la situación apenas descrita, el tráfico fue distribuido igualmente a los dispositivos de las 7000 Series del nexo de Cisco por un PortChannel correcto y por una configuración de trayectoria múltiple del igual costo (ECMP). En este caso, el servidor-a-servidor y el tráfico del cliente-a-servidor continúa con la advertencia que solo-asoció los host conectados directamente con las 7000 Series del nexo de Cisco no podrá comunicar (para la falta del link del par). También, las nuevas direcciones MAC aprendidas en las 7000 Series de un nexo de Cisco no se pueden aprender en el par, porque ésta causaría el tráfico de retorno que llega en el dispositivo de las 7000 Series del nexo de Cisco del par para inundar.
Refiera a la página 19 del Software Cisco NX-OS PortChannel virtual: Conceptos fundamentales para más información.
Actualmente, no hay un procedimiento de verificación disponible para esta configuración.
Actualmente, no hay información específica de troubleshooting disponible para esta configuración.