Descripción del cambio de enrutamiento elegante

Conceptos de cambio de motor de enrutamiento elegante

La función de cambio de motor de enrutamiento (GRES) de Junos OS y Junos OS evolucionado permite que un dispositivo con motores de enrutamiento redundantes continúe reenviando paquetes incluso si falla un motor de enrutamiento. GRES conserva la información de la interfaz y del kernel, y el tráfico no se interrumpe. Sin embargo, GRES no conserva el plano de control.

Los dispositivos vecinos detectan que el dispositivo ha experimentado un reinicio y reaccionan al evento de la manera prescrita por las especificaciones de protocolo de enrutamiento individuales.

Para conservar el enrutamiento durante un cambio, GRES debe combinarse con:

• Extensiones de protocolo de reinicio elegantes

• Enrutamiento activo sin interrupciones (NSR)

Cualquier actualización del motor de enrutamiento principal se replica en el motor de enrutamiento de reserva tan pronto como se produce.

Nota:

Debido a sus requisitos de sincronización y lógica, el rendimiento de NSR/GRES está limitado por el motor de enrutamiento más lento del sistema.

El rol principal cambia al motor de enrutamiento de reserva si:

• El kernel principal del motor de enrutamiento deja de funcionar.

• El motor de enrutamiento principal experimenta un error de hardware.

• El administrador inicia un cambio manual.

Nota:

Para restaurar rápidamente o conservar la información de estado del protocolo de enrutamiento durante una conmutación, GRES debe combinarse con un reinicio correcto o un enrutamiento activo sin interrupciones, respectivamente. Para obtener más información acerca del reinicio correcto, consulte Conceptos de reinicio correcto. Para obtener más información acerca del enrutamiento activo sin parada, consulte Conceptos de enrutamiento activo sin parada.

Si el motor de enrutamiento de reserva no recibe un keepalive del motor de enrutamiento principal después de 2 segundos, determina que el motor de enrutamiento principal ha fallado; y asume la función principal.

El motor de reenvío de paquetes:

• Se desconecta sin problemas del antiguo motor de enrutamiento primario

• Se vuelve a conectar al nuevo motor de enrutamiento principal

• No se reinicia

• No interrumpe el tráfico

A continuación, se sincronizan el nuevo motor de enrutamiento principal y el motor de reenvío de paquetes. Si el nuevo motor de enrutamiento principal detecta que el estado del motor de reenvío de paquetes no está actualizado, reenvía los mensajes de actualización de estado.

Tenga en cuenta los siguientes comportamientos, recomendaciones o requisitos de GRES:

• A partir de Junos OS versión 12.2, si se agotan las adyacencias entre el dispositivo de reinicio y los dispositivos "auxiliares" pares vecinos, las extensiones de protocolo de reinicio correcto no podrán notificar a los dispositivos "auxiliares" del mismo nivel sobre el reinicio inminente. Un reinicio agraciado puede detenerse y provocar interrupciones en el tráfico.

  Para asegurarse de que se mantienen estas adyacencias, cambie el hold-time valor predeterminado de 27 segundos a un valor superior a 40 segundos.

• Los eventos sucesivos de cambio de motor de enrutamiento deben estar separados por un mínimo de 240 segundos (4 minutos) después de que se hayan instalado ambos motores de enrutamiento.

  Si el dispositivo muestra un mensaje de advertencia similar a:

  entonces no intente un cambio. Si elige continuar con la conmutación, el dispositivo restablece solo los motores de reenvío de paquetes que no estaban listos para una conmutación elegante. Ninguno de los FPC debe reiniciarse espontáneamente. Le recomendamos que espere hasta que la advertencia ya no aparezca y, a continuación, continúe con el cambio.

• No recomendamos:

  • Realizar una operación de confirmación en el motor de enrutamiento de reserva cuando GRES está habilitado en el dispositivo.

  • Habilitación de GRES en el motor de enrutamiento de respaldo en cualquier escenario.

La figura 1 muestra la arquitectura del sistema de un cambio elegante del motor de enrutamiento y el proceso que sigue una plataforma de enrutamiento para prepararse para un cambio.

Nota:

Compruebe la preparación de GRES ejecutando ambos:

• El request chassis routing-engine master switch check comando del motor de enrutamiento principal

• El show system switchover comando del motor de enrutamiento de reserva

El proceso de preparación del cambio para GRES es el siguiente:

1. Se inicia el motor de enrutamiento principal.

2. Se inician los procesos de la plataforma de enrutamiento (como el proceso del chasis [chasisd]).

3. El motor de reenvío de paquetes se inicia y se conecta al motor de enrutamiento principal.

4. Toda la información del estado se actualiza en el sistema.

