EN ESTA PÁGINA
Requisitos para enrutadores con configuración de enrutador de respaldo
Habilitación de una conmutación elegante del motor de enrutamiento
Configuración de una conmutación normal del motor de enrutamiento con un reinicio normal
Sincronización de la configuración del motor de enrutamiento
Verificar el funcionamiento correcto del cambio del motor de enrutamiento
Configuración de una conmutación agraciada del motor de enrutamiento en un chasis virtual
Evitar el cambio agraciado del motor de enrutamiento en el caso de discos lentos
Ejemplo: Configuración de SI-SI para GRES con reinicio normal
Configuración de una conmutación agraciada del motor de enrutamiento
Aprenda a configurar el cambio del motor de enrutamiento elegante (GRES) con los siguientes pasos y ejemplos.
Requisitos para enrutadores con configuración de enrutador de respaldo
Si la configuración del motor de enrutamiento incluye una backup-router instrucción o una inet6-backup-router instrucción, también puede utilizarla destination para especificar una dirección de subred o varias direcciones de subred para el enrutador de reserva. Incluya las subredes de destino para el motor de enrutamiento de respaldo en el [edit system (backup-router | inet6-backup-router) address] nivel jerárquico.
Si tiene una configuración de enrutador de respaldo en la que varias rutas estáticas apuntan a una puerta de enlace desde la interfaz Ethernet de administración, debe configurar prefijos que sean más específicos que las rutas estáticas o incluir la marca retain en el [edit routing-options static route] nivel jerárquico.
Por ejemplo, si configura la ruta estática 172.16.0.0/12 desde la interfaz Ethernet de administración con fines de administración, debe especificar la configuración del enrutador de respaldo de la siguiente manera:
backup-router 172.29.201.62 destination [172.16.0.0/13 172.16.128.0/13]
Habilitación de una conmutación elegante del motor de enrutamiento
En la mayoría de los casos, el cambio normal del motor de enrutamiento (GRES) está deshabilitado de forma predeterminada. Para configurar GRES, incluya la graceful-switchover instrucción en el nivel de [edit chassis redundancy] jerarquía.
[edit chassis redundancy] graceful-switchover;
Cuando se habilita GRES, la interfaz de línea de comandos (CLI) indica qué motor de enrutamiento está utilizando. Por ejemplo:
{master} [edit]
user@host#
Para deshabilitar GRES, elimine la graceful-switchover instrucción del [edit chassis redundancy] nivel de jerarquía.
Configuración de una conmutación normal del motor de enrutamiento con un reinicio normal
Cuando se usa GRES con reinicio normal, si se agota el tiempo de espera de las adyacencias entre el motor de enrutamiento y los enrutadores "auxiliares" pares vecinos, las extensiones del protocolo de reinicio normal no pueden notificar a los enrutadores "auxiliares" pares 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 el tiempo de espera de los protocolos SI-SI del valor predeterminado de 27 segundos a un valor superior a 40 segundos.
Sincronización de la configuración del motor de enrutamiento
Un motor de enrutamiento de respaldo recién insertado sincroniza automáticamente su configuración con la configuración del motor de enrutamiento principal.
Cuando configure GRES, puede poner en línea el motor de enrutamiento de respaldo después de que el motor de enrutamiento principal ya se esté ejecutando. No es necesario iniciar los dos motores de enrutamiento simultáneamente.
Solo cuando habilite el cambio normal del motor de enrutamiento, puede copiar la versión en ejecución de Junos OS del motor de enrutamiento principal al motor de enrutamiento de respaldo.
Si el sistema está en estado ISSU, no puede copiar la versión de Junos OS en ejecución del motor del enrutador principal.
Puede habilitar la sincronización automática de la configuración del motor de enrutamiento principal con el motor de enrutamiento de respaldo si incluye la instrucción events CHASSISD_SNMP_TRAP7 en el nivel de jerarquía [edit event-options policy policy-name].
CHASSISD_SNMP_TRAP7 es un mensaje de registro de eventos del sistema que indica que el proceso del chasis (chasisd) genera una trampa del protocolo simple de administración de red (SNMP) con los siete pares argumento-valor indicados. A continuación, se muestra un ejemplo de una secuencia de comandos de evento para activar la sincronización automática del principal con el motor de enrutamiento de respaldo:
[edit event-options]
policy UPGRADE-BACKUPRE {
events CHASSISD_SNMP_TRAP7;
attributes-match {
CHASSISD_SNMP_TRAP7.value5 matches "Routing Engine";
CHASSISD_SNMP_TRAP7.trap matches "Fru Online";
CHASSISD_SNMP_TRAP7.argument5 matches jnxFruName;
}
then {
event-script auto-image-upgrade.slax {
arguments {
trap "{$$.trap}";
value5 "{$$.value5}";
argument5 "{$$.argument5}";
}
}
}
}
event-script {
file auto-image-upgrade.slax;
}
Después de recibir este evento, se activa la política de eventos en el motor de enrutador principal y la imagen disponible en la /var/sw/pkg ruta de acceso se inserta en la actualización de respaldo del motor de enrutador. Durante la ejecución del script, la imagen se copia en la ruta del /var/sw/pkg motor de enrutamiento de respaldo.
Si la imagen no está disponible en la /var/sw/pkg ruta, la secuencia de comandos finaliza con un mensaje syslog adecuado.
Los scripts de automatización de Junos se sincronizan automáticamente.
Después de reiniciar el motor del enrutador principal, el script de evento disponible en el /usr/libexec/scripts/event/auto-image-upgrade.slax debe copiarse en el /var/db/scripts/event path.
En el caso de los dispositivos que admiten la 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 correcto del motor de enrutamiento. Este reinicio en frío resincroniza 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 el cambio.
Verificar el funcionamiento correcto del cambio del motor de enrutamiento
Para comprobar si GRES está habilitado en el motor de enrutamiento de respaldo, ejecute el show system switchover comando. Cuando el resultado del comando indica que el campo Cambio elegante está establecido en Activado, GRES está operativo. También se proporciona el estado de la base de datos del kernel y la sincronización de la base de datos de configuración entre motores de enrutamiento. Por ejemplo:
Graceful switchover: On Configuration database: Ready Kernel database: Ready Peer state: Steady state
Debe ejecutar el show system switchover comando en el motor de enrutamiento de respaldo. Este comando no es compatible con el motor de enrutamiento principal.
Para obtener más información acerca del show system switchover comando, consulte el Explorador de CLI.
Configuración de una conmutación agraciada del motor de enrutamiento en un chasis virtual
En un chasis virtual, a un conmutador miembro se le asigna el rol principal y tiene el motor de enrutamiento principal. A otro conmutador miembro se le asigna la función de respaldo y tiene el motor de enrutamiento de respaldo. La conmutación del motor de enrutamiento elegante (GRES) permite que los motores de enrutamiento principal y de respaldo en una configuración de chasis virtual cambien del principal a la copia de respaldo sin interrupción al reenvío de paquetes como una solución de tolerancia a fallos sin fallas. Cuando configura un cambio normal del motor de enrutamiento, el motor de enrutamiento de respaldo se sincroniza automáticamente con el motor de enrutamiento principal para conservar la información del estado del kernel y el estado de reenvío.
Para configurar la configuración del chasis virtual para utilizar el cambio normal del motor de enrutamiento (GRES):
Confirmar la configuración.
Le recomendamos que utilice el comando para guardar los commit synchronize cambios de configuración que realice en un chasis virtual de varios miembros.
Evitar el cambio agraciado del motor de enrutamiento en el caso de discos lentos
El acceso lento inesperado al disco puede ocurrir por varias razones, por ejemplo, un sector defectuoso o defectuoso, lo que causa un retraso en el funcionamiento normal de procesos como el proceso de enrutamiento (rpd). Eventualmente, el rendimiento del enrutador se verá afectado. En estas circunstancias, puede tomar más tiempo para que se active el mecanismo de tolerancia a fallos típico.
Juniper Networks ha introducido un demonio de monitoreo de disco para resolver este dilema. El daemon detecta un acceso lento al disco e inicia la tolerancia a fallos. La conmutación por error puede minimizar el impacto del tráfico y aliviar la carga en el motor de enrutamiento principal original para su limpieza del trabajo pendiente.
Sin embargo, hay casos en los que es posible que no desee que se produzca una tolerancia a fallos. Puede confirmar un gran conjunto de cambios o incluso cambios menores que pueden conducir a una serie de actualizaciones en la topología de enrutamiento. Esta actividad podría provocar un retraso extenso en el acceso al disco y, por lo tanto, desencadenar una tolerancia a fallos. Para retrasos esperados de acceso al disco como este, en los que no desea activar la tolerancia a fallos, puede elegir que no se produzca una tolerancia a fallos estableciendo el comando de chassis redundancy failover not-on-disk-underperform configuración. Otra forma es deshabilitar el demonio de monitoreo de disco por completo configurando el system processes gstatd disable comando.
Para evitar conmutaciones por error en caso de discos lentos en el motor de enrutamiento:
[edit chassis redundancy failover] nivel de jerarquía.
[edit] user@host# set chassis redundancy failover not-on-disk-underperform
Restablecer estadísticas locales
Cuando habilita el cambio normal del motor de enrutamiento, la configuración principal del motor de enrutamiento se copia y se carga en el motor de enrutamiento de respaldo. Los archivos de usuario, la información de contabilidad y la información de opciones de rastreo no se replican en el motor de enrutamiento de respaldo.
Cuando se produce un cambio normal del motor de enrutamiento, las estadísticas locales, como las estadísticas de procesos y las estadísticas de redes, se muestran como un valor acumulativo desde el momento en que el proceso se conectó por primera vez. Dado que los procesos del motor de enrutamiento principal pueden iniciarse en momentos diferentes de los procesos del motor de enrutamiento de respaldo, las estadísticas de los dos motores de enrutamiento para el mismo proceso pueden diferir. Después de cambiar correctamente del motor de enrutamiento, le recomendamos que ejecute el comando borrar estadísticas de interfaz (interface-name | all) para restablecer los valores acumulados de las estadísticas locales. Las estadísticas de reenvío no se ven afectadas por un cambio agraciado del motor de enrutamiento.
Para obtener más información acerca de cómo utilizar el comando clear para borrar estadísticas e información de bases de datos de protocolos, consulte el Explorador de CLI.
El comando borrar firewall no se puede utilizar para borrar los contadores de filtro del motor de enrutamiento en un motor de enrutamiento de respaldo que esté habilitado para un cambio correcto del motor de enrutamiento.
Ejemplo: Configuración de SI-SI para GRES con reinicio normal
En este ejemplo, se muestra cómo configurar las extensiones del protocolo de reinicio correcto del motor de enrutamiento mediante el protocolo de puerta de enlace interior (IGP) de sistema intermedio a sistema intermedio (SI-SI) para habilitar correctamente el cambio normal del motor de enrutamiento (GRES) con un reinicio normal.
Requisitos
GRES evita interrupciones en el tráfico de red si el motor de enrutamiento principal falla cuando se combina con cualquiera de los siguientes elementos:
Reinicio virtuoso
Enrutamiento activo sin paradas (NSR)
Antes de seguir las instrucciones que se indican aquí para configurar el reinicio normal, asegúrese de que ha habilitado GRES, que está deshabilitado de forma predeterminada. Consulte Configuración de conmutación del motor de enrutamiento elegante para obtener más información.
Visión general
Si se agota el tiempo de espera de las adyacencias entre el motor de enrutamiento y los enrutadores "auxiliares" del par vecinos, las extensiones del protocolo de reinicio correcto no pueden notificar a los enrutadores "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 el tiempo de espera de los protocolos SI-SI del valor predeterminado de 27 segundos a un valor superior a 40 segundos.
Si el sistema utiliza el protocolo de abrir primero el camino más corto (OSPF) en lugar de SI-SI, consulte Ejemplo: Configuración de temporizadores de OSPF para obtener información de configuración.
Configuración
- Configuración rápida de CLI
- Configuración del tiempo de espera del protocolo SI-SI para un reinicio correcto
- Resultados
Configuración rápida de CLI
Para configurar rápidamente el tiempo de espera, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en los diferentes niveles de jerarquía que se muestran.
Cada interfaz debe establecerse individualmente, con un valor para cada nivel en el que funciona el dispositivo enrutador. En este ejemplo se utiliza el valor mínimo recomendado de 41 segundos, es posible que el sistema requiera un valor más alto en función del tamaño y el tráfico.
El nivel 1 y el nivel 2 se pueden establecer en valores diferentes.
[editar protocolos]
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
[editar nombre-del-sistema-lógico-lógico-de-los-sistemas}
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
[editar logical-systems logical-system-name routing-instances routing-instance-name]
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
[editar enrutamiento-instances routing-instance-name]
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
Configuración del tiempo de espera del protocolo SI-SI para un reinicio correcto
Procedimiento paso a paso
Para configurar el tiempo de espera de SI-SI para un reinicio normal:
Localice o establezca las interfaces.
set protocols isis interface interface-name
Establezca el nivel de red y el tiempo de espera en segundos para ese nivel.
set protocols isis interface interface-name level 1 hold-time 41
Si el dispositivo enrutador funciona en más de un nivel, establezca el valor para el otro nivel.
set protocols isis interface interface-name level 2 hold-time 41
Cuando termine de configurar el dispositivo de enrutamiento, confirme la configuración.
Nota:Repita toda la configuración en todos los dispositivos de enrutamiento de una red compartida.
Resultados
Verificación
Verificar el tiempo de espera del protocolo SI-SI para un reinicio correcto
Propósito
Compruebe que el tiempo de espera del protocolo SI-SI está establecido en 41 segundos o más para asegurarse de que está habilitado el reinicio normal.
Acción
Ingrese el comando desde el modo operativo para confirmar la show isis adjacency brief configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregirla.
Significado
Un valor de tiempo de espera del protocolo SI-SI lo suficientemente alto permite que la configuración del sistema se reinicie y garantiza que, incluso si falla un motor de enrutamiento, el tráfico continuará.