Descripción de la conmutación de enrutamiento elegante

Conceptos de conmutación de motor de enrutamiento elegante

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

En las plataformas PTX10004, PTX10008 y PTX10016 que ejecutan Junos OS Evolved, GRES está habilitado de forma predeterminada y no se puede deshabilitar.

Nota:

En enrutadores serie T, enrutadores de matriz de transmisión y enrutadores de transmisión Matrix Plus, el plano de control se conserva en el caso de GRES con enrutamiento activo (NSR) sin interrupciones, y casi el 75 % de la velocidad de línea del tráfico por motor de reenvío de paquetes permanece ininterrumpida durante GRES.

Los enrutadores vecinos detectan que el enrutador ha experimentado un reinicio y reaccionan ante el evento de la manera prescrita por las especificaciones del protocolo de enrutamiento individual.

Para conservar el enrutamiento durante una conmutación, GRES debe combinarse con:

• Extensiones de protocolo de reinicio agraciado

• Enrutamiento activo sin interrupciones (NSR)

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

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.

La función principal cambia al motor de enrutamiento de respaldo si:

• El núcleo del motor de enrutamiento principal deja de funcionar.

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

• El administrador inicia una conmutación manual.

Nota:

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

Si el motor de enrutamiento de respaldo no recibe un resguardo del motor de enrutamiento principal después de 2 segundos (4 segundos en enrutadores M20), determina que el motor de enrutamiento principal ha fallado; y asume el rol principal.

El motor de reenvío de paquetes:

• Se desconecta sin problemas del antiguo motor de enrutamiento principal

• Se vuelve a conectar con el nuevo motor de enrutamiento principal

• No se reinicia

• No interrumpe el tráfico

El nuevo motor de enrutamiento principal y el motor de reenvío de paquetes se sincronizan. 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.

Nota:

A partir de Junos OS versión 12.2, si las adyacencias entre el enrutador de reinicio y el tiempo de espera de los enrutadores "ayudante" del par vecino, las extensiones de protocolo de reinicio agraciado no pueden notificar a los enrutadores par "ayudante" acerca del reinicio inminente. El reinicio agraciado puede detenerse y causar interrupciones en el tráfico.

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

Nota:

Los eventos de conmutación sucesivos del motor de enrutamiento deben tener una diferencia mínima de 240 segundos (4 minutos) después de la entrada de ambos motores de enrutamiento.

Si el enrutador o conmutador muestra un mensaje de advertencia similar al Standby Routing Engine is not ready for graceful switchover. Packet Forwarding Engines that are not ready for graceful switchover might be reset de , no intente cambiar. Si elige continuar con la conmutación, solo se restablecen los motores de reenvío de paquetes que no estaban listos para el cambio agraciado. Ninguna de las FPC debe reiniciarse espontáneamente. Recomendamos que espere hasta que deje de aparecer la advertencia y, a continuación, continúe con la conmutación.

Nota:

A partir de Junos OS versión 14.2, cuando realice GRES en enrutadores serie MX, debe ejecutar el clear synchronous-ethernet wait-to-restore comando de modo operativo en el nuevo motor de enrutamiento principal para borrar el temporizador de espera para restaurar en él. 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.

Nota:

En una matriz de enrutamiento con enrutador de transmisión Matrix Plus con SIB 3D, para el cambio sucesivo del motor de enrutamiento, los eventos deben tener una diferencia mínima de 900 segundos (15 minutos) después de que ambos motores de enrutamiento hayan llegado.

El GRES se debe realizar en un chasis de tarjeta de línea (LCC) (de un enrutador de matriz de transmisión con SIB 3D) a la vez para evitar problemas de sincronización.

Nota:

• No recomendamos realizar una operación de confirmación en el motor de enrutamiento de respaldo cuando GRES está habilitado en el enrutador o conmutador.

• No recomendamos habilitar GRES en el motor de enrutamiento de respaldo en ningún caso.

Nota:

En los conmutadores QFX10000, recomendamos encarecidamente que configure la instrucción en el nsr-phantom-holdtime seconds [edit routing-options] nivel de jerarquía cuando el enrutamiento sin interrupción está habilitado con GRES. Esto ayuda a evitar la pérdida de tráfico. Cuando configure esta instrucción, las direcciones IP fantasma permanecen en el kernel durante una conmutación hasta que expire el intervalo de tiempo de espera especificado. Después de que caduca el intervalo, estas rutas se agregan a las tablas de enrutamiento adecuadas. En un entorno de VPN Ethernet (EVPN)/VXLAN, recomendamos que especifique un valor de tiempo de espera de 300 segundos (5 minutos).