5. Se inicia el motor de enrutamiento de respaldo.

6. El sistema determina si se ha habilitado GRES.

7. El proceso de sincronización del kernel (ksyncd) sincroniza el motor de enrutamiento de copia de seguridad con el motor de enrutamiento principal.

8. Después de que ksyncd complete la sincronización, se actualizarán toda la información de estado y la tabla de reenvío.

La figura 2 muestra los efectos de un cambio en la plataforma de enrutamiento (o conmutación).

Un proceso de cambio comprende los siguientes pasos:

1. Cuando se pierden keepalives del motor de enrutamiento principal, el sistema cambia correctamente al motor de enrutamiento de reserva.

2. El motor de reenvío de paquetes se conecta al motor de enrutamiento de reserva, que se convierte en el nuevo motor principal.

3. Se reinician los procesos de plataforma de enrutamiento que no forman parte de GRES (como el rpd de proceso de protocolo de enrutamiento).

4. La información de estado aprendida desde el punto de la conmutación se actualiza en el sistema.

5. Si se configuran, las extensiones de protocolo de reinicio correcto recopilan y restauran información de enrutamiento de dispositivos auxiliares pares vecinos.

Use el Explorador de características para confirmar la compatibilidad de la plataforma y el lanzamiento de características específicas.

Revise la sección Comportamiento GRES específico de la plataforma para obtener notas relacionadas con su plataforma.

Efectos de un cambio de motor de enrutamiento

En la Tabla 1 se describen los efectos de un cambio de motor de enrutamiento cuando se habilitan diferentes funciones:

• Sin funciones de alta disponibilidad

• Cambio agraciado del motor de enrutamiento

• Reinicio agraciado

• Enrutamiento activo sin interrupciones

Tabla 1: Efectos de un cambio de motor de enrutamiento

Característica	Beneficios	Consideraciones
Solo motores de enrutamiento dual (sin funciones habilitadas)	Cuando se completa el cambio al nuevo motor de enrutamiento principal, se produce la convergencia de enrutamiento y se reanuda el tráfico.	Todas las interfaces físicas se desconectan. Reinicie los motores de reenvío de paquetes. El motor de enrutamiento de copia de seguridad reinicia el proceso de protocolo de enrutamiento (rpd). El nuevo motor de enrutamiento principal detecta todo el hardware y las interfaces. El cambio tarda varios minutos. Todas las adyacencias del dispositivo son conscientes de los cambios físicos (alarmas de interfaz) y de enrutamiento (topología).
GRES habilitado	Durante el cambio, se conserva la información de la interfaz y del kernel. La conmutación es más rápida porque los motores de reenvío de paquetes no se reinician.	El nuevo motor de enrutamiento principal reinicia el proceso de protocolo de enrutamiento (rpd). Todo el hardware y las interfaces se adquieren mediante un proceso similar a un reinicio en caliente. Todas las adyacencias son conscientes del cambio de estado del dispositivo.
Habilitado para GRES y NSR	El tráfico no se interrumpe durante el cambio. Se conserva la información de la interfaz y del kernel.	Los protocolos no compatibles deben actualizarse utilizando los mecanismos de recuperación normales inherentes a cada protocolo.
GRES y reinicio elegante habilitados	El tráfico no se interrumpe durante el cambio. Se conserva la información de la interfaz y del kernel. Las extensiones de protocolo de reinicio elegante recopilan y restauran rápidamente la información de enrutamiento de los dispositivos vecinos.	Se requiere que los vecinos admitan un reinicio elegante y se requiere un intervalo de espera. Se reinicia el proceso de protocolo de enrutamiento (rpd). Para ciertos protocolos, un cambio significativo en la red puede hacer que se detenga un reinicio correcto. A partir de Junos OS versión 12.2, si se agotan las adyacencias entre el dispositivo de reinicio y los dispositivos "auxiliares" pares vecinos, el reinicio correcto puede detenerse y provocar interrupciones en el tráfico.

Cambio correcto del motor de enrutamiento en interfaces de servicios agregados

Si un comando de modo operativo desencadena un cambio correcto de motor de enrutamiento (GRES), el dispositivo no conserva el estado de las interfaces de servicios agregados (ASI). Por ejemplo:

Sin embargo, si GRES se activa por una confirmación de CLI o un reinicio o bloqueo de FPC, el motor de enrutamiento de respaldo actualiza el estado de ASI. Por ejemplo:

O:

Compatibilidad con una plataforma de cambio de motor de enrutamiento elegante

Para habilitar un cambio correcto de motor de enrutamiento, el sistema debe cumplir estos requisitos mínimos:

