Descripción de la conmutación de enrutamiento elegante

Conceptos de conmutación del motor de enrutamiento elegante

La característica 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 del protocolo de enrutamiento individual.

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

• Extensiones del protocolo de reinicio elegante

• Enrutamiento activo sin paradas (NSR)

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

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

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

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

• El administrador inicia un cambio manual.

Si el motor de enrutamiento de respaldo no recibe una red persistente del motor de enrutamiento principal después de 2 segundos, determina que se produjo un error en el motor de enrutamiento principal; y asume la función principal.

El motor de reenvío de paquetes:

• Se desconecta sin problemas del antiguo motor de enrutamiento principal

• Se vuelve a conectar al nuevo motor de enrutamiento principal

• No se reinicia

• No interrumpe el tráfico

A continuación, 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, vuelve a enviar 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 agota el tiempo de espera de las adyacencias entre el dispositivo de reinicio y los dispositivos "auxiliares" del par vecinos, las extensiones del protocolo de reinicio agraciado no pueden notificar a los dispositivos "auxiliares" del mismo nivel sobre el reinicio inminente. El reinicio correcto puede detenerse y causar interrupciones en el tráfico.

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

• Los eventos sucesivos de conmutación del motor de enrutamiento deben estar separados por un mínimo de 240 segundos (4 minutos) después de que ambos motores de enrutamiento hayan aparecido.

  Si el dispositivo muestra un mensaje de advertencia similar al siguiente:

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

• No recomendamos:

  • Realización de una operación de confirmación en el motor de enrutamiento de respaldo 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 conmutación agraciada del motor de enrutamiento y el proceso que sigue una plataforma de enrutamiento para prepararse para una conmutación.

Figura 1: Preparación para un cambio agraciado del motor de enrutamiento

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 de chasis [chassisd]).

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 se ha habilitado GRES.

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

8. Una vez que ksyncd completa la sincronización, se actualiza toda la información de estado y la tabla de reenvío.

La Figura 2 muestra los efectos de una conmutación en la plataforma de enrutamiento (o conmutación).

Figura 2: Proceso de conmutación del motor de enrutamiento elegante

Un proceso de cambio consta de los siguientes pasos:

1. Cuando se pierden las señales del motor de enrutamiento principal, el sistema cambia correctamente 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 proceso de protocolo de enrutamiento rpd) se reinician.

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

5. Si están configuradas, las extensiones del protocolo de reinicio correcto recopilan y restauran la información de enrutamiento de los dispositivos de ayuda par vecinos.

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

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

Efectos de una conmutación del motor de enrutamiento

En la tabla 1 se describen los efectos de un cambio de motor de enrutamiento cuando se habilitan diferentes características:

• Sin funciones de alta disponibilidad

• Conmutación del motor de enrutamiento elegante

• Reinicio virtuoso

• Enrutamiento activo sin paradas

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

Si un comando del modo operativo activa una conmutación normal del 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 bien:

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

Para habilitar un cambio normal del 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: Junos OS versión 9.0 o posterior

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

• Conmutadores de la serie EX con motores de enrutamiento duales o en un chasis virtual: versión 9.2 o posterior de Junos OS para conmutadores de la 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 de la serie EX o la serie QFX en una estructura del chasis virtual: versión 13.2X51-D20 o posterior de Junos OS para los conmutadores de la serie EX y la serie QFX

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

Soporte de la característica de cambio del motor de enrutamiento elegante

El cambio del motor de enrutamiento elegante admite la mayoría de las funciones de Junos OS en la versión 5.7 y posteriores. Algunas funciones de Junos OS requieren versiones específicas de Junos OS. Ver Tabla 2.

Las siguientes restricciones se aplican a la compatibilidad con la característica de conmutación del motor de enrutamiento:

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

  Nota:

  Las sesiones de MACSec oscilarán al cambiar el motor de enrutamiento agraciado.

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

Conmutación del motor de enrutamiento elegante y acceso de suscriptores

El cambio del motor de enrutamiento elegante actualmente admite la mayoría de las características directamente asociadas con el DHCP dinámico y el acceso dinámico de los suscriptores PPPoE. La conmutación del motor de enrutamiento elegante también admite la actualización de software en servicio (ISSU) unificada para el modelo de acceso DHCP y el modelo de acceso PPPoE utilizado por el acceso de los suscriptores.

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

El cambio del motor de enrutamiento elegante se admite en la mayoría de las PIC, excepto en 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 información acerca de los tipos de FPC, la compatibilidad con FPC/PIC y la versión inicial de Junos OS en la que una FPC admitió una PIC determinada, consulte la guía de PIC para su plataforma de enrutador.

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

• Puede incluir la graceful-switchover instrucción en el nivel de [edit chassis redundancy] jerarquía en un enrutador con PIC de servicios adaptativos, multiservicios y servicios de túnel configurados 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 proveedores de extensiones y SDK en PIC de multiservicios, se restablecen durante una conmutación.

• El cambio del motor de enrutamiento elegante no se admite en ninguna PIC de servicios de monitoreo 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 que tenga configurado cualquiera de estos tipos de PIC y emite el comando, se producirá un error en la commit confirmación.

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

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

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