El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe el proceso de elección de la función Virtual PortChannel (vPC) en los switches de la serie Nexus.
Cisco recomienda que tenga conocimiento sobre estos temas:
La información de este documento se basa en la plataforma de switches Nexus serie 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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Los PortChannel virtuales (vPC) permiten que los enlaces que están conectados físicamente a dos switches Cisco diferentes aparezcan como un único PortChannel para un tercer dispositivo. El tercer dispositivo puede ser un switch, un servidor o cualquier otro dispositivo de red que admita PortChannels IEEE 802.3ad. vPC también permite la creación de PortChannels de capa 2 que abarcan dos switches. En este momento, vPC se implementa en las plataformas Nexus de Cisco series 9000, 7000, 5000 y 3000 (con o sin Fabric Extenders Nexus de Cisco serie 2000).
Nota: Las vPC con software Cisco NX-OS y los sistemas de switching virtual Cisco Catalyst Virtual Switching Systems (VSS) son de tecnologías similares. Para la tecnología Cisco EtherChannel, el término Multi-chassis EtherChannel (MCEC) se refiere indistintamente a cualquiera de las dos tecnologías.
Aunque ambos switches vPC aparecen como un único switch para un dispositivo de flujo descendente, entre ellos dos switches vPC tienen roles vPC claramente definidos: vPC principal y vPC secundario.
Las funciones de vPC no son preventivas, lo que significa que un dispositivo se puede configurar como vPC principal pero funciona como dispositivo par secundario de vPC. Esto puede suceder en este escenario:
El rol vPC define cuál de los dos dispositivos de par vPC procesa las unidades de datos del protocolo de puente (BPDU) y responde a las solicitudes del protocolo de resolución de direcciones (ARP). El rol vPC también define un conjunto de acciones que deben realizar vPC principal y vPC secundario en respuesta a una situación de desconexión del enlace de par vPC.
También puede utilizar el comando role priority en el modo de dominio vPC para influir en el proceso de elección de vPC. El rango de valores va de 1 a 65636 y el valor predeterminado es 32667. Un valor inferior significa que este switch tiene más posibilidades de ser el vPC principal.
Cuando cambia la prioridad de los dispositivos de par vPC, puede hacer que las interfaces de la red suban y bajen. Si desea volver a configurar la prioridad de rol para convertir un dispositivo vPC en el dispositivo principal, configure la prioridad de rol tanto en el dispositivo vPC principal con un valor de prioridad inferior como en el dispositivo vPC secundario con el valor superior. A continuación, apague el enlace de par vPC en ambos dispositivos e ingrese el comando shutdown y, finalmente, vuelva a habilitar el canal de puerto en ambos dispositivos e ingrese el comando no shutdown.
La función de cambio de roles sin impacto de vPC proporciona un marco para cambiar los roles de vPC entre pares vPC sin que ello afecte a los flujos de tráfico. El intercambio de funciones de vPC se realiza en función del valor de prioridad de funciones del dispositivo en el dominio vPC. Un dispositivo par vPC con menor prioridad de rol se selecciona como el dispositivo vPC principal cuando se ejecuta el comando vpc role preempt.
Consulte Escenario de caso práctico de cambio de función de vPC sin impacto para obtener más detalles.
Cuando el enlace de par vPC falla y el enlace de par keepalive vPC sigue activo, el dispositivo de par secundario vPC realiza estas operaciones:
Este comportamiento de protección de vPC redirige todo el tráfico de sur a norte al dispositivo principal vPC.
Tenga en cuenta que cuando el enlace de par vPC está inactivo, ambos dispositivos de par vPC ya no pueden sincronizarse entre sí, por lo que el mecanismo de protección diseñado lleva al aislamiento de uno de los dispositivos de par (en caso de que se produzca el dispositivo de par secundario) de la ruta de datos.
El bit fijo de vPC Master es un mecanismo de protección programado introducido para evitar cambios de funciones innecesarios (que podrían causar interrupciones en la red) cuando el switch principal se recarga de forma inesperada. vPC Master Sticky Bit permite que el switch activo se adhiera a su función PRINCIPAL cuando un switch inactivo vuelve a estar activo o cuando un switch aislado se integra de nuevo en el dominio VPC.
Conmutación del bit persistente maestro de vPC:
1. El valor de bit persistente maestro de vPC se establece en TRUE en este escenario:
2. El valor de bit persistente maestro de vPC se establece en FALSE en estos escenarios:
El bit maestro vPC Sticky se informa en la estructura de componentes del software vPC Manager y se puede comprobar con este comando de modo NX-OS exec.
Campus_N7K2-VPC# show system internal vpcm info global | include ignore-case sticky Sticky Master: TRUE Campus_N7K2-VPC#
Después de que un dispositivo par vPC se recargue y vuelva a estar activo, el protocolo de routing necesita tiempo para volver a converger. El tramo de recuperación de vPC puede bloquear el tráfico enrutado desde el acceso a la agregación/núcleo hasta que se restablezca la conectividad de enlace ascendente de capa 3.
La función vPC Delay Restore retrasa el inicio del tramo de vPC en el dispositivo par vPC que se recupera. vPC Delay Restore permite que los protocolos de routing de capa 3 converjan antes de permitir el tráfico en el tramo vPC. Esto se traduce en una restauración más fluida y cero pérdidas de paquetes durante la fase de recuperación (el tráfico sigue desviándose en el dispositivo de par vPC activo). Esta función está activada de forma predeterminada con un temporizador predeterminado de restauración vPC de 30 segundos. El temporizador se puede ajustar a una línea de base de convergencia de Capa 3 específica de 1 a 3600 segundos.
Para retrasar la aparición de las interfaces VLAN en el dispositivo par vPC restaurado, utilice la opción interfaces-vlan del comando delay restore. Esta función se habilita de forma predeterminada con un temporizador predeterminado de restauración vPC de 10 segundos.
Se introduce un nuevo comando delay restore interface-VLAN batch <1-4094> para configurar el marcador para activar las interfaces VLAN o de dominio de puente en un lote de 200 SVI a la vez. El comando de temporizador de restauración de retraso vPC delay restore <valor de tiempo de espera> se puede configurar en un valor mayor que la suma de todos los temporizadores por lotes configurados. Esto se hace para que el tramo VPC se active solo después de que todas las SVI se hayan activado completamente para evitar cualquier agujero negro de tráfico.
Ejemplo: 4000 VLAN, 200 lotes, retraso de 15 s
delay restore > (4000/200)x 15
En un sistema vPC, un dispositivo vPC por dispositivo se define como vPC principal y otro como vPC secundario, en función de estos parámetros y en este orden
Este diagrama de flujo (Imagen 1) resume los pasos que ambos dispositivos de par vPC siguen durante el proceso de elección del switch principal vPC.
Imagen 1
Como se muestra en la imagen, cuando el switch vPC tiene el bit persistente maestro vPC establecido en 1 (condición TRUE) y su par con el bit persistente establecido en 0 (condición FALSE), el lado TRUE gana la elección y asume la función de vPC principal.
Bit fijo de par 1 de vPC establecido en 1 | Bit fijo de par 2 de vPC establecido en 1 | vPC principal |
Falso (0) | Falso (0) | Corbata |
Verdadero (1) | Falso (0) | Par 1 de vPC |
Falso (0) | Verdadero (1) | Par 2 de vPC |
Verdadero (1) | Verdadero (1) | Corbata |
Es importante comprender el proceso de elección de vPC y no se puede subestimar, especialmente en escenarios de recuperación de vPC.
La imagen 2 muestra una configuración de VPC típica, Nexus-01 es el VPC principal y Nexus-02 es el VPC secundario. Ambos tienen sus Bits pegajosos reconfigurados a FALSE de forma predeterminada.
Imagen 2
Como se muestra en esta imagen, el Nexus-01 tiene ahora un corte de energía y se ha aislado de la red. Nexus-02 se promocionó a vPC principal y estableció vPC Sticky Bit en TRUE.
Y ahora el Nexus-02 se convierte en Operational Primary (Primario operativo) y el bit fijo se establece en TRUE.
Imagen 3
Como se muestra en esta imagen, cuando el Nexus-01 vuelve a estar online después de que se haya restablecido el corte de electricidad, el Nexus-02 conserva la función PRIMARIO operativo independientemente de su prioridad de función (porque tiene un bit realmente pegajoso) y el Nexus-02 desempeña la función SECUNDARIO cuando se conecta. Sólo Nexus-01 inicia el proceso de inicialización de VPC, mientras que N7K-02 permanece como principal y reenvía el tráfico como de costumbre. Por lo tanto, no se observa ninguna interrupción en la red.
Hay dos temporizadores asociados con el proceso de inicialización de vPC en Nexus-01, que ahora es el dispositivo secundario operativo de vPC:
Como resultado, puede esperar un tiempo de recuperación de 40 segundos en el Nexus-01 después de que este se vuelva a introducir en la red como dispositivo secundario vPC. Sin embargo, dado que Nexus-02 desempeña la función principal, todo el tráfico pasa ahora a través de Nexus-01, como se ha mencionado anteriormente, no se observa ninguna interrupción en la red.
Imagen 4
La interrupción de la red se debe a un bit persistente configurado INCORRECTAMENTE cuando se introduce de nuevo un switch aislado (Nexus-02) en el dominio VPC
Sin embargo, se puede producir una interrupción de la red después de que un switch aislado se introduzca de nuevo en el dominio VPC si los bits persistentes no se configuran correctamente en ambos switches Nexus. Antes de que un switch aislado se introduzca de nuevo en el dominio VPC, su bit persistente debe establecerse en FALSE. (Procedimientos para reemplazar un chasis N7K, consulte https://www.cisco.com/c/en/us/support/docs/interfaces-modules/nexus-7000-series-supervisor-1-module/119033-technote-nexus-00.html#anc11)
Como se muestra en la imagen 5, el Nexus-01 está configurado con una prioridad de rol de VPC mayor que el Nexus-02, y el Nexus-02 tiene el bit persistente establecido en TRUE. Los enlaces E1/1 y E1/2 de Nexus-01 se encuentran en estado de reenvío, mientras que E1/1 y E1/2 se encuentran en estado de apagado.
Imagen 5
Cuando se restauran el PKA y el enlace de par, Nexus-02 asume la función PRINCIPAL independientemente de su prioridad de función (porque tiene un bit persistente TRUE) y fuerza a Nexus-01 a convertirse en SECUNDARIO y el proceso de inicialización de VPC comienza en Nexus-01. Por lo tanto, el VPC suspende el enlace E1/1 y E1/2 del Nexus-01 y se pone en línea después de que caduquen los temporizadores de restauración de relé (40 segundos de forma predeterminada). En este caso, se observa una interrupción de la red de 40 segundos después de restaurar el PKA y el enlace de par, como se muestra en la imagen 6.
Imagen 6
Nota: Cuando se vuelve a introducir un Nexus en el dominio vPC, debe asegurarse de que no hay ningún cambio de función de vPC en el dispositivo vPC activo. Para evitar un cambio de función de vPC cuando los bits persistentes de ambos switches se establecen en el mismo valor, el dispositivo vPC activo debe tener una prioridad de función más alta para poder conservar su función PRINCIPAL. Consulte la imagen 1 de este documento para obtener más información sobre el proceso de elección de roles de VPC.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
2.0 |
20-Jul-2022 |
Artículo actualizado para descargos legales, justificantes, traducción automática, requisitos de estilo, etc. para cumplir con las directrices de Cisco. |
1.0 |
26-Dec-2017 |
Versión inicial |