• Enrutador MX960: versión 8.3 o posterior de Junos OS

• Enrutador MX480: versión 8.4 o posterior de Junos OS (se recomienda 8.4R2)

• Enrutador MX240: versión 9.0 o posterior de Junos OS

• Enrutador PTX5000: Junos OS versión 12.1X48 o posterior

• Conmutadores serie EX con motores de enrutamiento duales o en un chasis virtual — Junos OS versión 9.2 o posterior para conmutadores serie EX

• Conmutadores de la serie QFX en un chasis virtual: versión 13.2 o posterior de Junos OS para la serie QFX

• Conmutadores serie EX o QFX en una estructura de chasis virtual: Junos OS versión 13.2X51-D20 o posterior para los conmutadores serie EX y QFX

Para obtener más información acerca de la compatibilidad con el cambio correcto de motor de enrutamiento, consulte las secciones siguientes.

Compatibilidad con la función Graceful Routing Engine Switchover

El cambio de motor de enrutamiento elegante es compatible con la mayoría de las funciones de Junos OS de la versión 5.7 y posteriores. Algunas características particulares de Junos OS requieren versiones específicas de Junos OS. Ver Tabla 2.

Tabla 2: Compatibilidad con la función Graceful Routing Engine Switchover

Aplicación	Versión de Junos OS
Interfaces Ethernet agregadas con protocolo de control de agregación de vínculos (LACP) e interfaces SONET agregadas	6.2
Modo de transferencia asíncrono (ATM) circuitos virtuales (VC)	6.2
Sistemas lógicos Nota: En Junos OS versión 9.3 y posteriores, la función de enrutador lógico cambia de nombre a sistema lógico.	6.3
Multidifusión	6.4 (7.0 para enrutador TX Matrix)
Protocolo punto a punto multivínculo (MLPPP) y relé de trama multivínculo (MLFR)	7.0
Conmutación automática de protección (APS): la interfaz activa actual (ya sea la interfaz de trabajo designada o la interfaz de protección designada) sigue siendo la interfaz activa durante un cambio de motor de enrutamiento.	7.4
Conmutación de etiquetas multiprotocolo punto a multipunto MPLS LSP (solo tránsito)	7.4
Protocolo de transporte comprimido en tiempo real (CRTP)	7.6
Servicio de LAN privada virtual (VPLS)	8.2
Operación, administración y gestión de Ethernet (OAM) según lo definido por IEEE 802.3ah	8.5
Agente de retransmisión DHCP extendido	8.5
OAM de Ethernet según lo definido por IEEE 802.1ag	9.0
Proceso del Protocolo de control de puerta de enlace de paquetes (PGCPD) en multiservicios 500 PIC en enrutadores T640.	9.0
Acceso de suscriptores	9.4
Configuración redundante de pseudocables VPLS basada en LDP y circuito de capa 2	9.6

Las siguientes restricciones se aplican a la compatibilidad con la característica de cambio de motor de enrutamiento:

• Cuando se configuran interfaces Ethernet agregadas y de conmutación de motor de enrutamiento en el mismo sistema, las interfaces Ethernet agregadas no deben configurarse para LACP de sondeo rápido. Cuando se configura el sondeo rápido, se agota el tiempo de espera de los sondeos LACP en el extremo remoto durante el cambio de rol principal del motor de enrutamiento. Cuando se agota el tiempo de espera del sondeo LACP, el vínculo agregado y la interfaz se deshabilitan. El cambio de rol principal del motor de enrutamiento es lo suficientemente rápido como para que el sondeo LACP lento y estándar no agote el tiempo de espera durante el procedimiento.

  Nota:

  Las sesiones de MACSec se agitarán al cambiar el motor de enrutamiento elegante.

  A partir de Junos OS versión 13.2, cuando se produce un cambio correcto de motor de enrutamiento, el estado VRRP no cambia. VRRP es compatible con un cambio de motor de enrutamiento elegante solo en el caso de que la delegación PPM esté habilitada (que es la predeterminada).

Cambio de motor de enrutamiento y acceso de suscriptores

Actualmente, el cambio de motor de enrutamiento elegante admite la mayoría de las funciones directamente asociadas con el acceso dinámico de suscriptores DHCP y PPPoE dinámico. El cambio de motor de enrutamiento elegante también admite la actualización unificada de software en servicio (ISSU) para el modelo de acceso DHCP y el modelo de acceso PPPoE utilizado por el acceso de suscriptor.

Nota:

Cuando se habilita el cambio de motor de enrutamiento para la administración de suscriptores, todos los motores de enrutamiento del enrutador deben tener la misma cantidad de DRAM para un funcionamiento estable.

