Descripción de la conmutación agraciada del motor de enrutamiento
Este tema contiene las siguientes secciones:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Verifique la preparación de GRES mediante la ejecución de ambos:
El
request chassis routing-engine master switch checkcomando del motor de enrutamiento principalEl
show system switchovercomando del motor de enrutamiento de respaldo
El proceso de preparación del cambio para GRES es el siguiente:
Se inicia el motor de enrutamiento principal.
Los procesos de la plataforma de enrutamiento (como el proceso de chasis [chassisd]) se inician.
El motor de reenvío de paquetes se inicia y se conecta al motor de enrutamiento principal.
Toda la información de estado se actualiza en el sistema.
Se inicia el motor de enrutamiento de respaldo.
El sistema determina si GRES se ha habilitado.
El proceso de sincronización del kernel (ksyncd) sincroniza el motor de enrutamiento de respaldo con el motor de enrutamiento principal.
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).
motor de enrutamiento
Un proceso de conmutación consta de los siguientes pasos:
Cuando se pierden las resguardos del motor de enrutamiento principal, el sistema pasa con gracia al motor de enrutamiento de respaldo.
El motor de reenvío de paquetes se conecta al motor de enrutamiento de respaldo, que se convierte en el nuevo principal.
Los procesos de plataforma de enrutamiento que no forman parte de GRES (como el rpd de proceso de protocolo de enrutamiento) se reinician.
La información de estado aprendida desde el punto de la conmutación se actualiza en el sistema.
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.
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.
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.
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
Característica |
Ventajas |
Consideraciones |
|---|---|---|
Solo motores de enrutamiento dual (sin funciones habilitadas) |
|
|
GRES habilitado |
|
|
Habilitados PARA GRES y NSR |
|
|
GRES y el reinicio agraciado habilitado |
|
|
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:
request interface <switchover | revert> asi-interface
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:
set interface si-x/y/z disable commit
O:
request chassis fpc restart
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.