La Figura 1 muestra la arquitectura del sistema de la conmutación agraciada del motor de enrutamiento y el proceso que sigue una plataforma de enrutamiento para prepararse para una conmutación.

Nota:

Verifique la preparación de GRES mediante la ejecución de 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 respaldo

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

1. Se inicia el motor de enrutamiento principal.

2. Los procesos de la plataforma de enrutamiento (como el proceso de chasis [chassisd]) se inician.

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

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

5. Se inicia el motor de enrutamiento de respaldo.

6. El sistema determina si GRES se ha habilitado.

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

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

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

Un proceso de conmutación consta de los siguientes pasos:

1. Cuando se pierden las resguardos del motor de enrutamiento principal, el sistema pasa con gracia al motor de enrutamiento de respaldo.

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

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

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

5. Si están configuradas, las extensiones de protocolo de reinicio agraciado recopilan y restauran la información de enrutamiento de enrutadores auxiliares de pares vecinos.

Nota:

En el caso de los enrutadores serie MX que utilizan una administración mejorada de suscriptores, el nuevo motor de enrutamiento de respaldo (el antiguo motor de enrutamiento principal) se reiniciará cuando se realice un cambio agraciado del motor de enrutamiento. Este reinicio en frío vuelve a sincronizar el estado del motor de enrutamiento de respaldo con el del nuevo motor de enrutamiento principal, lo que evita las discrepancias de estado que podrían haberse producido durante la conmutación.

Nota:

Durante GRES en enrutadores serie T y M320 durante GRES, las tarjetas de interfaz de conmutación (SIB) se desconectan y se reinician una por una. Esto se hace para proporcionar la tarjeta entreplanta del procesador del conmutador (SPMB) que administra el SIB el tiempo suficiente para completar la información de estado de su SIB asociada. Sin embargo, en un chasis completamente poblado en el que todas las FPC envían tráfico a una velocidad de línea completa, puede haber una pérdida momentánea de paquetes durante la conmutación.

Nota:

Cuando GRES está configurado y el restart chassis-control comando se ejecuta en un enrutador de transmisión Matrix Plus con SIB 3D, no puede determinar qué motor de enrutamiento se convierte en el principal. Esto se debe a que el proceso de chasis se reinicia con la ejecución del restart chassis-control comando. El proceso de chasis es responsable de mantener y conservar la función principal y, cuando se reinicia, el nuevo chasis se procesa según la carga del enrutador o del conmutador. Como resultado, cualquiera de los motores de enrutamiento se hace el principal.

Efectos de una conmutación de motor de enrutamiento

En la tabla 1 se describen los efectos de una conmutación del motor de enrutamiento cuando se habilitan diferentes funciones:

• Sin funciones de alta disponibilidad

• Cambio elegante del motor de enrutamiento

• Reinicio agraciado

• Enrutamiento activo sin interrupciones

Tabla 1: Efectos de una conmutación de motor de enrutamiento

Característica	Ventajas	Consideraciones
Solo motores de enrutamiento dual (sin funciones habilitadas)	Cuando se completa el cambio al nuevo motor de enrutamiento principal, se produce convergencia de enrutamiento y se reanuda el tráfico.	Todas las interfaces físicas se desconectan. Los motores de reenvío de paquetes se reinician. El motor de enrutamiento de respaldo reinicia el proceso de protocolo de enrutamiento (rpd). El nuevo motor de enrutamiento principal descubre todo el hardware y las interfaces. El cambio tarda varios minutos. Todas las adyacencias del enrutador son conscientes de los cambios físicos (alarmas de interfaz) y enrutamiento (topología).
GRES habilitado	Durante la conmutación, se conserva la información de interfaz y kernel. El cambio es más rápido porque no se reinician los motores de reenvío de paquetes.	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 enrutador.
Habilitados PARA GRES y NSR	El tráfico no se interrumpe durante la conmutación. Se conserva la información de interfaz y kernel.	Los protocolos no compatibles deben actualizarse utilizando los mecanismos de recuperación normales inherentes a cada protocolo.
GRES y el reinicio agraciado habilitado	El tráfico no se interrumpe durante la conmutación. Se conserva la información de interfaz y kernel. Las extensiones de protocolo de reinicio elegante recopilan y restauran rápidamente la información de enrutamiento de los enrutadores vecinos.	Los vecinos deben admitir un reinicio agraciado y se requiere un intervalo de espera. El proceso de protocolo de enrutamiento (rpd) se reinicia. Para ciertos protocolos, un cambio significativo en la red puede hacer que el reinicio agraciado se detenga. A partir de la versión 12.2 de Junos OS, si las adyacencias entre el enrutador que está reiniciando y el tiempo de descanso de los enrutadores 'ayudantes' del par vecino, el reinicio agraciado puede detenerse y causar interrupciones en el tráfico.

