Descripción de VRRP
RESUMEN El Protocolo de redundancia de enrutador virtual (VRRP) se puede utilizar para crear plataformas de enrutamiento redundantes virtuales en una LAN, lo que permite enrutar el tráfico en la LAN sin depender 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 sola 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 reserva se convierte en la nueva plataforma de enrutamiento principal, lo que proporciona una plataforma de enrutamiento virtual predeterminada y permite enrutar el tráfico en la LAN sin depender de una única plataforma de enrutamiento. Con VRRP, un dispositivo de copia de seguridad puede hacerse cargo de un dispositivo predeterminado fallido 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 dispositivos primarios y de respaldo. También puede forzar la asignación de dispositivos principales y de copia de seguridad con prioridades del 1 al 255, siendo 255 la prioridad más alta. En la operación VRRP, el dispositivo primario 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 asume el control como principal y comienza a reenviar paquetes.
No se puede establecer la prioridad 255 para las 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 de VRRP en un momento dado. Los dispositivos de copia de seguridad no envían ningún anuncio hasta que asuman el papel principal.
VRRP para IPv6 proporciona un cambio mucho más rápido a un enrutador predeterminado alternativo que los procedimientos de descubrimiento de vecinos IPv6. Las implementaciones típicas usan solo un enrutador de respaldo.
No confunda las plataformas de enrutamiento primario y de respaldo VRRP con los conmutadores miembro principal y de respaldo de una configuración de Virtual Chassis . Los miembros principal y de respaldo de una configuración de Virtual Chassis componen un único host. En una topología VRRP, un host opera como la plataforma de enrutamiento principal y otro opera como la plataforma de enrutamiento de reserva, 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 de Junos OS admite la autenticación tal 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 Hello de 2 segundos o más con un intervalo muerto no inferior a 6 segundos para evitar fallas durante eventos de operaciones intensivas de CPU, como cambio de motor de enrutamiento, solapas 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
Debido a 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 LAN. Cuando el enrutador A se recupera, vuelve a convertirse en el enrutador virtual principal.
En algunos casos, durante una sesión heredada, hay un pequeño período de tiempo durante el cual dos enrutadores están en estado primario-primario. 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 de copia de seguridad primaria desde el estado primario-primario.
Los enrutadores de la serie ACX admiten hasta 64 entradas de grupo VRRP. Estos pueden ser una combinación de familias IPv4 o IPv6. Si cualquiera de las familias (IPv4 o IPv6) está configurada ú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 VRRP versión 3 para direcciones IPv6.
ACX5448 enrutador admite RFC 3768 VRRP versión 2 y RFC 5798 VRRP versión 3. ACX5448 enrutador también admite la configuración de VRRP a través de Ethernet agregada e interfaces de enrutamiento y puente integrados (IRB).
Las siguientes limitaciones se aplican al configurar VRRP en ACX5448 enrutador:
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 delegados 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 Virtual Chassis. Los conmutadores A, B y C están compuestos por múltiples conmutadores Ethernet EX4200 de Juniper Networks interconectados. Cada configuración de Virtual Chassis 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
Debido a que la plataforma de enrutamiento virtual utiliza la dirección IP de la interfaz física del conmutador A, el conmutador A es la plataforma de enrutamiento VRRP principal, mientras que el conmutador B y el conmutador C funcionan como plataformas de enrutamiento VRRP de reserva. Los clientes del 1 al 3 se configuran con la dirección IP predeterminada de la puerta de enlace, ya 10.10.0.1 que 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 ser la principal plataforma de enrutamiento virtual.
Ver también
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ápida
Cobre Ethernet de tres velocidades
Gigabit Ethernet
PIC de 10 Gigabit Ethernet LAN/WAN
Interfaces lógicas Ethernet
VRRP y VRRP para IPv6 permiten que los hosts en una LAN hagan uso de enrutadores redundantes en esa LAN sin requerir más que la configuración estática de una sola 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 otros son copias de seguridad. Si el primario falla, uno de los enrutadores de respaldo se convierte en el nuevo enrutador primario, proporcionando así siempre un enrutador predeterminado virtual y permitiendo que el tráfico en la LAN se enrute sin depender de un solo enrutador.
VRRP se define en RFC 3768, Protocolo de redundancia de enrutador virtual.
Para obtener información general sobre VRRP y VRRP para IPv6, directrices de configuración y resúmenes de instrucciones, consulte la Guía del usuario de alta disponibilidad de Junos OS.
Ver también
Descripción del VRRP entre sistemas QFabric
Los sistemas QFabric de Juniper Networks admiten el Protocolo de redundancia de enrutador virtual (VRRP). En este tema se trata:
Diferencias de VRRP en sistemas QFabric
La configuración de servidores en la red con rutas estáticas a una puerta de enlace predeterminada minimiza el esfuerzo y la complejidad de la configuración, y reduce la sobrecarga de procesamiento. Sin embargo, un error de la puerta de enlace predeterminada normalmente produce un evento catastrófico que aísla los servidores. El uso del Protocolo de redundancia de enrutador virtual (VRRP) permite proporcionar dinámicamente puertas de enlace alternativas para los servidores si se produce un error en la puerta de enlace principal.
Los conmutadores configurados con VRRP comparten una dirección IP virtual (VIP), que es la dirección que se configura como ruta predeterminada en los servidores. En el funcionamiento normal de VRRP, uno de los conmutadores es el VRRP primario, lo que significa que posee la VIP y es la puerta de enlace predeterminada activa. Los otros dispositivos son copias de seguridad. Los conmutadores asignan dinámicamente roles principales y de respaldo en función de las prioridades que configure. Si se produce un error en el primario, el conmutador de copia de seguridad con la prioridad más alta se convierte en el principal y se hace cargo de la VIP en pocos segundos. Esto se hace sin ninguna interacción con los servidores.
Puede configurar dos sistemas QFabric para que participen en una configuración VRRP como si fueran dos conmutadores independientes. Sin embargo, en la operación normal de VRRP, solo un sistema puede ser el principal para un grupo VRRP determinado a la vez, lo que significa que solo un sistema puede actuar como puerta de enlace predeterminada utilizando la VIP configurada para el grupo. Cuando se ejecuta VRRP en dos sistemas QFabric, es posible que desee que ambos sistemas utilicen simultáneamente la VIP para actuar como puerta de enlace y reenviar tráfico. Para lograr esto, puede configurar un filtro de firewall para bloquear los paquetes de anuncio VRRP entre los sistemas QFabric en el vínculo entre los dos grupos de nodos de red. Al hacerlo, ambos sistemas QFabric actúan como tráfico primario y de reenvío recibido por la VIP (que es la dirección de puerta de enlace predeterminada que se configura en los servidores conectados a ambos sistemas QFabric). Si utiliza vMotion de VMware, esta configuración permite que las máquinas virtuales realicen la transición entre servidores conectados a los sistemas QFabric sin actualizar su información de puerta de enlace predeterminada. Por ejemplo, una máquina virtual que se ejecuta en un servidor conectado a un sistema QFabric en el centro de datos A puede realizar la transición a un servidor conectado a un sistema QFabric en el centro de datos B sin necesidad de resolver una nueva dirección IP y dirección MAC de puerta de enlace porque ambos sistemas QFabric utilizan el mismo VIP.
Para usar un filtro de firewall para bloquear el tráfico VRRP, cree un término de firewall que coincida con el tráfico y protocol vrrp lo descarte.
Detalles de configuración
La configuración de un grupo VRRP en dos sistemas QFabric es similar a la configuración de VRRP en dos conmutadores. Las principales diferencias se enumeran aquí:
Todas las interfaces en ambos sistemas QFabric que participan en VRRP deben ser miembros de la misma VLAN.
Debe crear interfaces VLAN enrutadas (RVI) en esa VLAN en ambos sistemas QFabric.
Las direcciones IP que asigne a ambas RVI deben estar en la misma subred.
Debe configurar VRRP en las RVI.
Ambos RVI deben ser miembros del mismo grupo VRRP. Esto es lo que permite a los dos sistemas QFabric compartir una dirección IP virtual.
En las tablas siguientes se enumeran los elementos de un ejemplo de configuración VRRP que se ejecuta en dos sistemas QFabric: el sistema QFabric A y el sistema QFabric B. Este ejemplo está configurado para que ambos sistemas QFabric actúen como el VRRP principal para VIP 10.1.1.50/24 y supone que un filtro de firewall bloquea los anuncios VRRP entre los sistemas. En la tabla 1 se enumeran las características necesarias de las RVI en la configuración de ejemplo.
La mayoría de las opciones de configuración de las tablas siguientes también se aplicarían en una configuración VRRP tradicional. Sin embargo, el intervalo de anuncio y la configuración de prioridad tendrían que ser diferentes (como se señaló).
| RVI en el sistema QFabric A | RVI en el sistema QFabric B |
VLAN.100 |
vlan.200 |
Miembro de VLAN 100. (Tenga en cuenta que la VLAN es la misma en ambos sistemas QFabric). |
Miembro de VLAN 100 |
Dirección IP 10.1.1.100/24 |
Dirección IP 10.1.1.200/24 |
Miembro del grupo VRRP 500 |
Miembro del grupo VRRP 500 |
Dirección IP virtual 10.1.1.50/24 |
Dirección IP virtual 10.1.1.50/24 |
Debe configurar VRRP en las RVI de ambos sistemas QFabric. La Tabla 2 enumera los elementos de una configuración VRRP de ejemplo en cada RVI. Tenga en cuenta que, con la excepción de la prioridad, los parámetros deben ser los mismos en ambos sistemas.
| VRRP en RVI en QFabric System A | VRRP en RVI en QFabric System B |
Grupo VRRP 500 |
Grupo VRRP 500 |
Dirección IP virtual 10.1.1.50/24 |
Dirección IP virtual 10.1.1.50/24 |
Intervalo de publicidad 60 segundos. (En una configuración VRRP normal, establecería este intervalo para que sea mucho menor, como 1 segundo. Sin embargo, en esta configuración, estos paquetes están bloqueados por el filtro de firewall en la interfaz que se conecta al sistema QFabric B, por lo que no es necesario enviarlos con frecuencia). |
Intervalo de anuncio 60 segundos |
Tipo de autenticación md5 |
Tipo de autenticación md5 |
Clave de autenticación $9$1.4ElMVb2aGi4aZjkqzFRhSeWx7-wY2aM8 |
Clave de autenticación $9$1.4ElMVb2aGi4aZjkqzFRhSeWx7-wY2aM8 |
Prioridad 254. (En una configuración VRRP normal, este valor sería diferente en los dos sistemas y el sistema con el valor más alto sería el principal. Sin embargo, en esta configuración ambos sistemas actúan como primarios, por lo que no es necesario configurar valores diferentes). |
Prioridad 254 |
La prioridad 255 no se admite para las RVI.
La Tabla 3 enumera todas las interfaces del sistema QFabric A en la configuración de ejemplo e identifica a qué se conectan.
| Interfaces VLAN 100 en el sistema QFabric A | Se conecta a |
VLAN.100 |
vlan.200 |
Interfaz de grupo de nodos de red QFA-NNG:xe-0/0/0 |
QFB-NNG:xe-0/0/0 en el sistema QFabric B |
Interfaz de grupo de nodos de red QFA-NNG:xe-0/0/1 |
Interfaz de grupo de nodos de servidor redundante QFA-RSNG:xe-0/0/0 |
Interfaz de grupo de nodos de servidor redundante QFA-RSNG:xe-0/0/0 |
Se conecta a una interfaz de grupo de nodos de red QFA-NNG:xe-0/0/1 |
Interfaz de grupo de nodos de servidor redundante QFA-RSNG:xe-0/0/1 |
LAN con servidores que ejecutan máquinas virtuales |
La Tabla 4 enumera todas las interfaces en el sistema QFabric B en la configuración de ejemplo e identifica a qué se conectan.
| Interfaces VLAN 100 en el sistema QFabric B | Se conecta a |
vlan.200 |
VLAN.100 |
Interfaz de grupo de nodos de red QFB-NNG:xe-0/0/0 |
QFA-NNG:xe-0/0/0 en el sistema QFabric A |
Interfaz de grupo de nodos de red QFB-NNG:xe-0/0/1 |
Interfaz de grupo de nodos de servidor redundante QFB-RSNG:xe-0/0/0 |
Interfaz de grupo de nodos de servidor redundante QFB-RSNG:xe-0/0/0 |
Se conecta a una interfaz de grupo de nodos de red QFB-NNG:xe-0/0/1 |
Interfaz de grupo de nodos de servidor redundante QFB-RSNG:xe-0/0/1 |
LAN con servidores que ejecutan máquinas virtuales |
Ver también
Compatibilidad de Junos OS con 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 describe la compatibilidad e interoperabilidad de Junos OS con VRRPv3, así como algunas diferencias entre VRRPv3 y sus precursores:
- Soporte de Junos OS VRRP
- Diferencias de comportamiento en la suma de comprobación VRRP IPv6
- Interoperabilidad de VRRP
- Actualización de VRRPv2 a VRRPv3
- Funcionalidad de las características de VRRPv3
Soporte de Junos OS VRRP
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 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 es compatible con IPv6 en conmutadores QFX10000.
VRRPv3 para IPv6 es compatible con QFX10002-60C.
A partir de la versión 12.2, Junos OS admite:
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 usan Junos OS versión 12.2 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 VRRP. Consulte Diferencias de comportamiento en la suma de comprobación VRRP IPv6.
Diferencias de comportamiento en 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 VRRP se calcula según 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 de 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 VRRP IPv6. El pseudoencabezado no se incluye al calcular la suma de comprobación VRRP IPv4.
Para que el enrutador con Junos OS versión 12.2 (o versiones posteriores de Junos OS) IPv6 VRRP interopere con el enrutador que ejecuta una versión de Junos OS anterior a la versión 12.2, incluya la instrucción de configuración en el nivel de
checksum-without-pseudoheaderjerarquía en el[edit protocols vrrp]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 del 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 Junos OS versión 12.2), 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 omitir este mensaje porque no indica un error 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ó según RFC 3768 sección 5.3.8. A partir de la versión 12.2, VRRP (IPv6) sigue la RFC 5798 y la suma de comprobación se calcula según la sección 5.2.8 de la RFC 5798. Debido a las diferencias en los cálculos de suma de comprobación de VRRP, VRRP IPv6 configurado en enrutadores que utilizan Junos OS versión 12.2 y versiones posteriores no interopera con VRRP IPv6 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) IPv6 VRRP interopere con el enrutador que ejecuta versiones de Junos OS anteriores a la versión 12.2, incluya la instrucción de configuración en el nivel de checksum-without-pseudoheader jerarquía en el [edit protocols vrrp] enrutador con Junos OS versión 12.2 o posterior.
Aquí hay algunos puntos generales que debe saber sobre la interoperabilidad de VRRP:
Si ha configurado VRRPv3 (IPv4 o IPv6) en enrutadores que utilizan Junos OS versión 12.2 o versiones posteriores, no funcionará con enrutadores que utilizan Junos OS versión 12.1 o versiones anteriores. Esto se debe a que solo Junos OS versión 12.2 y versiones posteriores 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 está habilitado VRRPv3 recibe paquetes de anuncio IPv4 VRRPv2, el enrutador pasa al estado de copia de seguridad para evitar la creación de varias primarias en la red. Debido a este comportamiento, debe tener cuidado al habilitar VRRPv3 en sus redes VRRPv2 existentes. Consulte Actualización de VRRPv2 a VRRPv3 para obtener más información.
Nota:Los paquetes de anuncios VRRPv3 son ignorados por los enrutadores en los que se configuraron las versiones anteriores de VRRP.
Actualización 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 no ser un éxito. La duración de la pérdida de paquetes depende de muchos factores, como el número 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 la pérdida 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 operan en la red.
Al cambiar las versiones de VRRP, se reinicia la máquina de estado para todos los grupos de VRRP.
Los enrutadores VRRPv3 (para IPv4) utilizan de forma predeterminada el estado de respaldo cuando reciben 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 crear varios enrutadores principales.
La Tabla 5 ilustra los pasos y eventos que tienen lugar durante una transición de VRRPv2 a VRRPv3. En la Tabla 5, dos enrutadores VRRPv2, R1 y R2, se configuran en dos grupos, G1 y G2. El enrutador R1 actúa como el principal para G1 y el enrutador R2 actúa como el 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 está habilitado VRRPv3 recibe paquetes de anuncio IPv4 VRRPv2, el enrutador pasa al estado de copia de seguridad para evitar la creación de varias primarias 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 características 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 yauthentication-keyno se pueden configurar para ningún grupo VRRP.Debe usar autenticación que no sea VRRP.
Intervalos de publicidad VRRPv3
Los intervalos de anuncio VRRPv3 (para IPv4 e IPv6) deben establecerse con la fast-interval instrucción en el nivel de [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] jerarquía.
No utilice la
advertise-intervalinstrucción (para IPv4).No utilice la
inet6-advertise-intervalinstrucción (para IPv6).
ISSU unificada para VRRPv3
Los cambios de diseño para la actualización unificada de software en servicio (ISSU) de VRRP se realizan en Junos OS versión 15.1 para lograr la siguiente funcionalidad:
Mantenga la adyacencia del protocolo con enrutadores pares durante la ISSU unificada. La adyacencia de protocolo creada en enrutadores pares para el enrutador sometido a ISSU unificada 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 Juniper Network.
Los valores de las siguientes configuraciones (que se encuentran en el nivel de jerarquía) deben mantenerse en los valores máximos para admitir ISSU [edit interfaces interface-name unit 0 family inet address ip-address vrrp-group group-name] unificada:
En el enrutador principal, el intervalo de anuncio (la
fast-intervalinstrucción) debe mantenerse en 40950 milisegundos.En el enrutador de reserva, el intervalo de caída primario (la
advertisements-thresholdinstrucción) debe mantenerse en el valor de umbral más alto.
Este diseño de ISSU unificado de VRRP solo funciona para VRRPv3. No es compatible con VRRPv1 ni VRRPv2. Otras limitaciones incluyen las siguientes:
La ISSU unificada de VRRP solo se encarga del VRRP. El reenvío de paquetes es responsabilidad del motor de reenvío de paquetes. La ISSU unificada del motor de reenvío de paquetes 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 copia de seguridad o el motor de enrutamiento de copia de seguridad a principal.
VRRP puede detener y descartar cualquier temporizador de ejecución antes de entrar en ISSU unificada. Esto significa que la acción esperada al expirar el temporizador nunca tiene lugar. Sin embargo, puede aplazar la ISSU unificada hasta la expiración de todos los temporizadores de ejecución.
La ISSU unificada en enrutadores locales y remotos no se puede realizar simultáneamente.
Ver también
Descripción general de la demora por conmutación por error 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 error 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 se convierte en principal y comenzará a reenviar paquetes. Cualquier sesión existente se eliminará en el dispositivo de copia de seguridad como fuera de estado.
Una conmutación por error rápida requiere un breve retraso. Por lo tanto, el retraso de conmutación por error configura el tiempo de retraso de conmutación por error, en milisegundos, para VRRP y VRRP para operaciones IPv6. Junos OS admite un intervalo de 50 a 100000 milisegundos para retrasos en el tiempo de conmutación por error.
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 tales mensajes, puede configurar un retraso de conmutación por error 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 de 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 secciones siguientes se detalla la comunicación del motor de enrutamiento al motor de reenvío de paquetes en dos escenarios:
- Cuando la demora por conmutación por error no está configurada
- Cuando se configura la interrupción de la conmutación por error
Cuando la demora por conmutación por error no está configurada
Sin retraso de conmutación por error configurado, la secuencia de eventos para las sesiones 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 principal, el motor de enrutamiento genera los mensajes de anuncio de 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, la nueva primaria envía un mensaje ARP gratuito a los grupos VRRP.
Se inicia el retraso en el temporizador de conmutación por error. De forma predeterminada, el temporizador de retraso de conmutación por error es:
500 milisegundos: cuando el intervalo de anuncio de VRRP configurado es inferior a 1 segundo.
2 segundos: cuando el intervalo de anuncio de VRRP configurado es de 1 segundo o más y el número total de grupos de 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 un cambio de estado uno por uno para los grupos VRRP posteriores. Cada vez que hay un cambio de estado y el nuevo estado para 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 expire el temporizador de retraso de conmutación por error.
Después de que expira el temporizador de retraso de conmutación por error, el motor de enrutamiento envía un mensaje al motor de reenvío de paquetes acerca de todos los grupos VRRP que lograron cambiar el estado. Como consecuencia, los filtros de hardware para esos grupos se reprograman, y para aquellos grupos cuyo nuevo estado es primario, se envían mensajes ARP gratuitos.
Este proceso se repite hasta que se complete la transición de estado para todos los grupos VRRP.
Por lo tanto, sin configurar el retraso por conmutación por error, 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, dependiendo de los temporizadores de anuncio VRRP configurados y el número 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 perderse en el nivel del motor de reenvío de paquetes debido a la reconfiguración diferida de los filtros de hardware.
Cuando se configura la interrupción de la conmutación por error
Cuando se configura el retraso de conmutación por error, la secuencia de eventos para las sesiones 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.
El retraso de conmutación por error se inicia durante el período configurado. El intervalo permitido del temporizador de retardo de conmutación por error es de 50 a 100000 milisegundos.
El motor de enrutamiento realiza cambios de estado uno por uno para los grupos VRRP. Cada vez que hay un cambio de estado y el nuevo estado para 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 expire el temporizador de retraso de conmutación por error.
Después de que expira el temporizador de retraso de conmutación por error, el motor de enrutamiento envía un mensaje al motor de reenvío de paquetes acerca de todos los grupos VRRP que lograron cambiar el estado. Como consecuencia, los filtros de hardware para esos grupos se reprograman, y para aquellos grupos cuyo nuevo estado es primario, se envían mensajes ARP gratuitos.
Este proceso se repite hasta que se complete la transición de estado para todos los grupos VRRP.
Por lo tanto, cuando se configura el retraso de conmutación por error, incluso el estado del motor de reenvío de paquetes para el primer grupo VRRP se aplaza. Sin embargo, el operador de red tiene la ventaja de configurar un valor de retraso de conmutación por error que mejor se adapte a las necesidades de la implementación de red para garantizar una interrupción mínima durante el cambio de estado de VRRP.
El retraso de conmutación por error solo influye en 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 retraso de conmutación por error no tiene ningún efecto.
Ver también
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.