Ejemplo de configuración de la característica de la Auto-recuperación del vPC del nexo 7000
Contenido
Introducción
Este documento describe cómo configurar la característica virtual de la auto-recuperación de PortChannel (vPC) en el nexo 7000.
Prerequisites
Requisitos
No hay requisitos específicos para este documento.
Componentes Utilizados
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.
Antecedentes
¿Por qué necesitamos la Auo-recuperación del vPC?
Hay dos razones principales para esta mejora del vPC:
- En una caída del sistema o una interrupción de la alimentación eléctrica del centro de datos, ambos pares del vPC que se comprenden de los 7000 Switch del nexo están apagados. De vez en cuando, solamente uno de los pares puede ser restablecido. Puesto que el otro nexo 7000 todavía está apagado, el par-link del vPC y el link del par-keepalive del vPC están también apagado. En este escenario, el vPC no se adelanta incluso para el nexo 7000 que está ya encendido. Todas las configuraciones del vPC tienen que ser quitadas del canal del puerto en eso el nexo 7000 para hacer el canal del puerto trabajar. Cuando se adelanta el otro nexo 7000, usted tiene que realizar otra vez los cambios de configuración para incluir la configuración del vPC para todos los vPCs. En la versión 5.0(2) y posterior, usted puede configurar el comando restore de la recarga bajo vPC Domain Configuration (Configuración del dominio) de abordar este problema.
- Por alguna razón, el par-link del vPC se apaga. Puesto que el par-keepalive del vPC todavía está encendido, el dispositivo de peer secundario del vPC da vuelta a todos sus puertos de miembro del vPC de debido a la detección dual-activa. Por lo tanto todo el tráfico pasa a través del Switch primario del vPC. Por alguna razón, el Switch primario del vPC también se apaga. Agujeros negros de este problema del Switch el tráfico puesto que los vPCs en el dispositivo de peer secundario todavía están apagado porque detectó la detección dual-activa antes de que se apagara el Switch primario 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.
Configuración
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.
- Una interrupción de la alimentación eléctrica apagó ambos nexos 7000 pares del vPC simultáneamente y solamente un Switch puede adelantarse.
- S1 y el s2 están ambos prendido. el vPC se forma correctamente con el par-link y el par-keepalive encendido.
- Poder del s1 y del s2 apagado simultáneamente.
- Solamente un Switch puede ahora accionar encendido. Por ejemplo, el s2 es el único Switch que acciona encendido.
- El s2 espera el descanso de la auto-recuperación del vPC (el valor por defecto es 240 segundos que se pueden configurar con el comando x del recarga-retardo de la auto-recuperación, donde está segundos x del 240-3600) para verificar si los poderes del estatus del par-link o del par-keepalive del vPC encendido. Si ninguno de estos links están prendido (estatus del par-link o del par-keepalive), la auto-recuperación no se acciona.
- Después del descanso, si ambos links todavía están apagado (estatus del par-link así como del par-keepalive), los permisos de la auto-recuperación del vPC y el s2 llegan a ser primarios e inician para accionar encendido su vPC local. Puesto que no hay pares, se desvía la Verificación de consistencia.
- Ahora el s1 se adelanta. Ahora, el s2 conserva su función primaria y el s1 toma rol secundario, se realiza una Verificación de consistencia, y se toman las acciones apropiadas.
- poderes del par-link del vPC apagado primero y después los poderes primarios del par del vPC apagado.
- S1 y el s2 están ambos prendido y el vPC se forma correctamente con el par-link y el par-keepalive encendido.
- Por alguna razón, el par-link del vPC se apaga primero.
- Puesto que el par-keepalive del vPC todavía está encendido, detecta la detección dual-activa. El s2 secundario del vPC apaga todos sus vPCs locales.
- Ahora el s1 primario del vPC se apaga o las recargas.
- Esta caída del sistema también apaga el link del par-keepalive del vPC.
- El s2 espera tres mensajes consecutivos del par-keepalive que se perderán. Por alguna razón, o el par-link del vPC se adelanta o el s2 recibe un mensaje del par-keepalive, y la auto-recuperación no habilita.
- Sin embargo, si sigue habiendo el par-link apagado y se pierden tres mensajes consecutivos del par-keepalive, permisos de la auto-recuperación del vPC.
- El s2 asume el papel de primario y habilita su vPC local que desvíe la Verificación de consistencia.
- Cuando el s1 completa la recarga, el s2 conserva su papel de primario y el s1 llega a ser secundario, se realiza una Verificación de consistencia, y se toman las acciones apropiadas.
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.
Verificación
Actualmente, no hay un procedimiento de verificación disponible para esta configuración.
Troubleshooting
Actualmente, no hay información específica de troubleshooting disponible para esta configuración.
Información Relacionada
ComentariosDéjenos ayudarlo
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)