Compatibilidad con PIC de cambio de motor de enrutamiento agraciado

El cambio de motor de enrutamiento correcto se admite en la mayoría de las PIC, excepto en las PIC de servicios enumeradas en esta sección. El PIC debe estar en una plataforma de enrutamiento compatible que ejecute la versión adecuada de Junos OS. Para obtener información acerca de los tipos de FPC, la compatibilidad de FPC/PIC y la versión inicial de Junos OS en la que una FPC admitía una PIC determinada, consulte la guía de PIC de su plataforma de enrutador.

Las siguientes restricciones se aplican a la compatibilidad con un cambio de motor de enrutamiento correcto para PIC de servicios:

• Puede incluir la graceful-switchover instrucción en el nivel de [edit chassis redundancy] jerarquía en un enrutador con las PIC de servicios adaptativos, multiservicios y servicios de túnel configuradas en él, y confirmar correctamente la configuración. Sin embargo, todos los servicios de estas PIC, excepto los paquetes de servicios de capa 2 y las aplicaciones de SDK y proveedor de extensiones en PIC de multiservicios, se restablecen durante una conversión.

• El cambio correcto de motor de enrutamiento no se admite en ninguna PIC de servicios de supervisión ni PIC de servicios multivínculo. Si incluye la graceful-switchover instrucción en el [edit chassis redundancy] nivel de jerarquía en un enrutador con cualquiera de estos tipos de PIC configurados y emite el comando, se producirá un commit error en la confirmación.

• El cambio de motor de enrutamiento correcto no se admite en las PIC multiservicios 400 configuradas para aplicaciones de servicios de supervisión. Si incluye la instrucción, se producirá un graceful-switchover error en la confirmación.

Nota:

Cuando una PIC no compatible está en línea, no puede habilitar el cambio correcto del motor de enrutamiento. Si el cambio correcto de motor de enrutamiento ya está habilitado, no se puede conectar una PIC no compatible.

Use el Explorador de características para confirmar la compatibilidad de la plataforma y el lanzamiento de características específicas.

Use la tabla siguiente para revisar los comportamientos específicos de la plataforma para su plataforma:

Diferencia de	plataforma
Serie MX	Cuando realice GRES en enrutadores de la serie MX, debe ejecutar el comando de clear synchronous-ethernet wait-to-restore modo operativo en el nuevo motor de enrutamiento principal para borrar el temporizador de espera para restaurar que contiene. Esto se debe a que el comando del clear synchronous-ethernet wait-to-restore modo operativo borra el temporizador de espera para restaurar solo en el motor de enrutamiento local. En el caso de los enrutadores de la serie MX que utilizan una administración de suscriptores mejorada, el nuevo motor de enrutamiento de reserva (el antiguo motor de enrutamiento principal) se reiniciará cuando se realice un cambio correcto del motor de enrutamiento. Este reinicio en frío vuelve a sincronizar el estado del motor de enrutamiento de reserva con el del nuevo motor de enrutamiento principal, evitando discrepancias de estado que podrían haberse producido durante el cambio. Los enrutadores de la serie MX que tienen habilitada la administración periódica de paquetes distribuidos (PPM) pueden configurar un cambio de motor de enrutamiento correcto y tener interfaces Ethernet agregadas configuradas para LACP de sondeo rápido en el mismo dispositivo. El cambio de motor de enrutamiento correcto admite todos los concentradores de puerto denso (DPC) en las plataformas de enrutamiento universal 5G de la serie MX que ejecutan la versión adecuada de Junos OS, como se muestra en Comportamiento GRES específico de la plataforma.
Serie PTX	En los dispositivos PTX10004, PTX10008 y PTX10016 que ejecutan Junos OS Evolved, GRES está habilitado de forma predeterminada y no se puede deshabilitar.
Serie QFX	Cuando habilite el enrutamiento sin interrupción con GRES en conmutadores de la línea QFX10000 que tengan motores de enrutamiento redundantes, se recomienda encarecidamente que configure la nsr-phantom-holdtime seconds instrucción en el nivel de [edit routing-options] jerarquía. Hacerlo ayuda a evitar la pérdida de tráfico durante un cambio. Si configura esta instrucción, las direcciones IP fantasma permanecen en el núcleo durante el cambio hasta que expire el intervalo de tiempo de espera especificado. Una vez expirado el intervalo, el dispositivo agrega las rutas correspondientes a las tablas de enrutamiento adecuadas. En un entorno de VPN ETHERNET-VXLAN, se recomienda especificar un valor de tiempo de espera de 300 segundos (5 minutos). Esta opción no se aplica a los conmutadores QFX10002, que no tienen motores de enrutamiento redundantes y no admiten GRES.