Conmutación elegante del motor de enrutamiento en interfaces de servicios agregados

Si un comando de modo operativo activa una conmutación agraciada del motor de enrutamiento (GRES), no se conserva el estado de las interfaces de servicios agregados (ASIs). Por ejemplo:

Sin embargo, si GRES se activa mediante una confirmación de CLI o si se reinicia o se bloquea FPC, el motor de enrutamiento de respaldo actualiza el estado de ASI. Por ejemplo:

O:

Soporte de plataforma de conmutación de motor de enrutamiento elegante

Para permitir un cambio elegante del motor de enrutamiento, su sistema debe cumplir con estos requisitos mínimos:

• Enrutadores M20 y M40e— Junos OS versión 5.7 o posterior

• Enrutador M10i— Junos OS versión 6.1 o posterior

• Enrutador M320: Junos OS versión 6.2 o posterior

• Enrutador T320, enrutador T640 y enrutador de matriz de transmisión— Junos OS versión 7.0 o posterior

• Enrutador M120: Junos OS versión 8.2 o posterior

• Enrutador MX960— Junos OS versión 8.3 o posterior

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

• Enrutador MX240— Junos OS versión 9.0 o posterior

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

• Enrutador independiente T1600— Junos OS versión 8.5 o posterior

• Enrutador independiente T4000— Junos OS versión 12.1R2 o posterior

• Enrutador de transmisión Matrix Plus— Junos OS versión 9.6 o posterior

• Enrutador de transmisión Matrix Plus con SIB 3D— Junos versión 13.1 o posterior

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

• Conmutadores de la serie QFX en un virtual chassis— Junos OS versión 13.2 o posterior 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 la conmutación agraciada del motor de enrutamiento, consulte las secciones que siguen.

Compatibilidad con la función de conmutación de motor de enrutamiento elegante

El cambio graceful routing engine admite la mayoría de las funciones de Junos OS en la versión 5.7 y posteriores. Las características particulares de Junos OS requieren versiones específicas de Junos OS. Véase el cuadro 2.

Tabla 2: Compatibilidad con la función de conmutación del motor de enrutamiento elegante

Aplicación	Versión de Junos OS
Interfaces Ethernet agregadas con el protocolo de control de agregación de vínculos (LACP) y las interfaces SONET agregadas	6.2
Circuitos virtuales (VM) del modo de transferencia asincrónica (ATM)	6.2
Sistemas lógicos Nota: En la versión 9.3 y posteriores de Junos OS, la función del enrutador lógico cambia de nombre a sistema lógico.	6.3
Multidifusión	6.4 (7.0 para enrutador de matriz de transmisión)
Protocolo de punto a punto multivínculo (MLPPP) y Multilink Frame Relay (MLFR)	7.0
Conmutación de protección automática (APS): la interfaz activa actual (ya sea la interfaz designada de funcionamiento o la de protección designada) sigue siendo la interfaz activa durante un cambio del motor de enrutamiento.	7.4
LSP de conmutación de etiquetas multiprotocolo de punto a multipunto MPLS (solo tránsito)	7.4
Protocolo de transporte en tiempo real comprimido (CRTP)	7.6
Servicio LAN privada virtual (VPLS)	8.2
Operación, administración y administración (OAM) Ethernet definida por IEEE 802.3ah	8.5
Agente de retransmisión DHCP extendido	8.5
Ethernet OAM como lo define IEEE 802.1ag	9.0
Proceso del Protocolo de control de puerta de enlace de paquetes (PGCP) (pgcpd) en PIC multiservicio 500 en enrutadores T640.	9.0
Acceso de suscriptores	9.4
Circuito de capa 2 y configuración pseudocable VPLS basada en LDP	9.6

