Descripción de VRRP
El Protocolo de redundancia de enrutador virtual (VRRP) se puede usar para crear plataformas de enrutamiento redundantes virtuales en una LAN, lo que permite enrutar el tráfico en la LAN sin la necesidad de una sola plataforma de enrutamiento.
Descripción de VRRP
Para Ethernet, Fast Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet e interfaces lógicas, puede configurar el Protocolo de redundancia de enrutador virtual (VRRP) o VRRP para IPv6. VRRP permite a los hosts en una LAN hacer uso de plataformas de enrutamiento redundantes en esa LAN sin requerir más que la configuración estática de una única ruta predeterminada en los hosts. Las plataformas de enrutamiento VRRP comparten la dirección IP correspondiente a la ruta predeterminada configurada en los hosts. En cualquier momento, una de las plataformas de enrutamiento VRRP es la principal (activa) y las otras son copias de seguridad. Si se produce un error en la plataforma de enrutamiento principal, una de las plataformas de enrutamiento de respaldo se convierte en la nueva plataforma de enrutamiento principal, lo que proporciona una plataforma de enrutamiento predeterminada virtual y permite enrutar el tráfico en la LAN sin la necesidad de una sola plataforma de enrutamiento. Con VRRP, un dispositivo de copia de seguridad puede hacerse cargo de un dispositivo predeterminado defectuoso en unos pocos segundos. Esto se hace con un tráfico VRRP mínimo y sin ninguna interacción con los hosts. El protocolo de redundancia de enrutador virtual no se admite en las interfaces de administración.
Los dispositivos que ejecutan VRRP eligen dinámicamente a los dispositivos principales y de respaldo. También puede forzar la asignación de dispositivos principales y de copia de seguridad mediante prioridades del 1 al 255, siendo 255 la prioridad más alta. En la operación VRRP, el dispositivo principal predeterminado envía anuncios a los dispositivos de respaldo a intervalos regulares. El intervalo predeterminado es de 1 segundo. Si un dispositivo de copia de seguridad no recibe un anuncio durante un período determinado, el dispositivo de copia de seguridad con la siguiente prioridad más alta toma el control como principal y comienza a reenviar paquetes.
No se puede establecer la prioridad 255 para interfaces VLAN enrutadas (RVI).
Para minimizar el tráfico de red, VRRP está diseñado de tal manera que solo el dispositivo que actúa como principal envía anuncios VRRP en un momento dado. Los dispositivos de copia de seguridad no envían ningún anuncio hasta que asuman el rol principal.
VRRP para IPv6 proporciona una conmutación mucho más rápida a un enrutador predeterminado alternativo que los procedimientos de detección de vecinos de IPv6. Las implementaciones típicas utilizan solo un enrutador de respaldo.
No confunda las plataformas de enrutamiento principal y de respaldo de VRRP con los conmutadores miembro principal y de respaldo de una configuración de chasis virtual . Los miembros principal y de respaldo de una configuración de chasis virtual componen un único host. En una topología VRRP, un host funciona como la plataforma de enrutamiento principal y otro opera como la plataforma de enrutamiento de respaldo, como se muestra en la Figura 3.
VRRP se define en RFC 3768, Protocolo de redundancia de enrutador virtual. VRRP para IPv6 se define en draft-ietf-vrrp-ipv6-spec-08.txt, Protocolo de redundancia de enrutador virtual para IPv6. Consulte también draft-ietf-vrrp-unified-mib-06.txt, Definiciones de objetos administrados para VRRP sobre IPv4 e IPv6.
Aunque VRRP, tal como se define en RFC 3768, no admite la autenticación, la implementación de VRRP en Junos OS admite la autenticación como se define en RFC 2338. Este soporte se logra a través de las opciones de compatibilidad con versiones anteriores en RFC 3768.
En los conmutadores EX2300 y EX3400, el protocolo VRRP debe configurarse con un intervalo de saludo de 2 segundos o más, con un intervalo muerto no inferior a 6 segundos para evitar oscilaciones durante eventos de operaciones intensivas de CPU, como conmutación de motor de enrutamiento, oscilaciones de interfaz y recopilación exhaustiva de datos del motor de reenvío de paquetes.
La Figura 1 ilustra una topología VRRP básica. En este ejemplo, los enrutadores A, B y C ejecutan VRRP y juntos forman un enrutador virtual. La dirección IP de este enrutador virtual es 10.10.0.1 (la misma dirección que la interfaz física del enrutador A).
básico
Dado que el enrutador virtual utiliza la dirección IP de la interfaz física del enrutador A, el enrutador A es el enrutador VRRP principal, mientras que los enrutadores B y C funcionan como enrutadores VRRP de respaldo. Los clientes del 1 al 3 están configurados con la dirección IP de puerta de enlace predeterminada de 10.10.0.1. Como enrutador principal, el enrutador A reenvía los paquetes enviados a su dirección IP. Si se produce un error en el enrutador virtual principal, el enrutador configurado con la prioridad más alta se convierte en el enrutador virtual principal y proporciona un servicio ininterrumpido para los hosts de LAN. Cuando el enrutador A se recupera, vuelve a ser el enrutador virtual principal.
En algunos casos, durante una sesión heredada, hay un breve período de tiempo durante el cual dos enrutadores están en estado primario-principal. En tales casos, los grupos VRRP que heredan el estado envían anuncios VRRP cada 120 segundos. Por lo tanto, los enrutadores tardan hasta 120 segundos en recuperarse después de pasar al estado Principal-Copia de seguridad desde el estado Principal-Principal.
Los enrutadores de la serie ACX pueden admitir hasta 64 entradas de grupo VRRP. Pueden ser una combinación de familias IPv4 o IPv6. Si cualquiera de la familia (IPv4 o IPv6) está configurado únicamente para VRRP, se admiten 64 identificadores de grupo VRRP únicos. Si las familias IPv4 e IPv6 comparten el mismo grupo VRRP, solo se admiten 32 identificadores VRRP únicos.
Los enrutadores de la serie ACX admiten la versión 3 de VRRP para direcciones IPv6.
El enrutador ACX5448 admite RFC 3768 VRRP versión 2 y RFC 5798 VRRP versión 3. El enrutador ACX5448 también admite la configuración de VRRP mediante Ethernet agregada e interfaces de enrutamiento y puente integrados (IRB).
Se aplican las siguientes limitaciones al configurar VRRP en el enrutador ACX5448:
-
Configure un máximo de 16 grupos VRRP.
-
No se admite el interfuncionamiento de VRRP versión 2 y VRRP versión 3.
-
No se admite el procesamiento de delegado VRRP.
-
No se admite la autenticación VRRP versión 2.
La figura 1 ilustra una topología VRRP básica con conmutadores de la serie EX. En este ejemplo, los conmutadores A, B y C ejecutan VRRP y juntos forman una plataforma de enrutamiento virtual. La dirección IP de esta plataforma de enrutamiento virtual es 10.10.0.1 (la misma dirección que la interfaz física del conmutador A).
de la serie EX
La figura 3 ilustra una topología VRRP básica mediante configuraciones de chasis virtual. Los conmutadores A, B y C están compuestos por múltiples conmutadores Ethernet EX4200 de Juniper Networks interconectados. Cada configuración de chasis virtual funciona como un solo conmutador, que ejecuta VRRP, y juntos forman una plataforma de enrutamiento virtual. La dirección IP de esta plataforma de enrutamiento virtual es 10.10.0.1 (la misma dirección que la interfaz física del conmutador A).
de chasis virtual
Dado que la plataforma de enrutamiento virtual usa la dirección IP de la interfaz física del conmutador A, el conmutador A es la plataforma de enrutamiento VRRP principal, mientras que los conmutadores B y C funcionan como plataformas de enrutamiento VRRP de respaldo. Los clientes del 1 al 3 están configurados con la dirección IP de puerta de enlace predeterminada de 10.10.0.1 como el enrutador principal, el conmutador A reenvía los paquetes enviados a su dirección IP. Si se produce un error en la plataforma de enrutamiento principal, el conmutador configurado con la prioridad más alta se convierte en la plataforma de enrutamiento virtual principal y proporciona un servicio ininterrumpido para los hosts de LAN. Cuando el conmutador A se recupera, vuelve a convertirse en la plataforma de enrutamiento virtual principal.
Descripción general de VRRP y VRRP para IPv6
Puede configurar el Protocolo de redundancia de enrutador virtual (VRRP) y VRRP para IPv6 para las siguientes interfaces:
Ethernet
Ethernet rápido
Ethernet de triple velocidad de cobre
Gigabit Ethernet:
PIC de LAN/WAN Ethernet de 10 Gigabit
interfaces lógicas de Ethernet
VRRP y VRRP para IPv6 permiten que los hosts en una LAN usen enrutadores redundantes en esa LAN sin requerir más que la configuración estática de una única ruta predeterminada en los hosts. Los enrutadores VRRP comparten la dirección IP correspondiente a la ruta predeterminada configurada en los hosts. En cualquier momento, uno de los enrutadores VRRP es el principal (activo) y los demás son copias de seguridad. Si se produce un error en el principal, uno de los enrutadores de respaldo se convierte en el nuevo enrutador principal, con lo que siempre se proporciona un enrutador virtual predeterminado y se permite enrutar el tráfico en la LAN sin depender de un solo enrutador.
VRRP se define en RFC 3768, Protocolo de redundancia de enrutador virtual.
Para obtener información general de VRRP y VRRP para IPv6, instrucciones de configuración y resúmenes de instrucciones, consulte la Guía del usuario de alta disponibilidad de Junos OS.
Soporte de Junos OS para VRRPv3
La ventaja de usar VRRPv3 es que VRRPv3 admite familias de direcciones IPv4 e IPv6, mientras que VRRPv2 solo admite direcciones IPv4.
En los temas siguientes se describen la compatibilidad e interoperabilidad de Junos OS de VRRPv3, así como algunas diferencias entre VRRPv3 y sus precursores:
- Soporte VRRP de Junos OS
- Diferencias de comportamiento de la suma de comprobación VRRP IPv6
- Interoperabilidad de VRRP
- Actualizar de VRRPv2 a VRRPv3
- Funcionalidad de las características de VRRPv3
Soporte VRRP de Junos OS
En versiones anteriores a la versión 12.2, Junos OS admitía RFC 3768, Protocolo de redundancia de enrutador virtual (VRRP) (para IPv4) y el borrador de Internet draft-ietf-vrrp-ipv6-spec-08, Protocolo de redundancia de enrutador virtual para IPv6.
VRRPv3 no se admite en enrutadores que utilizan versiones anteriores a Junos OS versión 12.2 y tampoco se admite para IPv6 en conmutadores QFX10000.
VRRPv3 para IPv6 es compatible con QFX10002-60C.
A partir de la versión 12.2, Junos OS admite lo siguiente:
RFC 3768, Protocolo de redundancia de enrutador virtual (VRRP)
RFC 5798, Protocolo de redundancia de enrutador virtual (VRRP) versión 3 para IPv4 e IPv6
RFC 6527, Definiciones de objetos administrados para el protocolo de redundancia de enrutador virtual versión 3 (VRRPv3)
VRRP (para IPv6) en enrutadores que utilizan la versión 12.2 de Junos OS y versiones posteriores no interopera con VRRP (para IPv6) en enrutadores con versiones anteriores de Junos OS debido a las diferencias en los cálculos de suma de comprobación de VRRP. Consulte Diferencias de comportamiento de suma de comprobación VRRP IPv6.
Diferencias de comportamiento de la suma de comprobación VRRP IPv6
Debe tener en cuenta las siguientes diferencias de suma de comprobación al habilitar redes VRRP IPv6:
En versiones anteriores a Junos OS versión 12.2, cuando VRRP para IPv6 está configurado, la suma de comprobación de VRRP se calcula de acuerdo con la sección 5.3.8 de RFC 3768, Protocolo de redundancia de enrutador virtual (VRRP).
A partir de Junos OS versión 12.2, cuando VRRP para IPv6 está configurado, independientemente de si VRRPv3 está habilitado o no, la suma de comprobación de VRRP se calcula de acuerdo con la sección 5.2.8 del RFC 5798, Protocolo de redundancia de enrutador virtual (VRRP) versión 3 para IPv4 e IPv6.
Además, el pseudoencabezado solo se incluye al calcular la suma de comprobación de VRRP IPv6. El pseudoencabezado no se incluye al calcular la suma de comprobación de VRRP IPv4.
Para hacer que el enrutador con Junos OS versión 12.2 (o versiones posteriores de Junos OS) VRRP IPv6 interopere con el enrutador que ejecuta una versión de Junos OS anterior a la versión 12.2, incluya la
checksum-without-pseudoheaderinstrucción de configuración en el nivel de[edit protocols vrrp]jerarquía en el enrutador que ejecuta Junos OS versión 12.2 o posterior.La
tcpdumputilidad de Junos OS versión 12.2 y posteriores calcula la suma de comprobación de VRRP según RFC 5798, Protocolo de redundancia de enrutador virtual (VRRP) versión 3 para IPv4 e IPv6. Por lo tanto, cuandotcpdumpanaliza paquetes VRRP IPv6 recibidos de versiones anteriores de Junos OS (anteriores a la versión 12.2 de Junos OS), se muestra elbad vrrp cksummensaje:23:20:32.657328 Out ... -----original packet----- 00:00:5e:00:02:03 > 33:33:00:00:00:12, ethertype IPv6 (0x86dd), length 94: (class 0xc0, hlim 255, next-header: VRRP (112), length: 40) fe80::224:dcff:fe47:57f > ff02::12: VRRPv3-advertisement 40: vrid=3 prio=100 intvl=100(centisec) (bad vrrp cksum b4e2!) addrs(2): fe80::200:5eff:fe00:3,2001:4818:f000:14::1 3333 0000 0012 0000 5e00 0203 86dd 6c00 0000 0028 70ff fe80 0000 0000 0000 0224 dcff fe47 057f ff02 0000 0000 0000 0000 0000 0000 0012 3103 6402 0064 b4e2 fe80 0000 0000 0000 0200 5eff fe00 0003 2001 4818 f000 0014 0000 0000 0000 0001Puede ignorar este mensaje porque no indica una falla de VRRP.
Interoperabilidad de VRRP
En versiones anteriores a Junos OS versión 12.2, VRRP (IPv6) siguió el borrador de Internet draft-ietf-vrrp-ipv6-spec-08, pero la suma de comprobación se calculó con base en la sección 5.3.8 del RFC 3768. A partir de la versión 12.2, VRRP (IPv6) sigue el RFC 5798 y la suma de comprobación se calcula con base en la sección 5.2.8 del RFC 5798. Debido a las diferencias en los cálculos de suma de comprobación de VRRP, IPv6 VRRP configurado en enrutadores que utilizan Junos OS versión 12.2 y versiones posteriores no interopera con IPv6 VRRP configurado en versiones anteriores a Junos OS versión 12.2.
Para hacer que el enrutador con Junos OS versión 12.2 (o versiones posteriores de Junos OS) VRRP IPv6 interopere con el enrutador que ejecuta versiones de Junos OS anteriores a la versión 12.2, incluya la checksum-without-pseudoheader instrucción de configuración en el nivel de [edit protocols vrrp] jerarquía en el enrutador con Junos OS versión 12.2 o posterior.
Estos son algunos puntos generales que debe conocer sobre la interoperabilidad de VRRP:
Si configuró VRRPv3 (IPv4 o IPv6) en enrutadores que utilizan Junos OS versión 12.2 o versiones posteriores, no funcionará con enrutadores que utilicen Junos OS versión 12.1 o versiones anteriores. Esto se debe a que solo la versión 12.2 y posteriores de Junos OS admiten VRRPv3.
VRRP (IPv4 o IPv6) configurado en enrutadores que utilizan Junos OS versión 12.2 y versiones posteriores interoperan con VRRP (IPv4 o IPv6) configurado en enrutadores que utilizan versiones anteriores a Junos OS versión 12.2.
VRRPv3 para IPv4 no interopera con las versiones anteriores de VRRP. Si un enrutador en el que VRRPv3 está habilitado recibe paquetes de anuncio IPv4 VRRPv2, el enrutador pasa al estado de copia de seguridad para evitar la creación de varios principales en la red. Debido a este comportamiento, debe tener cuidado al habilitar VRRPv3 en sus redes VRRPv2 existentes. Consulte Actualizar de VRRPv2 a VRRPv3 para obtener más información.
Nota:Los paquetes de anuncio VRRPv3 son ignorados por los enrutadores en los que están configuradas las versiones anteriores de VRRP.
Actualizar de VRRPv2 a VRRPv3
Habilite VRRPv3 en su red solo si VRRPv3 se puede habilitar en todos los enrutadores VRRP de su red.
Habilite VRRPv3 en su red VRRPv2 solo cuando actualice de VRRPv2 a VRRPv3. Mezclar las dos versiones de VRRP no es una solución permanente.
El cambio de versión de VRRP se considera catastrófico y disruptivo y puede que no esté exento de impactos. La duración de la pérdida de paquetes depende de muchos factores, como la cantidad de grupos VRRP, las interfaces y FPC involucradas, y la carga de otros servicios y protocolos que se ejecutan en el enrutador.
La actualización de VRRPv2 a VRRPv3 debe hacerse con mucho cuidado para evitar pérdidas de tráfico, debido a estas consideraciones:
No es posible configurar VRRPv3 en todos los enrutadores simultáneamente.
Durante el período de transición, tanto VRRPv2 como VRRPv3 funcionan en la red.
Al cambiar las versiones de VRRP, se reinicia la máquina de estado para todos los grupos VRRP.
Los enrutadores VRRPv3 (para IPv4) tienen de forma predeterminada el estado de copia de seguridad cuando obtienen paquetes de anuncio VRRPv2 (para IPv4).
Los paquetes VRRPv2 (para IPv4) siempre tienen la máxima prioridad.
Las diferencias de suma de comprobación entre VRRPv2 y VRRPv3 (para IPv6) pueden crear varios enrutadores principales.
Desactive VRRPv3 (para IPv6) en los enrutadores de respaldo durante la actualización para evitar la creación de varios enrutadores principales.
La tabla 1 ilustra los pasos y eventos que tienen lugar durante una transición de VRRPv2 a VRRPv3. En la tabla 1, dos enrutadores VRRPv2, R1 y R2, están configurados en dos grupos, G1 y G2. El enrutador R1 actúa como principal para G1 y el enrutador R2 actúa como principal para G2.
|
|
For IPv4 |
For IPv6 |
|
|
Cuando habilite VRRPv3, asegúrese de que VRRPv3 esté habilitado en todos los enrutadores VRRP de la red, ya que VRRPv3 (IPv4) no interopera con las versiones anteriores de VRRP. Por ejemplo, si un enrutador en el que VRRPv3 está habilitado recibe paquetes de anuncio IPv4 VRRPv2, el enrutador pasa al estado de copia de seguridad para evitar la creación de varios principales en la red.
Puede habilitar VRRPv3 configurando la version-3 instrucción en el nivel de [edit protocols vrrp] jerarquía (para redes IPv4 o IPv6). Configure la misma versión de protocolo en todos los enrutadores VRRP de la LAN.
Funcionalidad de las características de VRRPv3
Algunas funciones de Junos OS difieren en VRRPv3 de versiones anteriores de VRRP.
Autenticación VRRPv3
Cuando VRRPv3 (para IPv4) está habilitado, no permite la autenticación.
Las
authentication-typeinstrucciones andauthentication-keyno se pueden configurar para ningún grupo VRRP.Debe usar autenticación que no sea VRRP.
Intervalos de anuncio VRRPv3
Los intervalos de anuncio VRRPv3 (para IPv4 e IPv6) deben establecerse con la fast-interval instrucción en el nivel jerárquico [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] .
No utilice la
advertise-intervalinstrucción (para IPv4).No utilice la
inet6-advertise-intervalinstrucción (para IPv6).
ISSU unificado para VRRPv3
Los cambios de diseño para la actualización de software en servicio (ISSU) unificada VRRP se realizan en la versión 15.1 de Junos OS para lograr la siguiente funcionalidad:
Mantenga la adyacencia del protocolo con enrutadores pares durante la ISSU unificada. La adyacencia de protocolo creada en enrutadores par para el enrutador sometido a ISSU unificado no debe oscilar, lo que significa que VRRP en el enrutador par remoto no debe oscilar.
Mantener la interoperabilidad con equipos competitivos o complementarios.
Mantenga la interoperabilidad con otras versiones de Junos OS y otros productos de red de Juniper.
Los valores de las siguientes configuraciones (que se encuentran en el [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] nivel de jerarquía) deben mantenerse en valores máximos para admitir una ISSU unificada:
En el enrutador principal, el intervalo de anuncio (la
fast-intervalinstrucción) debe mantenerse en 40950 milisegundos.En el enrutador de copia de seguridad, el intervalo primario hacia abajo (la
advertisements-thresholdinstrucción) debe mantenerse en el valor de umbral más grande.
Este diseño ISSU unificado de VRRP solo funciona para VRRPv3. No se admite en VRRPv1 ni VRRPv2. Otras limitaciones incluyen las siguientes:
La ISSU unificada de VRRP solo se ocupa de VRRP. El reenvío de paquetes es responsabilidad del motor de reenvío de paquetes. El motor de reenvío de paquetes ISSU unificado debe garantizar un flujo de tráfico ininterrumpido.
VRRP no se ve afectado por ningún evento de cambio durante la ISSU unificada, por ejemplo, el cambio del motor de enrutamiento principal a respaldo o el motor de enrutamiento de respaldo a principal.
VRRP puede detener y descartar cualquier temporizador en ejecución antes de entrar en ISSU unificado. Esto significa que la acción esperada al expirar el temporizador nunca se lleva a cabo. Sin embargo, puede aplazar la ISSU unificada hasta que expiren todos los temporizadores en ejecución.
La ISSU unificada en enrutadores locales y remotos no se puede hacer simultáneamente.
Descripción general de la tolerancia a fallos-retraso de VRRP
La conmutación por error es un modo operativo de copia de seguridad en el que un dispositivo secundario asume las funciones de un dispositivo de red cuando el dispositivo principal deja de estar disponible debido a un fallo o a un tiempo de inactividad programado. La conmutación por error suele ser una parte integral de los sistemas de misión crítica que deben estar constantemente disponibles en la red.
VRRP no admite la sincronización de sesiones entre miembros. Si se produce un error en el dispositivo principal, el dispositivo de copia de seguridad con la prioridad más alta toma el control como principal y comenzará a reenviar paquetes. Cualquier sesión existente se descartará en el dispositivo de copia de seguridad como fuera de estado.
Una tolerancia a fallos rápida requiere un breve retraso. Por lo tanto, el retraso de tolerancia a fallos configura el tiempo de retraso de tolerancia a fallos, en milisegundos, para VRRP y VRRP para operaciones IPv6. Junos OS admite un rango de 50 a 100000 milisegundos para retraso en el tiempo de tolerancia a fallos.
El proceso VRRP (vrrpd) que se ejecuta en el motor de enrutamiento comunica un cambio de rol principal de VRRP al motor de reenvío de paquetes para cada sesión de VRRP. Cada grupo VRRP puede activar dicha comunicación para actualizar el motor de reenvío de paquetes con su propio estado o el estado heredado de un grupo VRRP activo. Para evitar sobrecargar el motor de reenvío de paquetes con dichos mensajes, puede configurar un retraso de tolerancia a fallos para especificar el retraso entre las comunicaciones posteriores del motor de enrutamiento al motor de reenvío de paquetes.
El motor de enrutamiento comunica un cambio de rol principal VRRP al motor de reenvío de paquetes para facilitar el cambio de estado necesario en el motor de reenvío de paquetes, como la reprogramación de filtros de hardware del motor de reenvío de paquetes, sesiones VRRP, etc. En las siguientes secciones, se detalla la comunicación entre el motor de enrutamiento y el motor de reenvío de paquetes en dos escenarios:
- Cuando la tolerancia a fallos-delay no está configurada
- Cuando se configura la tolerancia a fallos-delay
Cuando la tolerancia a fallos-delay no está configurada
Sin la tolerancia a fallos-delay configurada, la secuencia de eventos para las sesiones de VRRP operadas desde el motor de enrutamiento es la siguiente:
Cuando el primer grupo VRRP detectado por el motor de enrutamiento cambia de estado y el nuevo estado es primario, el motor de enrutamiento genera mensajes de anuncio VRRP adecuados. Se informa al motor de reenvío de paquetes sobre el cambio de estado, de modo que los filtros de hardware para ese grupo se reprograman sin demora. Luego, el nuevo principal envía un mensaje ARP gratuito a los grupos VRRP.
Se inicia el retraso en el temporizador de tolerancia a fallos. De forma predeterminada, el temporizador de tolerancia a fallos-retraso es:
500 milisegundos: cuando el intervalo de anuncio VRRP configurado es inferior a 1 segundo.
2 segundos: cuando el intervalo de anuncio VRRP configurado es de 1 segundo o más y el número total de grupos VRRP en el enrutador es 255.
10 segundos: cuando el intervalo de anuncio de VRRP configurado es de 1 segundo o más y el número de grupos de VRRP en el enrutador es superior a 255.
El motor de enrutamiento realiza cambios de estado uno por uno para los grupos VRRP subsiguientes. Cada vez que hay un cambio de estado y el nuevo estado de un grupo VRRP determinado es principal, el motor de enrutamiento genera mensajes de anuncio VRRP adecuados. Sin embargo, la comunicación con el motor de reenvío de paquetes se suprime hasta que caduca el temporizador de retraso de tolerancia a fallos.
Después de que caduca el temporizador de tolerancia a fallos-retraso, el motor de enrutamiento envía un mensaje al motor de reenvío de paquetes sobre todos los grupos VRRP que lograron cambiar el estado. Como consecuencia, se reprograman los filtros de hardware para esos grupos y, para aquellos grupos cuyo nuevo estado es primario, se envían mensajes ARP gratuitos.
Este proceso se repite hasta que se completa la transición de estado para todos los grupos VRRP.
Por lo tanto, sin configurar la tolerancia a fallos-delay, la transición de estado completa (incluidos los estados en el motor de enrutamiento y el motor de reenvío de paquetes) para el primer grupo VRRP se realiza inmediatamente, mientras que la transición de estado en el motor de reenvío de paquetes para los grupos VRRP restantes se retrasa al menos 0,5-10 segundos, según los temporizadores de anuncio VRRP configurados y la cantidad de grupos VRRP. Durante este estado intermedio, la recepción de tráfico para grupos VRRP para cambios de estado que aún no se completaron en el motor de reenvío de paquetes podría descartarse en el nivel del motor de reenvío de paquetes debido a una reconfiguración diferida de los filtros de hardware.
Cuando se configura la tolerancia a fallos-delay
Cuando se configura la tolerancia a fallos-delay, la secuencia de eventos para las sesiones de VRRP operadas desde el motor de enrutamiento se modifica de la siguiente manera:
El motor de enrutamiento detecta que algunos grupos VRRP requieren un cambio de estado.
La tolerancia a fallos-delay se inicia para el período configurado. El intervalo permitido de temporizador de tolerancia a fallos y retardo es de 50 a 100000 milisegundos.
El motor de enrutamiento realiza un cambio de estado uno por uno para los grupos VRRP. Cada vez que hay un cambio de estado y el nuevo estado de un grupo VRRP determinado es principal, el motor de enrutamiento genera mensajes de anuncio VRRP adecuados. Sin embargo, la comunicación con el motor de reenvío de paquetes se suprime hasta que caduca el temporizador de retraso de tolerancia a fallos.
Después de que caduca el temporizador de tolerancia a fallos-retraso, el motor de enrutamiento envía un mensaje al motor de reenvío de paquetes sobre todos los grupos VRRP que lograron cambiar el estado. Como consecuencia, se reprograman los filtros de hardware para esos grupos y, para aquellos grupos cuyo nuevo estado es primario, se envían mensajes ARP gratuitos.
Este proceso se repite hasta que se completa la transición de estado para todos los grupos VRRP.
Por lo tanto, cuando se configura la tolerancia a fallos-delay, se aplaza incluso el estado del motor de reenvío de paquetes para el primer grupo VRRP. Sin embargo, el operador de red tiene la ventaja de configurar un valor de tolerancia a fallos-retraso que mejor se adapte a las necesidades del despliegue de red para garantizar una interrupción mínima durante el cambio de estado de VRRP.
La tolerancia a fallos-delay solo afecta a las sesiones de VRRP operadas por el proceso VRRP (VRRPD) que se ejecuta en el motor de enrutamiento. Para las sesiones VRRP distribuidas al motor de reenvío de paquetes, la configuración de tolerancia a fallos-retraso no tiene ningún efecto.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.