EN ESTA PÁGINA
Descripción del reinicio correcto
El reinicio correcto permite el reenvío ininterrumpido de paquetes y la supresión temporal de todas las actualizaciones del protocolo de enrutamiento durante el proceso de reinicio.
Conceptos de reinicio correcto
Con los protocolos de enrutamiento, cualquier interrupción del servicio requiere que un enrutador afectado recalcule las adyacencias con enrutadores vecinos, restaure las entradas de la tabla de enrutamiento y actualice otra información específica del protocolo. Un reinicio desprotegido de un enrutador puede provocar retrasos en el reenvío, aleteo de rutas, tiempos de espera derivados de la reconvergencia del protocolo e incluso paquetes perdidos. Algunos beneficios de un reinicio correcto son el reenvío ininterrumpido de paquetes y la supresión temporal de todas las actualizaciones del protocolo de enrutamiento. El reinicio correcto permite que un enrutador pase a través de estados de convergencia intermedios que están ocultos para el resto de la red.
Hay tres tipos principales de reinicio correcto disponibles en las plataformas de enrutamiento de Juniper Networks:
Reinicio correcto para rutas agregadas y estáticas y para protocolos de enrutamiento: proporciona protección para rutas agregadas y estáticas, y para protocolos de enrutamiento en modo disperso del Protocolo de puerta de enlace de borde (BGP), sistema final a sistema intermedio (ES-IS), sistema intermedio a sistema intermedio (IS-IS), ruta abierta más corta primero (OSPF), Protocolo de información de enrutamiento (RIP), RIP de próxima generación (RIPng) y multidifusión independiente de protocolo (PIM).
Reinicio correcto para protocolos relacionados con MPLS: proporciona protección para el protocolo de distribución de etiquetas (LDP), el protocolo de reserva de recursos (RSVP), la conexión cruzada de circuitos (CCC) y la conexión cruzada de traducción (TCC). (No se admite en conmutadores de la serie OCX).
Reinicio correcto para redes privadas virtuales (VPN): proporciona protección para VPN de capa 2 y capa 3.
El reinicio correcto funciona de manera similar para los protocolos de enrutamiento y los protocolos MPLS, y combina componentes de estos tipos de protocolo para habilitar el reinicio correcto en VPN. Los principales beneficios de un reinicio correcto son el reenvío ininterrumpido de paquetes y la supresión temporal de todas las actualizaciones del protocolo de enrutamiento. Por lo tanto, un reinicio correcto permite que un enrutador pase a través de estados de convergencia intermedios que están ocultos para el resto de la red.
La mayoría de las implementaciones de reinicio correctas definen dos tipos de enrutadores: el enrutador de reinicio y el enrutador auxiliar. El enrutador de reinicio requiere una restauración rápida de la información del estado de reenvío para que pueda reanudar el reenvío del tráfico de red. El enrutador auxiliar ayuda al enrutador de reinicio en este proceso. Las instrucciones de configuración de reinicio correcto suelen afectar al enrutador de reinicio o al enrutador auxiliar.
Reinicio correcto para rutas agregadas y estáticas
Cuando se incluye la graceful-restart instrucción en el nivel de [edit routing-options] jerarquía, se protegen todas las rutas estáticas o agregadas que se hayan configurado. Dado que ningún enrutador auxiliar ayuda en el reinicio, estas rutas se conservan en la tabla de reenvío mientras el enrutador se reinicia (en lugar de descartarse o actualizarse).
Protocolos de reinicio y enrutamiento agraciados
En esta sección se tratan los siguientes temas:
BGP
Cuando se reinicia un enrutador habilitado para el reinicio correcto de BGP, conserva las rutas del par BGP en su tabla de reenvío y las marca como obsoletas. Sin embargo, continúa reenviando tráfico a otros pares (o pares receptores) durante el reinicio. Para restablecer las sesiones, el enrutador de reinicio establece el bit de "estado de reinicio" en el mensaje BGP OPEN y lo envía a todos los pares participantes. Los pares receptores responden al enrutador de reinicio con mensajes que contienen marcadores de fin de tabla de enrutamiento. Cuando el enrutador o conmutador que se reinicia recibe todas las respuestas del par receptor, el enrutador que reinicia realiza la selección de ruta, se actualiza la tabla de reenvío y se descartan las rutas marcadas anteriormente como obsoletas. En este punto, todas las sesiones BGP se restablecen y el par que se reinicia puede recibir y procesar mensajes BGP como de costumbre.
Mientras el enrutador de reinicio realiza su procesamiento, los pares receptores también retienen temporalmente la información de enrutamiento. Cuando un par receptor detecta un restablecimiento de transporte TCP, conserva las rutas recibidas y marca las rutas como obsoletas. Después de restablecer la sesión con el enrutador o conmutador que se reinicia, las rutas obsoletas se reemplazan por información de ruta actualizada.
IS-IS
Normalmente, los enrutadores IS-IS mueven las adyacencias vecinas al estado inactivo cuando se producen cambios. Sin embargo, un enrutador habilitado para el reinicio correcto IS-IS envía mensajes de saludo con el bit de solicitud de reinicio (RR) establecido en un mensaje de valor de longitud de tipo de reinicio (TLV). Esto indica a los enrutadores vecinos que se está llevando a cabo un reinicio correcto y que se debe dejar intacta la adyacencia IS-IS. Los enrutadores vecinos deben interpretar e implementar la señalización de reinicio por sí mismos. Además de mantener la adyacencia, los vecinos envían PDU de número de secuencia completo (CSNP) al enrutador de reinicio e inundan toda su base de datos.
El enrutador de reinicio nunca inunda ninguna de sus propias PDU de estado de vínculo (LSP), incluidos los LSP de pseudonodos, a vecinos de IS-IS mientras se somete a un reinicio correcto. Esto permite a los vecinos restablecer sus adyacencias sin pasar al estado inactivo y permite que el enrutador de reinicio reinicie una sincronización de base de datos sin problemas.
OSPF y OSPFv3
Cuando se reinicia un enrutador habilitado para el reinicio correcto de OSPF, conserva las rutas aprendidas antes del reinicio en su tabla de reenvío. El enrutador no permite que los nuevos anuncios de estado de vínculo (LSA) de OSPF actualicen la tabla de enrutamiento. Este enrutador continúa reenviando tráfico a otros vecinos de OSPF (o enrutadores auxiliares) y envía solo un número limitado de LSA durante el período de reinicio. Para restablecer las adyacencias de OSPF con vecinos, el enrutador de reinicio debe enviar un LSA de gracia a todos los vecinos. En respuesta, los enrutadores auxiliares entran en modo auxiliar y envían una confirmación al enrutador de reinicio. Si no hay cambios en la topología, los enrutadores auxiliares continúan anunciando LSA como si el enrutador de reinicio hubiera permanecido en funcionamiento OSPF continuo.
Cuando el enrutador de reinicio recibe respuestas de todos los enrutadores auxiliares, el enrutador de reinicio selecciona rutas, actualiza la tabla de reenvío y descarta las rutas antiguas. En este punto, se restablecen las adyacencias completas de OSPF y el enrutador de reinicio recibe y procesa los LSA de OSPF como de costumbre. Cuando los enrutadores auxiliares ya no reciben LSA de gracia del enrutador de reinicio o la topología de la red cambia, los enrutadores auxiliares también reanudan el funcionamiento normal.
Para obtener más información acerca de la implementación del modo auxiliar estándar, consulte RFC 3623, Reinicio correcto de OSPF.
A partir de la versión 11.3, Junos OS admite el modo auxiliar basado en señales de reinicio para las configuraciones de reinicio correcto de OSPF. Los modos auxiliar, tanto estándar como basado en señales de reinicio, están habilitados de forma predeterminada. En las implementaciones del modo auxiliar basado en la señalización de reinicio, el enrutador de reinicio transmite el estado de reinicio a sus vecinos sólo una vez finalizado el reinicio. Cuando se completa el reinicio, el enrutador de reinicio envía mensajes de saludo a sus enrutadores auxiliares con el bit de señal de reinicio (RS) establecido en el encabezado del paquete de saludo. Cuando un enrutador auxiliar recibe un paquete de saludo con el bit RS establecido en el encabezado, el enrutador auxiliar devuelve un mensaje de saludo al enrutador que se reinicia. El mensaje de saludo de respuesta del enrutador auxiliar contiene la marca ResyncState y el temporizador ResyncTimeout que permiten que el enrutador de reinicio realice un seguimiento de los enrutadores auxiliares que se sincronizan con él. Cuando todos los ayudantes completen la sincronización, el enrutador de reinicio saldrá del modo de reinicio.
Para obtener más información acerca de la implementación del modo auxiliar de reinicio correcto basado en la señalización de reinicio, consulte RFC 4811, Resincronización de la base de datos de estado de vínculo fuera de banda (LSDB) de OSPF, RFC 4812, Señalización de reinicio de OSPF y RFC 4813, Señalización local de vínculo OSPF.
El modo auxiliar de reinicio elegante basado en señales de reinicio no es compatible con las configuraciones de OSPFv3.
Modo disperso de PIM
El modo disperso PIM utiliza un mecanismo denominado identificador de generación para indicar la necesidad de un reinicio correcto. Los identificadores de generación se incluyen de forma predeterminada en los mensajes de saludo PIM. Cada vecino de PIM crea un identificador de generación inicial para establecer las capacidades del dispositivo. Cuando uno de los vecinos de PIM se reinicia, envía un identificador de nueva generación a sus vecinos. Todos los vecinos que admiten el reinicio correcto y están conectados por vínculos punto a punto ayudan enviando actualizaciones de multidifusión al vecino que se reinicia.
La fase de reinicio se completa cuando el estado PIM se estabiliza o cuando expira el temporizador de intervalo de reinicio. Si los vecinos no admiten el reinicio correcto o no se conectan entre sí mediante interfaces multipunto, el enrutador de reinicio utiliza el temporizador de intervalo de reinicio para definir el período de reinicio.
RIP y RIPng
Cuando se reinicia un enrutador habilitado para el reinicio correcto de RIP, las rutas que se han configurado están protegidas. Dado que ningún enrutador auxiliar ayuda en el reinicio, estas rutas se conservan en la tabla de reenvío mientras el enrutador se reinicia (en lugar de descartarse o actualizarse).
Reinicio correcto y protocolos relacionados con MPLS
Esta sección contiene los siguientes temas:
LDP
El reinicio correcto de LDP permite que un enrutador cuyo plano de control LDP está experimentando un reinicio continúe reenviando tráfico mientras recupera su estado de los enrutadores vecinos. También habilita un enrutador en el que está habilitado el modo auxiliar para ayudar a un enrutador vecino que está intentando reiniciar LDP.
Durante la inicialización de la sesión, un enrutador anuncia su capacidad para realizar un reinicio correcto de LDP o para aprovechar que un vecino realiza un reinicio correcto de LDP enviando el TLV de reinicio correcto. Este TLV contiene dos campos relevantes para el reinicio correcto de LDP: el tiempo de reconexión y el tiempo de recuperación. Los valores de los tiempos de reconexión y recuperación indican las capacidades de reinicio correcto compatibles con el enrutador.
El tiempo predeterminado de reconexión se configura en Junos OS como 60 segundos y es configurable por el usuario. El tiempo de reconexión es el tiempo que espera el enrutador auxiliar a que el enrutador de reinicio establezca una conexión. Si la conexión no se establece dentro del intervalo de reconexión, finaliza correctamente el reinicio de la sesión LDP. El tiempo máximo predeterminado de reconexión es de 120 segundos y es configurable por el usuario. El tiempo máximo de reconexión es el valor máximo que un enrutador auxiliar acepta de su vecino de reinicio.
Cuando un enrutador descubre que un enrutador vecino se está reiniciando, espera hasta el final del tiempo de recuperación antes de intentar volver a conectarse. El tiempo de recuperación es el tiempo que un enrutador espera a que LDP se reinicie correctamente. El período de recuperación comienza cuando se envía o recibe un mensaje de inicialización. Este período de tiempo también suele ser el período de tiempo que un enrutador vecino mantiene su información sobre el enrutador que se reinicia, para que pueda continuar reenviando el tráfico.
Puede configurar el reinicio correcto de LDP tanto en la instancia maestra para el protocolo LDP como para una instancia de enrutamiento específica. Puede deshabilitar el reinicio correcto en el nivel global para todos los protocolos, en el nivel de protocolo solo para LDP y solo para una instancia de enrutamiento específica.
RSVP
El reinicio correcto de RSVP permite que un enrutador que se somete a un reinicio informe a sus vecinos adyacentes de su condición. El enrutador de reinicio solicita un período de gracia al vecino o par, que luego puede cooperar con el enrutador de reinicio. El enrutador que se reinicia aún puede reenviar tráfico MPLS durante el período de reinicio; La convergencia en la red no se interrumpe. El reinicio no es visible para el resto de la red y el enrutador de reinicio no se elimina de la topología de red. El reinicio correcto de RSVP se puede habilitar tanto en enrutadores de tránsito como en enrutadores de entrada. Está disponible tanto para LSP punto a punto como para LSP punto a multipunto.
CCC y TCC
El reinicio correcto de CCC y TCC permite que las conexiones de capa 2 entre los enrutadores perimetrales del cliente (CE) se reinicien correctamente. Estas conexiones de capa 2 se configuran con el conmutador lsp-switch o las instrucciones de interfaz remota. Dado que estas conexiones CCC y TCC tienen una dependencia implícita de los LSP RSVP, el reinicio correcto para CCC y TCC utiliza las capacidades de reinicio correcto del RSVP.
El reinicio correcto de RSVP debe estar habilitado en los enrutadores perimetrales del proveedor (PE) y enrutadores del proveedor (P) para habilitar el reinicio correcto para CCC y TCC. Además, dado que RSVP se utiliza como protocolo de señalización para señalar la información de la etiqueta, el enrutador vecino debe utilizar el modo auxiliar para ayudar con los procedimientos de reinicio de RSVP.
Descripción de la compatibilidad del modo auxiliar basado en señales de reinicio para el reinicio correcto de OSPF
A partir de la versión 11.4, Junos OS admite el modo auxiliar basado en señales de reinicio para las configuraciones de reinicio correcto de OSPF.
El modo auxiliar de reinicio elegante basado en señales de reinicio no es compatible con las configuraciones de OSPFv3.
Las versiones de Junos OS anteriores a la versión 11.4 y las configuraciones de OSPFv3 solo admiten el modo auxiliar estándar, tal como se define en RFC 3623. Para obtener más información acerca de la implementación del modo auxiliar estándar, consulte RFC 3623 y la Guía de configuración de alta disponibilidad de Junos OS.
Tanto el modo auxiliar estándar como el modo auxiliar basado en señales de reinicio están habilitados de forma predeterminada, independientemente del estado de configuración de reinicio correcto en el dispositivo.
En las implementaciones del modo auxiliar basado en señales de reinicio, el enrutador de reinicio informa el estado de reinicio a sus vecinos sólo una vez finalizado el reinicio. Cuando se completa el reinicio, el enrutador de reinicio envía mensajes de saludo a sus enrutadores auxiliares con el bit de señal de reinicio (RS) establecido en el encabezado del paquete de saludo. Cuando un enrutador auxiliar recibe un paquete de saludo con el bit RS establecido en el encabezado, el enrutador auxiliar devuelve un mensaje de saludo al enrutador que se reinicia. El mensaje de saludo de respuesta del enrutador auxiliar contiene la marca ResyncState y el temporizador ResyncTimeout que permiten que el enrutador de reinicio realice un seguimiento de los enrutadores auxiliares que se sincronizan con él. Cuando todos los ayudantes completen la sincronización, el enrutador de reinicio saldrá del modo de reinicio.
Para obtener más información acerca de la implementación del modo auxiliar de reinicio correcto basado en señalización, consulte RFC 4811, Resincronización de bases de datos de estado de vínculos fuera de banda (LSDB) OSPF, RFC 4812, Señalización de reinicio OSPFy RFC 4813, Señalización local de vínculo OSPF.
Reinicio correcto y VPN de capa 2 y capa 3
El reinicio correcto de VPN utiliza tres tipos de funcionalidad de reinicio:
La funcionalidad de reinicio correcto de BGP se utiliza en todas las sesiones de BGP de PE a PE. Esto afecta a las sesiones que transportan cualquier dato de señalización de servicio para la información de accesibilidad de la capa de red (NLRI), por ejemplo, una VPN IPv4 o una NLRI VPN de capa 2.
La funcionalidad de reinicio correcto OSPF, IS-IS, LDP o RSVP se utiliza en todos los enrutadores principales. Las rutas agregadas por estos protocolos se utilizan para resolver NLRI VPN de capa 2 y capa 3.
La funcionalidad de reinicio del protocolo se usa para cualquier protocolo de capa 3 (RIP, OSPF, LDP, etc.) utilizado entre el PE y los enrutadores perimetrales del cliente (CE). Esto no se aplica a las VPN de capa 2 porque los protocolos de capa 2 utilizados entre los enrutadores CE y PE no tienen capacidades de reinicio correctas.
Antes de que el reinicio correcto de VPN pueda funcionar correctamente, todos los componentes deben reiniciarse correctamente. En otras palabras, los enrutadores deben conservar sus estados de reenvío y solicitar a los vecinos que continúen reenviando al enrutador en caso de un reinicio. Si se cumplen todas las condiciones, el reinicio correcto de VPN impone las siguientes reglas en un enrutador que se reinicia:
El enrutador debe esperar a recibir toda la información BGP NLRI de otros enrutadores PE antes de anunciar rutas a los enrutadores CE.
El enrutador debe esperar a que todos los protocolos de todas las instancias de enrutamiento converjan (o completar el proceso de reinicio) antes de enviar la información del enrutador CE a otros enrutadores PE. En otras palabras, el enrutador debe esperar a que se procese toda la información de la instancia (ya sea derivada de la configuración local o de los anuncios recibidos de un par remoto) antes de enviar esta información a otros enrutadores PE.
El enrutador debe conservar todo el estado de reenvío en las tablas instance.mpls.0 hasta que las nuevas etiquetas y rutas de tránsito se asignen y anuncien a otros enrutadores PE (y enrutadores CE en un escenario de portadora de portadoras).
Si no se cumple alguna condición, el reinicio correcto de VPN no logra proporcionar un reenvío ininterrumpido entre enrutadores CE a través de la infraestructura VPN.
Reinicio correcto en sistemas lógicos
El reinicio correcto para un sistema lógico funciona de la misma manera que lo hace el reinicio correcto en el enrutador principal. La única diferencia es la ubicación de la graceful-restart instrucción:
Para un sistema lógico, incluya la
graceful-restartinstrucción en el nivel jerárquico[edit logical-systems logical-system-name routing-options].Para una instancia de enrutamiento dentro de un sistema lógico, incluya la
graceful-restartinstrucción en los niveles de[edit logical-systems logical-system-name routing-options]jerarquía y[edit logical-systems logical-system-name routing-instances instance-name routing-options].
Requisitos del sistema para reiniciar correctamente
El reinicio correcto es compatible con todas las plataformas de enrutamiento. Para implementar un reinicio correcto para características particulares, su sistema debe cumplir estos requisitos mínimos:
Junos OS versión 5.3 o posterior para ruta agregada, BGP, IS-IS, OSPF, RIP, RIPng o reinicio correcto de ruta estática.
Junos OS versión 5.5 o posterior para RSVP en enrutadores perimetrales del proveedor de salida (PE).
Junos OS versión 5.5 o posterior para un reinicio correcto de LDP.
Junos OS versión 5.6 o posterior para las implementaciones CCC, TCC, VPN de capa 2 o VPN de capa 3 de reinicio correcto.
Junos OS versión 6.1 o posterior para un reinicio correcto de RSVP en enrutadores de PE de entrada.
Junos OS versión 6.4 o posterior para el modo disperso PIM, reinicio correcto.
Junos OS versión 7.4 o posterior para el reinicio correcto de ES-IS.
Junos OS versión 8.5 o posterior para sesión BFD (solo modo auxiliar): si un nodo está experimentando un reinicio correcto y sus sesiones BFD se distribuyen al motor de reenvío de paquetes, el nodo par puede ayudar al par con el reinicio correcto.
Junos OS versión 9.2 o posterior para que BGP admita el modo auxiliar sin necesidad de configurar un reinicio correcto.