Las siguientes restricciones se aplican a la compatibilidad con funciones de conmutación del motor de enrutamiento agraciado:

• Cuando el conmutador agraciado del motor de enrutamiento y las interfaces Ethernet agregadas se configuran en el mismo sistema, las interfaces Ethernet agregadas no se deben configurar para la LACP de sondeo rápido. Cuando se configura el sondeo rápido, la LACP hace sondeos con tiempo de descanso en el extremo remoto durante la conmutación del rol principal del motor de enrutamiento. Cuando el tiempo de espera de la encuesta LACP, el vínculo y la interfaz agregados se deshabilitan. El cambio de función principal del motor de enrutamiento es lo suficientemente rápido como para que la encuesta LACP estándar y lenta no se despase durante el procedimiento. Sin embargo, tenga en cuenta que esta restricción no se aplica a los enrutadores serie MX que ejecutan Junos OS versión 9.4 o posterior y tienen habilitada la administración de paquetes periódicos (PPM) distribuida (que es la configuración predeterminada) en ellos. En tales casos, puede configurar una conmutación agraciada del motor de enrutamiento y tener interfaces Ethernet agregadas configuradas para LACP de sondeo rápido en el mismo dispositivo.

  Nota:

  Las sesiones DE MACSec se activarán al cambiar el motor de enrutamiento graceful.

  A partir de Junos OS versión 13.2, cuando se produce una conmutación agraciada del motor de enrutamiento, el estado vrrp no cambia. VRRP solo es compatible con la conmutación agraciada del motor de enrutamiento en el caso de que la delegación de PPM esté habilitada (que es el valor predeterminado).

Soporte de DPC con conmutación de motor de enrutamiento elegante

La conmutación del motor de enrutamiento graceful admite todos los concentradores de puerto denso (DPC) en las plataformas de enrutamiento universal 5G serie MX que ejecutan la versión adecuada de Junos OS, como se muestra en la compatibilidad de plataforma de conmutación de motor de enrutamiento graceful. Para obtener más información acerca de los DPC, consulte la Guía de DPC serie MX.

Cambio agraciado del motor de enrutamiento y acceso de suscriptores

La conmutación graceful del motor de enrutamiento actualmente admite la mayoría de las funciones directamente asociadas con DHCP dinámico y acceso de suscriptor ppPoE dinámico. La conmutación del motor de enrutamiento Graceful también admite la actualización unificada del software en servicio (ISSU) para el modelo de acceso DHCP y el modelo de acceso PPPoE utilizado por el acceso de suscriptores.

Nota:

Cuando el cambio agraciado del motor de enrutamiento está habilitado para la administración de suscriptores, todos los motores de enrutamiento del enrutador deben tener la misma cantidad de DRAM para una operación estable.

Soporte de PIC de conmutación de motor de enrutamiento elegante

La conmutación agraciada del motor de enrutamiento se admite en la mayoría de las PIC, a excepción de las PIC de servicios enumeradas en esta sección. La PIC debe estar en una plataforma de enrutamiento compatible que ejecute la versión adecuada de Junos OS. Para obtener más información acerca de los tipos de FPC, la compatibilidad FPC/PIC y la versión inicial de Junos OS en la que una FPC admite una PIC en particular, consulte la guía de PIC para su plataforma de enrutador.

Las siguientes restricciones se aplican a la compatibilidad de conmutación de motor de enrutamiento agraciado para PIC de servicios:

• Puede incluir la instrucción en el graceful-switchover [edit chassis redundancy] nivel de jerarquía en un enrutador con servicios adaptables, multiservicios y PIC de 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 servicio de capa 2 y las aplicaciones de proveedor de extensiones y SDK en PIC multiservicios) se restablecen durante una conmutación.

• La conmutación graceful del motor de enrutamiento no se admite en ninguna PIC de servicios de supervisión ni pic de servicios multilink. 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 en él y emite el commit comando, se produce un error en la confirmación.

• La conmutación graceful routing engine no se admite en las PIC multiservicios 400 configuradas para aplicaciones de servicios de supervisión. Si incluye la graceful-switchover instrucción, se produce un error en la confirmación.

Nota:

Cuando una PIC no compatible está en línea, no puede habilitar la conmutación agraciada del motor de enrutamiento. Si el cambio agraciado del motor de enrutamiento ya está habilitado, no se puede activar una PIC no compatible.