Descripción del reinicio correcto para BGP
Descripción de la capacidad de reinicio agraciado del BGP de larga duración
Junos OS admite el mecanismo para conservar los detalles de enrutamiento del BGP durante un período más largo de un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio satisfactorio del BGP.
Históricamente, los protocolos de enrutamiento y BGP, en particular, se han diseñado con un enfoque en la corrección, donde un aspecto significativo de la "corrección" es que el estado de reenvío de cada elemento de la red converja hacia el estado actual de la red lo más rápido posible. Por esta razón, el protocolo fue diseñado para eliminar el estado anunciado por los enrutadores que se caían (desde la perspectiva de BGP) lo antes posible. Con el uso del reinicio agraciado del BGP definido en RFC 4724, la funcionalidad de convergencia rápida ha sido un intento de eliminar rápidamente el estado "obsoleto" de la red.
Durante un período de tiempo, dos factores contribuyentes han hecho que este método de eliminación rápida de estados obsoletos se modifique y mejore. La primera es la adopción generalizada de infraestructuras de reenvío en túnel, por ejemplo, MPLS. Estas infraestructuras eliminan el riesgo de algunos tipos de bucles de reenvío que pueden surgir en el reenvío salto a salto y, por lo tanto, reducen una de las motivaciones para una fuerte coherencia entre los elementos de reenvío. El segundo es el uso cada vez mayor de BGP como transporte de datos menos estrechamente asociado con el reenvío de paquetes de lo que era el caso originalmente. Algunos ejemplos son el uso de BGP para el autodescubrimiento (VPLS [RFC4761]) y la programación de filtros (FLOWSPEC [RFC5575]). En estos casos, los datos del BGP asumen una característica que no está en línea con el enrutamiento tradicional.
Era importante ofrecer a los operadores de red la capacidad de optar por conservar los datos del BGP durante un período más prolongado cuando el plano de control del BGP falla por algún motivo. Aunque las propiedades del reinicio agraciado del BGP se acercan a este requisito deseado de conservar la información del BGP durante más tiempo, existen varias lagunas, sobre todo en el tiempo máximo durante el cual se puede conservar la información "obsoleta": el reinicio agraciado impone una limitación de límite superior de 4095 segundos. Junos OS admite una capacidad de BGP denominada capacidad de reinicio agraciado de larga duración para que la información obsoleta se pueda conservar durante más tiempo durante un restablecimiento de sesión. También admite una nueva comunidad BGP, "LLGR_STALE", para marcar dicha información. Dicha información obsoleta debe tratarse como la menos preferida y su publicidad se limitará a los altavoces BGP que admitan la nueva capacidad.
El reinicio agraciado de larga duración (LLGR) del BGP permite a un operador de red elegir mantener la información de enrutamiento obsoleta de un par BGP con errores durante mucho más tiempo que la instalación de reinicio agraciado del BGP existente. Esta funcionalidad para mantener las rutas del BGP durante un período de tiempo más largo está de acuerdo con el borrador de GTI-I, Soporte para un reinicio satisfactorio de BGP de larga duración—draft-uttaro-idr-bgp-persistence-03. Según este borrador, el reinicio agraciado de larga duración (LLGR) debe configurarse explícitamente según NLRI e incluye disposiciones para evitar la propagación de información obsoleta a otros pares que no reconocen ni validan LLGR. Los siguientes beneficios y operaciones son causados por LLGR:
-
Las rutas de los nodos con errores se conservan durante un período de tiempo configurado (del orden de días).
-
Puede examinar los estados de negociación de LLGR por NLRI mediante los comandos show adecuados.
-
Puede ver si LLGR está actualmente en vigor para un par y, si está en vigor, el período después del cual caduca.
-
Las rutas obsoletas conservadas por LLGR se marcan explícitamente en la salida del
show bgp neighborcomando. -
Las rutas obsoletas aprendidas de otros vecinos se marcan explícitamente en la salida del
show bgp neighborcomando (mediante comunidades bien definidas).
Aunque la metodología LLGR se puede aplicar a varios escenarios diferentes, un escenario específico es el objetivo principal de esta característica. En una situación en la que se produce una pérdida de conectividad entre un reflector de ruta y un cliente, incluida la conectividad intermitente, lo que puede hacer que se restablezca una conexión antes de que se pueda transmitir toda la RIB, dicha falla no resulta en un reinicio. Además, tal fenómeno no implica que exista ningún tipo de problema de conectividad entre los clientes y los próximos saltos anunciados por el reflector de ruta. Se anticipa que un tiempo de reinicio típico de larga duración es del orden de 12 horas.
Se admiten todas las pautas de comportamiento y los puntos operativos descritos en el borrador de GTI-I, draft-uttaro-idr-bgp-persistence-03, para LLGR. Además, se admite la compatibilidad con versiones anteriores de las funciones de Junos OS existentes en versiones anteriores a la versión 15.1, específicamente el reinicio elegante y el enrutamiento sin interrupción (NSR). Cuando se configura LLGR, el reinicio agraciado funciona de la manera existente, excepto como se ilustra explícitamente en el borrador de Internet. También puede configurar LLGR y NSR al mismo tiempo, y lograr la funcionalidad completa de LLGR. Como requisito previo para LLGR, se implementa la compatibilidad con el borrador de GTI-I, compatibilidad con mensajes de notificación para reinicio satisfactorio de BGP: draft-ietf- idr-bgp-gr-notification-01. Este borrador amplía el comportamiento de la RG ordinaria para permitirle proteger contra interrupciones de las comunicaciones y errores de protocolo.
Ver también
Descripción de la configuración del período máximo para la generación automática de señales de mantenimiento de BGP mediante temporizadores de kernel después del cambio
En Junos OS, el enrutamiento activo sin paradas (NSR) utiliza la misma infraestructura que el cambio normal del motor de enrutamiento (GRES) para conservar la información de la interfaz y del kernel. Sin embargo, NSR también guarda la información del protocolo de enrutamiento mediante la ejecución del proceso de protocolo de enrutamiento (rpd) en el motor de enrutamiento de respaldo. Al guardar esta información adicional, NSR es autónomo y no depende de enrutadores auxiliares (o conmutadores) para ayudar a la plataforma de enrutamiento a restaurar la información del protocolo de enrutamiento. NSR es ventajoso en redes donde los enrutadores (o conmutadores) vecinos no admiten extensiones de protocolo de reinicio agraciadas. Como resultado de esta funcionalidad mejorada, NSR es un reemplazo natural para un reinicio elegante.
La fusión automática de enrutamiento activo sin paradas es uno de los componentes del kernel de la replicación de sockets. En la conmutación, este componente combina automáticamente los pares de sockets de la copia de seguridad al motor de enrutamiento principal. El cambio de NSR de respaldo a principal ocurre cuando rpd emite una llamada de combinación para cada par de sockets secundario para fusionarlos en un solo socket, lo que podría resultar en un retraso. Para evitar este retraso, un módulo de fusión automática en el kernel desacopla la combinación de sockets secundarios de rpd y fusiona automáticamente sockets secundarios en la conmutación para que el subproceso de alta prioridad rpd aproveche esto y genere una conexión keepalive más rápida para mantener conexiones TCP en la conmutación.
De forma predeterminada, el BGP no se registra para el servicio automático de generación de keepalive proporcionado por el kernel justo después del evento de conmutación de backup a principal. Para esto, debe habilitar la instrucción en el nivel de jerarquía [edit routing-options] y configurar temporizadores de precisión en BGPnonstop-routing-options. La configuración de temporizadores de precisión en BGP permite que BGP registre todas sus sesiones con el servicio de generación automática de keepalive proporcionado por el kernel. Una vez registrado, el kernel genera automáticamente señales de mantenimiento utilizando sus temporizadores en nombre de BGP para sus sesiones de control justo después del evento de cambio de respaldo a principal. Esto permite la generación de señales de mantenimiento más confiables para sesiones de control con temporizadores muy pequeños durante el evento de conmutación.
Ver también
Interoperabilidad de funcionalidades con BGP Reinicio agraciado de larga duración
Este tema contiene las siguientes secciones que describen el comportamiento de trabajo de diferentes funcionalidades con BGP, reinicio normal de larga duración y las diversas condiciones del sistema:
A partir de Junos OS versión 15.1, Junos OS admite el mecanismo para conservar los detalles de enrutamiento del BGP durante un período más largo de un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio satisfactorio del BGP.
- Limitaciones de las NLRI compatibles
- Modo de reinicio LLGR en NSR
- Capacidad de LLGR a nivel global, de grupo de BGP y de vecino de BGP
Limitaciones de las NLRI compatibles
La configuración de LLGR y la negociación de capacidad son compatibles con las siguientes familias de información de accesibilidad de la capa de red (NLRI) del BGP:
-
VPN L2
-
inet etiquetada con unidifusión
-
flujo de inet
-
objetivo de ruta
-
Unidifusión Inet-VPN
-
flujo de inet-vpn
-
Unidifusión de inet6-VPN
La configuración de LLGR y la negociación de capacidades se impiden para las siguientes familias:
-
inet-mvpn
-
inet6-mvpn
-
inet-mdt
En el caso de las familias NLRI para las que se impide la capacidad de LLGR, indica que se rechaza un intento de confirmar una configuración que incluya una configuración de LLGR para estas familias y que dicha configuración no se guarda. Los NLRI asociados con estas familias no se incluyen en un anuncio de capacidades de LLGR y no se tienen en cuenta en un anuncio de capacidades de LLGR recibido.
La negociación de la configuración y la capacidad de LLGR están permitidas, pero ocultas, para otras familias.
Modo de reinicio LLGR en NSR
Cuando NSR y LLGR se configuran juntos, el enrutador negocia la capacidad de LLGR de la manera habitual y regular, incluido un tiempo obsoleto de larga duración para activar el modo de receptor LLGR en sus pares. Sin embargo, la funcionalidad completa del reiniciador de LLGR (retrasar la transmisión de los marcadores de fin de RIB hasta que se reciban EoR de todos los pares) no funciona con NSR. Durante un reinicio completo del sistema (ambos motores de enrutamiento), el daemon de protocolo de enrutamiento (rpd) no espera a que haya EoR de otros pares antes de enviar su propio EoR. Transmite el EoR tan pronto como ha transmitido el contenido actual de RIB. Esta condición puede causar interrupciones transitorias cuando la red vuelve a converger. NSR se considera adecuado para manejar todos los escenarios de reinicio del motor de enrutamiento único. La restricción del modo de reinicio solo afecta a los casos en los que ambos motores de enrutamiento (o ambas copias de rpd) se reinician simultáneamente. La configuración normal del modo de reinicio no está habilitada con NSR.
La configuración normal del modo de reinicio agraciado sigue sin ser compatible con NSR.
Capacidad de LLGR a nivel global, de grupo de BGP y de vecino de BGP
El modo de receptor de reinicio elegante de larga duración está habilitado de forma predeterminada, a menos que el modo de receptor de reinicio normal esté deshabilitado. Para habilitar la capacidad de reinicio agraciado de larga duración (LLGR) del BGP, incluya la long-lived receiver enable instrucción en el nivel de [edit protocols bgp graceful-restart] jerarquía. Además de habilitar el LLGR del BGP a nivel global o a nivel de todo el sistema, también puede incluir la instrucción receiver enable de larga duración en el nivel de jerarquía [edit protocols bgp group group-name graceful- restart] para configurar LLGR para un grupo de BGP determinado y en el nivel de [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] jerarquía para configurar LLGR para un vecino de BGP determinado. Para deshabilitar el mecanismo LLGR del BGP, incluya la long-lived receiver disable opción , o [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart][edit protocols bgp group-group-name neighbor neighbor-address graceful-restart] nivel de jerarquía. Deshabilitar LLGR desactiva todas las capacidades de LLGR (tanto en modo receptor como en modo de reinicio) para todas las familias de NLRI. Esta propiedad la heredan los grupos de la configuración global y los vecinos de la configuración de grupo.
Ver también
Supervisión y administración del BGP Reinicio agraciado de larga duración
En este tema se describen los comandos operativos y su importancia para permitirle analizar y ver los parámetros relacionados con el reinicio satisfactorio de larga duración del BGP. Puede analizar los contadores estadísticos y las métricas relacionadas con cualquier pérdida de tráfico y tomar las medidas correctivas adecuadas. Los campos que se muestran en el resultado de los comandos show ayudan a diagnosticar y depurar problemas de rendimiento de red y eficiencia en el manejo del tráfico.
Esto clear bgp neighbor neighbor-address stale-routes causa que las rutas obsoletas que se mantienen actualmente para el vecino especificado debido a las operaciones del modo de receptor de reinicio agraciado (GR) o reinicio agraciado de larga duración (LLGR). El clear bgp neighbor neighbor-address gracefully comando es el mismo que clear bgp neighbor hard (el valor predeterminado para clear bgp neighbor), pero no utiliza el nuevo subcódigo de restablecimiento completo en los mensajes Notify y Cease que se envían. Esto permite que el vecino entre en modo auxiliar GR o LLGR, si se negocia. La sesión sigue borrada en este enrutador y este enrutador no entra en modo auxiliar GR o LLGR.
Hay un comando oculto clear disponible, agregado para la capacidad de reinicio elegante de larga duración del BGP con fines de depuración:
clear bgp neighbor neighbor-address socket.
Este comando interrumpe la conexión TCP para una sesión de emparejamiento establecida. Esta es la única implicación directa del comando y todas las demás implicaciones son efectos secundarios de la ruptura de la conexión. El efecto resultante es que (a menos que se hayan deshabilitado las extensiones de notificación de GR) ambos lados de la conexión entrarán en modo auxiliar GR o LLGR, si se negocia, y se restablecerá la conexión TCP.
El resultado del show bgp neighbor comando se mejora para mostrar la siguiente información adicional:
-
La opción de reinicio elegante de larga duración
-
Los parámetros LLGR que negoció el par
-
Los parámetros LLGR que negoció el enrutador de reinicio
-
Las horas se muestran con el formato %#0T del demonio de protocolo de enrutamiento (rpd):
<weeks>w<days>d <hours>:<minutes>:<seconds>Se omiten cero elementos iniciales, por ejemplo, un valor inferior a una semana no incluye las semanas.
Si el reinicio normal de larga duración está completamente deshabilitado para un vecino, se muestra lo siguiente:
user@router> show bgp neighbor
Peer: 10.6.128.225+45824 AS 100 Local: 10.255.255.14+44542 AS 100
Type: Internal State: Established Flags: <Sync>
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress AddressFamily Rib-group Refresh>
Options: <LLGRHelperDisabled> {The LLGRHelperDisabled value for the Options field denotes that long-lived BGP graceful restart is completely disabled for a neighbor}
Si un vecino no admite LLGR por completo, se muestra lo siguiente:
user@router> show bgp neighbor
...
Peer does not support LLGR Restarter or Receiver functionality {BGP neighor or peer does not support long-lived BGP graceful restart restarter or receiver
functionality}
Mientras el modo de receptor LLGR está activo (un par que negoció LLGR se ha desconectado y aún no se ha vuelto a conectar), el resultado del show bgp neighbor comando muestra la cantidad de tiempo que queda hasta que expire el LLGR, el tiempo restante en el temporizador obsoleto de GR y los detalles de RIB:
user@router> show bgp neighbor
Peer: 10.4.12.11 AS 100 Local: 10.6.128.225 AS 100
Type: Internal State: Active Flags: <>
Last State: Idle Last Event: Start
Last Error: None
Export: [ foo ]
Options: <Preference LocalAddress Refresh GracefulRestart>
Options: <LLGR>
Local Address: 10.6.128.225 Holdtime: 90 Preference: 170
Number of flaps: 3
Last flap event: Restart
Error: 'Cease' Sent: 0 Recv: 1
Time until long-lived stale routes deleted: inet-vpn-unicast 10:00:22 route-target 10:00:22
Table bgp.l3vpn.0
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not advertising
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Table foo.inet.0 Bit: 30000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Cuando el modo de receptor de reinicio correcto del BGP está activo para un vecino, se muestra información adicional en la salida del show bgp neighbor comando. Estos detalles incluyen la lista de NLRI para los que se retienen las rutas obsoletas (NLRI estamos reteniendo rutas obsoletas para el campo), el tiempo restante en el temporizador de reinicio (tiempo hasta que las rutas obsoletas se eliminan o se convierten en un campo obsoleto de larga duración), el tiempo restante en el temporizador obsoleto (se asume el tiempo hasta el final de la costilla para las rutas obsoletas) y los detalles de RIB. La hora se muestra en formato de hora universal coordinada (UTC) (AAAA-MM-DD-HH:MM:SS). Tenga en cuenta que la pantalla del temporizador obsoleto ('Se asume el final de la costilla') también está presente cuando una sesión está activa, pero el vecino aún no ha enviado todas las indicaciones del final de la costilla.
Cuando el modo auxiliar de reinicio normal o LLGR está activo, el comando muestra la información de RIB show bgp summary . Si se establece una sesión de BGP en el dispositivo de enrutamiento principal, el campo muestra la cantidad de rutas activas, recibidas, aceptadas y amortiguadas que se reciben de un vecino y aparecen en las tablas de enrutamiento inet.0 (principal) e inet.2 (multidifusión). Por ejemplo, 8/10/10/2 y 2/4/4/0 indican lo siguiente:
-
En la tabla de enrutamiento inet.0 aparecen 8 rutas activas, 10 rutas recibidas, 10 rutas aceptadas y 2 rutas amortiguadas de un par BGP.
-
2 rutas activas, 4 rutas recibidas, 4 rutas aceptadas y ninguna ruta amortiguada de un par BGP aparecen en la tabla de enrutamiento inet.2.
El show route detail comando (con y sin la receive-protocol bgp opción) se ha mejorado para identificar las rutas que se mantienen en el estado obsoleto de larga duración. La LongLivedStale marca indica que este enrutador marcó la ruta como LLGR-obsoleta, como parte de la operación del modo de receptor LLGR. El LongLivedStaleImport indicador indica que la ruta se marcó como LLGR-obsoleta cuando se recibió de un par o mediante una política de importación. Se pueden mostrar una o ambas banderas para una ruta. Ninguna de estas banderas se mostrará al mismo tiempo que la bandera Stale (GR rancia ordinaria). Cuando se anula la preferencia de una ruta porque está obsoleta de larga duración, el campo Motivo inactivo de la salida del comando mostrar detalles de ruta muestra LLGR obsoleto. El nuevo motivo de inactividad obsoleto de LLGR encaja en la jerarquía de selección de rutas entre Preferencia y Preferencia local.
user@router> show route receive-protocol bgp 10.4.12.11 detail
bgp.l2vpn.0: 38 destinations, 39 routes (37 active, 0 holddown, 1 hidden)
* 1.1.1.4:100:1.1.1.4/96 AD (1 entry, 1 announced)
Accepted LongLivedStale LongLivedStaleImport
Nexthop: 10.4.12.11
Localpref: 100
AS path: I
Según el Centro de asistencia técnica de Juniper (JTAC), un comando útil para ayudar a solucionar problemas relacionados con el reinicio satisfactorio de larga duración del BGP es el show route table bgp.l2vpn.0 detail hidden comando. El resultado del comando le ayuda a detectar si las rutas del BGP siguen existiendo después de que la sesión del BGP haya finalizado. El uso de esta hidden opción le permite ver las rutas durante y después de un incidente, y descubrir información que explica por qué las rutas están ocultas. Otras pistas que lo ayudarán a solucionar este escenario incluyen la aparición de entradas de registro de BGP obsoletas (como bgp_mark_route_stale) y rutas ocultas que aparecen en la salida del show bgp summary comando.
Ver también
Aumento de la duración de la conservación de rutas de BGP en pares de reinicio lento mediante BGP Reinicio satisfactorio de larga duración
Junos OS admite el mecanismo para conservar los detalles de enrutamiento del BGP durante un período más largo de un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio satisfactorio del BGP.
El modo de receptor de reinicio elegante de larga duración está habilitado de forma predeterminada, a menos que el modo de receptor de reinicio normal esté deshabilitado. Para habilitar la capacidad de reinicio agraciado de larga duración (LLGR) del BGP, incluya la long-lived receiver enable instrucción en el nivel de [edit protocols bgp graceful-restart] jerarquía. Además de habilitar el LLGR del BGP a nivel global o a nivel de todo el sistema, también puede incluir la instrucción receiver enable de larga duración en el nivel de jerarquía [edit protocols bgp group group-name graceful-restart] para configurar LLGR para un grupo de BGP determinado y en el nivel de [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] jerarquía para configurar LLGR para un vecino de BGP determinado. Para deshabilitar el mecanismo LLGR del BGP, incluya la long-lived receiver disable opción , o [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart][edit protocols bgp group-group-name neighbor neighbor-address graceful-restart] nivel de jerarquía. Deshabilitar LLGR desactiva todas las capacidades de LLGR (tanto en modo receptor como en modo de reinicio) para todas las familias de NLRI. Esta propiedad la heredan los grupos de la configuración global y los vecinos de la configuración de grupo.
Los vecinos del BGP se pueden configurar en los siguientes niveles de jerarquía:
-
[edit protocols bgp group group-name]: sistema lógico predeterminado e instancia de enrutamiento predeterminada. -
[edit routing-instances instance-name protocols bgp group group-name]: sistema lógico predeterminado con una instancia de enrutamiento especificada. -
[edit logical-systems logical-system-name protocols bgp group group-name]: sistema lógico configurado e instancia de enrutamiento predeterminada. -
[edit logical-systems logical-system-name routing-instances instance-name protocols bgp group group-name]: sistema lógico configurado con una instancia de enrutamiento especificada.
Anula long-lived receiver enable una opción de desactivación heredada de un nivel superior de la configuración. No habilita el modo de reinicio agraciado de larga duración para todas las familias: el modo de reinicio debe configurarse explícitamente para cada familia.
Para permitir que las rutas obsoletas de LLGR se anuncien a vecinos que no anuncian la capacidad de LLGR, incluya la advertise-to-non-llgr-neighbor instrucción en el nivel , o [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] de [edit protocols bgp group group-name graceful-restart long-lived][edit protocols bgp graceful-restart long-lived]jerarquía. Esta configuración se aplica tanto a las rutas marcadas como LLGR-stale por este enrutador como a las rutas LLGR-stale recibidas de los vecinos. Idealmente, todos los enrutadores en un sistema autónomo admiten la especificación de borrador de GTI-I antes de que se habilitara. Sin embargo, para facilitar la implementación incremental, es posible que sea necesario anunciar las rutas obsoletas a los vecinos que no hayan anunciado la capacidad de reinicio normal de larga duración en las siguientes condiciones: Los vecinos deben ser vecinos internos (IBGP o Confederación). La comunidad NO_EXPORT debe estar apegada a las rutas obsoletas. Las rutas obsoletas deben tener su atributo LOCAL_PREF establecido en cero. Si se usa esta técnica para la implementación parcial, debe establecer LOCAL_PREF en cero para todas las rutas LLGR en todo el sistema autónomo. Esta configuración compensa una pequeña reducción en la flexibilidad (es posible que no se conserve el orden entre rutas LLGR competidoras) por la consistencia entre los enrutadores que admiten y no admiten esta especificación. Dado que la coherencia de la selección de rutas puede ser importante para evitar bucles de reenvío, precede esta última consideración de los enrutadores que no admiten esta especificación.
Para evitar que la comunidad de BGP sin exportación se agregue automáticamente a las rutas anunciadas a vecinos de BGP externos (que se supone que son enrutadores CE), incluya la omit- no-export instrucción en el nivel , [edit protocols bgp graceful-restart long-lived][edit protocols bgp group group-name graceful-restart long-lived]o [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] de jerarquía. En los despliegues de VPN, por ejemplo, BGP se suele usar como protocolo PE-CE. Podría ser una necesidad práctica en tales implementaciones dar cabida a la interoperación con CE que no se pueden actualizar fácilmente para admitir especificaciones como esta. Este requisito causa un problema, a la vez que garantiza que la información de enrutamiento "obsoleta" no se filtre más allá del perímetro de los enrutadores que admiten estos procedimientos en los que uno o más enrutadores de IBGP no están actualizados. En el caso de VPN PE-CE, el protocolo en uso es EBGP y se utiliza el LOCAL_PREF, un atributo de ruta solo para IBGP. La principal motivación para restringir la propagación de información de enrutamiento "obsoleta" es la razón para evitar que se propague sin límite una vez que salga del límite de la confederación del BGP. Las implementaciones de VPN suelen estar restringidas topológicamente, lo que elimina esta preocupación. Por este motivo, una implementación puede anunciar rutas obsoletas a través de una sesión PE-CE, cuando se configura explícitamente. En tal escenario, la implementación debe adjuntar la comunidad de NO_EXPORT a las rutas en cuestión de forma predeterminada, como una protección adicional contra rutas obsoletas que se propagan sin límite. El apego de la comunidad NO_EXPORT puede desactivarse explícitamente para dar cabida a casos excepcionales. Puede ser necesario anunciar las rutas obsoletas a un CE en algunas implementaciones de VPN, incluso si el CE no admite esta especificación. En ese caso, si configura los enrutadores de PE para anunciar dichas rutas, debe notificar al operador del CE que recibe las rutas y el CE debe configurarse para anular la preferencia de las rutas. Las implementaciones típicas de BGP realizan esta operación haciendo coincidir en la comunidad de LLGR_STALE y estableciendo el LOCAL_PREF para hacer coincidir las rutas en cero.
Cuando el modo de receptor LLGR está habilitado o deshabilitado, la sesión se restablece. Este comportamiento permite enviar el nuevo valor de capacidad al vecino. Cuando la opción está habilitada o deshabilitada, la advertise-to-non-llgr-neighbor política de exportación se vuelve a evaluar y es posible que se anuncien o retiren rutas obsoletas de LLGR. Cuando se agrega o elimina la omit-no-export opción, la sesión se restablece. Este resto de sesión permite que las rutas obsoletas de LLGR se vuelvan a anunciar con o sin la comunidad de no exportación (que se agrega fuera de la política de exportación).
Para habilitar la capacidad de reinicio satisfactorio de larga duración del BGP a nivel del sistema o global y configurar sus propiedades:
[edit]
protocols {
bgp {
graceful-restart {
long-lived {
receiver {
enable:
disable;
}
advertise-to-non-llgr-neighbor {
omit-no-export;
}
}
}
}
}
Para habilitar la capacidad de reinicio satisfactorio de larga duración del BGP en el nivel de grupo BGP y configurar sus propiedades:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
long-lived {
receiver {
enable:
disable;
}
advertise-to-non-llgr-neighbor {
omit-no-export;
}
}
}
}
}
}
Para habilitar la capacidad de reinicio normal de larga duración del BGP a nivel de vecino o grupo par y configurar sus propiedades:
[edit]
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
long-lived {
receiver {
enable:
disable;
}
advertise-to-non-llgr-neighbor {
omit-no-export;
}
}
}
}
}
}
}
Ver también
Configuración de comunidades de reinicio agraciado de larga duración del BGP en políticas de enrutamiento
Junos OS admite el mecanismo para conservar los detalles de enrutamiento del BGP durante un período más largo de un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio satisfactorio del BGP.
Se introducen dos nuevas comunidades conocidas. Estas nuevas comunidades de BGP se pueden utilizar en cualquiera de los niveles de jerarquía de configuración como otras comunidades simbólicas bien conocidas (como no-advertise, no-export y no-export-subconfed) en el atributo community de definiciones de rutas estáticas o en una definición de comunidad de opciones de política. Las dos nuevas comunidades son las siguientes:
-
llgr-stale: agrega una comunidad a una ruta obsoleta de larga duración cuando se vuelve a anunciar. -
no-llgr: marca las rutas que un anunciador BGP no desea que LLGR conserve. La función Mensaje de notificación no tiene ningún parámetro de configuración asociado.
Puede incluir las opciones and no-llgr con la instrucción para asociar la información de la llgr-stale community name members comunidad del BGP con una ruta estática, agregada o generada en los siguientes niveles jerárquicos:
[edit dynamic policy-options], [edit logical-systems logical-system-name policy-options], [edit policy-options]
Para configurar las comunidades de reinicio agraciado de larga duración del BGP para su uso en una condición de coincidencia de política de enrutamiento:
[edit policy-options]
community name {
members [ llgr-stale | nollgr];
}
La configuración de LLGR no requiere que también se configure el reinicio correcto del BGP. Los valores para las comunidades conocidas llgr-stale y no-llgr son 0xFFFF0006 y 0xFFFF0007 respectivamente. Los privilegios son los mismos que para los protocolos bgp. La sección long-lifed-graceful-restart solo está visible para las familias l2vpn, inet labeled-unidifusión, inet flow y route-target. Está prohibido para inet-mvpn, inet6-mvpn e inet-mdt. Está oculto para otras familias.
Junos OS también proporciona soporte para configurar una política de exportación de BGP que coincida con el estado de una ruta para el reinicio satisfactorio de larga duración del BGP. Puede asociar la comunidad que definió anteriormente y una lista de prefijos de dirección en una política de enrutamiento para aceptar o rechazar selectivamente las rutas para un reinicio satisfactorio de larga duración para los prefijos especificados, como se indica a continuación:
policy-options {
prefix-list name;
community name members [ llgr-stale | nollgr];
policy-statement name{
from {
prefix-list name;
community name;
}
then {
(accept | reject)
}
}
}
Se agregan dos instrucciones de configuración ocultas bajo el nivel de jerarquía ] para la [edit protocols bgp graceful-restartconfiguración global, a nivel de grupo y a nivel de grupo vecino.
La disable-notification-flag instrucción en el nivel , o [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] jerárquico [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart]deshabilita la transmisión de la marca N en la negociación de capacidad de reinicio normal. La disable-notification-extensions instrucción en el nivel , o [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] de [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart]jerarquía también deshabilita la transmisión de la marca N en la negociación de la capacidad de reinicio normal, pero, además, deshabilita las nuevas reglas para invocar el modo de receptor de reinicio normal como se especifica en el borrador de notificación bgp-gr-notification de GTI-I y deshabilita la transmisión del subcódigo restablecimiento completo. El subcódigo de restablecimiento completo continúa observándose cuando se recibe en un mensaje de notificación o finalización.
Para deshabilitar la transmisión de N indicadores y deshabilitar las reglas para activar el reinicio correcto a nivel global o en todo el sistema:
[edit]
protocols {
bgp {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
Para deshabilitar la transmisión de N indicadores y deshabilitar las reglas para activar el reinicio correcto a nivel de grupo:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
}
Para deshabilitar la transmisión de N indicadores y deshabilitar las reglas para activar el reinicio correcto a nivel de vecino o par:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
}
Ver también
Configuración de la negociación del modo de reinicio agraciado de larga duración para una familia de direcciones específica en sistemas lógicos e instancias de enrutamiento
Junos OS admite el mecanismo para conservar los detalles de enrutamiento del BGP durante un período más largo de un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio satisfactorio del BGP.
También puede configurar el mecanismo de negociación del modo de reinicio elegante de larga duración del BGP para una familia de direcciones determinada en lugar de configurar esta capacidad para todas las familias de direcciones en una instancia de enrutamiento, sistema lógico o sistema. Para habilitar LLGR de BGP para una familia de direcciones específica, incluya la graceful-restart long-lived restarter stale-time interval instrucción en uno de los siguientes niveles de jerarquía.
Cada tabla de enrutamiento se identifica mediante el indicador de familia de protocolos o de familia de direcciones (AFI) y un identificador de familia de direcciones (SAFI) posterior. El parámetro AFI puede ser uno de los (l2vpn | inet | route-target) protocolos y el parámetro SAFI puede ser cualquiera de los protocolos para la (flow | labeled-unicast) familia inet y uno de los protocolos para la (auto-discovery-mspw | auto-discovery-only | signaling) familia L2VPN.
La configuración de LLGR no requiere que también se configure el reinicio correcto del BGP. La sección long-lifed-graceful-restart solo está visible para las familias l2vpn, inet labeled-unidifusión, inet flow y route-target. Está prohibido para inet-mvpn, inet6-mvpn e inet-mdt. Está oculto para otras familias.
[edit logical-systems logical-system-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)] [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)],
Las estrofas de la sección de configuración de reinicio agraciado por familia y larga duración habilitan la negociación del modo de reinicio LLGR para BGP globalmente, o para un grupo o vecino. Los valores los heredan los grupos de la configuración global y los vecinos de la configuración de grupo. El atributo disable se utiliza para anular la configuración heredada de un nivel superior. No deshabilita el modo de receptor LLGR; debe deshabilitar el modo de receptor LLGR explícitamente para todas las familias según sea necesario. Se puede usar un atributo oculto enable para anular un atributo de desactivación heredado. La configuración del reiniciador de larga duración gracefulful-restart en el nivel del vecino (cuando no está configurado en el nivel del grupo contenedor o globalmente) hace que se divida un grupo interno. Cuando el reiniciador LLGR está habilitado o deshabilitado para una familia o se cambia el tiempo obsoleto, la sesión se restablece para que la nueva capacidad se pueda enviar al vecino.
El rango de valores para el tiempo obsoleto es de 1 a 16777215 (2^24 – 1) segundos. El valor es un entero simple que da el número de segundos de forma predeterminada, pero también se puede especificar usando la siguiente notación:
[<semanas>p][<días>d][<horas>h][<minutos>m][<segundos>s] Por ejemplo, puede especificar 27 días como 27d, 648h, 38880m o 2332800s. 90 minutos se pueden configurar como 1h30m, 90m o 5400s. El número especificado de días se multiplica por 86400, el número de horas por 3600 y el número de minutos por 60; estos se suman a los segundos para obtener el total. Se permite un formato combinado de días y horas, en diferentes unidades de período de tiempo, como 1d36h, siempre que el total especificado no exceda el tiempo máximo obsoleto.
Además, las horas también se pueden configurar con la siguiente notación: <horas>:<minutos>:<segundos> Por ejemplo, 12:00:00 especifica doce horas. Las horas y los minutos son opcionales.
Las dos notaciones se pueden combinar, por ejemplo, 2w1d 12:00:02 especifica dos semanas, un día, doce horas y dos segundos (1339202 segundos). (Tenga en cuenta que la CLI requiere comillas dobles alrededor de un valor como este con espacios). Expresado en esta notación, el tiempo máximo de obsolescencia es 27w5d 04:20:15 (27 semanas, 5 días, 4 horas, 20 minutos y 15 segundos). Aunque el comando show configuration muestra los valores realmente configurados, cuando los temporizadores asociados se muestran en comandos show en tiempo de ejecución como show bgp neighbor, los valores se normalizan, como 1d36h convirtiéndose en 2d 12:00:00. Las reglas completas para mostrar tiempos de LLGR normalizados dependen de la configuración del clear bgp neighbor neighbor-address gracefully comando.
Para configurar las características de reinicio normal de larga duración del BGP por familia de direcciones y por familia de direcciones subsiguientes a nivel global para un sistema lógico o una instancia de enrutamiento:
Configuración del BGP Reinicio correcto de larga duración por familia de direcciones a nivel global para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
Configuración del BGP Reinicio agraciado de larga duración por familia de direcciones a nivel global para instancias de enrutamiento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
Para configurar el BGP, las características de reinicio normal de larga duración por familia de direcciones y por familia de direcciones subsiguientes en el nivel de grupo BGP para un sistema lógico o una instancia de enrutamiento:
Configuración del reinicio normal de larga duración del BGP por familia de direcciones en el nivel de grupo del BGP para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
Configuración del reinicio normal de larga duración del BGP por familia de direcciones en el nivel de grupo del BGP para instancias de enrutamiento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
Para configurar las características de reinicio normal de larga duración del BGP por familia de direcciones y por familia de direcciones subsiguientes en el nivel de grupo de vecinos del BGP para un sistema lógico o una instancia de enrutamiento:
Configuración del reinicio satisfactorio de larga duración del BGP por familia de direcciones en el nivel de grupo de vecinos del BGP para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
}
Configuración del reinicio agraciado de larga duración del BGP por familia de direcciones en el nivel de grupo de vecinos del BGP para instancias de enrutamiento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
}
Ver también
Informar al par o enrutador auxiliar del BGP sobre la conservación de rutas mediante la configuración del bit de estado de reenvío para todas las familias de direcciones y para una familia de direcciones específica
Junos OS admite el mecanismo para conservar los detalles de enrutamiento del BGP durante un período más largo de un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio satisfactorio del BGP.
Después de que una sesión de BGP deja de funcionar y antes de que se restablezca la sesión, las rutas obsoletas se pueden conservar durante un máximo de dos períodos consecutivos, controlados por los parámetros de tiempo de reinicio y tiempo obsoleto de larga duración, respectivamente. Durante el primer período, se impiden modificaciones de enrutamiento, pero con un potencial filtrado de tráfico de ruta nula. Durante el segundo período, es posible que se reduzca el filtrado de ruta nula del tráfico, pero los cambios de enrutamiento son visibles en toda la red. En su entorno de red, la configuración de los parámetros relevantes para una aplicación en particular debe considerar las compensaciones, la dinámica de la red y los posibles escenarios de falla. Si es necesario, el primer punto se puede omitir mediante la configuración local o estableciendo el tiempo de reinicio en la capacidad de reinicio elegante en cero, sin enumerar los indicadores de familia de direcciones (AFI) y los identificadores de familia de direcciones posteriores (SAFI) en esa capacidad.
El ajuste del bit F (y el bit «Estado de reenvío» de la capacidad GR que lo acompaña) depende en parte de consideraciones de despliegue. El bit F puede interpretarse para indicar que el enrutador auxiliar necesita vaciar las rutas asociadas (si el bit se deja libre). Un escenario importante en el que se usa LLGR es para rutas que son más similares a la configuración que al enrutamiento tradicional (reenvío salto a salto en lugar de enrutamiento basado en túnel). Para tales rutas, podría ser útil establecer siempre el bit F, independientemente de otras consideraciones. De manera similar, para entidades de solo plano de control, como reflectores de ruta dedicados, que no participan en el plano de reenvío, se prefiere que siempre se establezca el bit F. En general, la directriz que se debe adoptar es que si se puede esperar razonablemente que la pérdida de estado en el enrutador de reinicio provoque un bucle de reenvío o una ruta nula, el bit F debe establecerse con criterio, dependiendo de si se ha conservado el estado. Puede determinar si es necesario establecer o no el bit F, en función de sus necesidades de implementación y de los ajustes configurados. Puede ser necesario anunciar las rutas obsoletas a un CE en algunas implementaciones de VPN, incluso si el CE no admite esta especificación. En tal escenario, el operador de red que configura su PE para anunciar dichas rutas debe notificar al operador que el CE recibe las rutas, y el CE debe configurarse para eliminar la preferencia de las rutas. Por lo general, las implementaciones de BGP realizan este comportamiento haciendo coincidir en la comunidad de LLGR_STALE y estableciendo el LOCAL_PREF para hacer coincidir las rutas en cero.
Puede especificar el bit Estado de reenvío, que es una opción de configuración del BGP que se puede definir a nivel global, de grupo y de vecino para cualquier instancia de enrutamiento o sistema lógico. Para especificar el bit de estado de reenvío en el nivel global, de grupo de BGP o de vecino de BGP, incluya la forwarding-state-bit (as-rr-client | from-fib) instrucción en el nivel , o [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart] de [edit protocols bgp graceful-restart][edit protocols bgp group-group-name graceful-restart]jerarquía. El atributo forwarding-state-bit controla cómo se establece el bit de estado de reenvío tanto en los anuncios de capacidad de reinicio normal como en los de reinicio normal de larga duración. De forma predeterminada, el valor depende de si el vecino es un cliente de reflector de ruta. Si el vecino no es un cliente de reflector de ruta, el valor se establece según el estado de la FIB asociada de conformidad con RFC 4724. Si el vecino es un cliente de reflector de ruta, el valor se establece en 1 para todas las familias excepto inet unidifusión e inet6 unidifusión, que utilizan el estado de la FIB asociada. La as-rr-client opción establece el comportamiento de todas las familias de direcciones para que sea el mismo que la funcionalidad de un cliente de reflector de ruta. La from-fib opción fuerza el comportamiento de todas las familias de direcciones para que sea como lo sería para un cliente que no sea reflector de ruta.
Para configurar la negociación de indicadores de estado de reenvío a nivel global:
[edit]
protocols {
bgp {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
Para configurar la negociación de indicadores de estado de reenvío a nivel de grupo:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
}
Para configurar la negociación de indicadores de estado de reenvío a nivel de vecino o grupo par:
[edit]
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
}
}
Además de la configuración global para el bit de estado de reenvío, se puede especificar el comportamiento del bit de estado de reenvío para familias individuales. El cambio de la configuración de bits de estado de reenvío no tiene ningún efecto en ninguna sesión existente. Para especificar el bit de estado de reenvío para una familia de direcciones determinada, incluya la forwarding-state-bit (set | from-fib) instrucción en el nivel , [edit protocols bgp graceful-restart family address-family subsequent-address-family][edit protocols bgp group-group-name graceful-restart family address-family subsequent-address-family]o [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart family address-family subsequent-address-family] de jerarquía en un sistema lógico y una instancia de enrutamiento. Se agregan opciones de configuración de BGP por familia para controlar el bit de estado de reenvío en los anuncios de capacidad de reinicio normal y reinicio normal de larga duración. Se pueden especificar para el sistema lógico predeterminado o para un sistema lógico específico, y para la instancia de enrutamiento principal o una instancia de enrutamiento específica. El per-family forwarding-state-bit atributo anula las reglas predeterminadas o la configuración global para establecer el bit Estado de reenvío. La set opción obliga a que el bit de estado de reenvío se establezca en 1. La from-fib opción hace que el valor se establezca según el estado de la FIB asociada. El cambio de la configuración de bit de estado de reenvío por familia no tiene ningún efecto en ninguna sesión existente.
A continuación, se muestran los niveles de jerarquía de configuración completos en los que puede incluir la forwarding-state-bit (set | from-fib) instrucción para configurar el bit de estado de reenvío por familia de direcciones:
[edit logical-systems logical-system-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)] [edit routing-instances routing-instance-name protocols bgp family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name family inet (labeled-unicast | unicast | multicast)], [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family inet (labeled-unicast | unicast | multicast)],
Para configurar el bit de estado de reenvío para el BGP, el reinicio normal de larga duración por familia de direcciones y por familia de direcciones subsiguientes a nivel global para un sistema lógico o una instancia de enrutamiento:
Configuración del bit de estado de reenvío por familia de direcciones a nivel global para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
Configuración del bit de estado de reenvío por familia de direcciones a nivel global para instancias de enrutamiento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
Para configurar el bit de estado de reenvío para el BGP, el reinicio normal de larga duración, por familia de direcciones y por familia de direcciones subsiguientes en el nivel de grupo del BGP para un sistema lógico o una instancia de enrutamiento:
Configuración del bit de estado de reenvío por familia de direcciones en el nivel de grupo BGP para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
Configuración del bit de estado de reenvío por familia de direcciones en el nivel de grupo del BGP para instancias de enrutamiento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
Para configurar el bit de estado de reenvío para el BGP, el reinicio normal de larga duración, por familia de direcciones y por familia de direcciones subsiguientes en el nivel de grupo de vecinos del BGP para un sistema lógico o una instancia de enrutamiento:
Configuración del bit de estado de reenvío por familia de direcciones en el nivel de grupo de vecinos del BGP para sistemas lógicos
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
}
Configuración del bit de estado de reenvío por familia de direcciones en el nivel de grupo de vecinos del BGP para instancias de enrutamiento
[edit routing-instances routing-instance-name protocols bgp family address-family subsequent-address-family
protocols {
bgp {
group group-name {
neighbor neighbor-address {
graceful-restart {
forwarding-state-bit (set | from-fib);
}
}
}
}
}
Ver también
Ejemplo: Conservación de detalles de ruta para pares BGP lentos y latentes mediante el reinicio satisfactorio de larga duración del BGP
Junos OS admite el mecanismo para conservar los detalles de enrutamiento del BGP durante un período más largo de un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio satisfactorio del BGP.
Históricamente, los protocolos de enrutamiento y BGP, en particular, se han diseñado con un enfoque en la corrección, donde un aspecto significativo de la "corrección" es que el estado de reenvío de cada elemento de la red converja hacia el estado actual de la red lo más rápido posible. Por esta razón, el protocolo fue diseñado para eliminar el estado anunciado por los enrutadores que se caían (desde la perspectiva de BGP) lo antes posible. Con el uso del reinicio agraciado del BGP definido en RFC 4724, la funcionalidad de convergencia rápida ha sido un intento de eliminar rápidamente el estado "obsoleto" de la red.
El reinicio agraciado de larga duración (LLGR) del BGP permite a un operador de red elegir mantener la información de enrutamiento obsoleta de un par BGP con errores durante mucho más tiempo que la instalación de reinicio agraciado del BGP existente. Esta funcionalidad para mantener las rutas del BGP durante un período de tiempo más largo está de acuerdo con el borrador de GTI-I, Soporte para un reinicio satisfactorio de BGP de larga duración—draft-uttaro-idr-bgp-persistence-03. Según este borrador, el reinicio agraciado de larga duración (LLGR) debe configurarse explícitamente según NLRI e incluye disposiciones para evitar la propagación de información obsoleta a otros pares que no reconocen ni validan LLGR.
En este ejemplo, se describe cómo configurar la funcionalidad de reinicio satisfactorio de larga duración del BGP en enrutadores de la serie MX y se incluyen las siguientes secciones:
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Un enrutador de la serie MX con una MPC.
-
Junos OS versión 15.1R1 o posterior para enrutadores de la serie MX
Antes de configurar el reinicio satisfactorio de larga duración del BGP, asegúrese de:
-
Configure las interfaces de los dispositivos.
-
Configure BGP.
Descripción general
El reinicio agraciado permite que un dispositivo de enrutamiento que se somete a un reinicio informe a sus vecinos y pares adyacentes de su condición. Durante un reinicio virtuoso, el dispositivo que se reinicia y sus vecinos continúan reenviando paquetes sin interrumpir el rendimiento de la red. Dado que los dispositivos vecinos ayudan en el reinicio (estos vecinos se denominan enrutadores auxiliares), el dispositivo de reinicio puede reanudar rápidamente el funcionamiento completo sin tener que volver a calcular los algoritmos.
El modo de receptor de reinicio elegante de larga duración está habilitado de forma predeterminada, a menos que el modo de receptor de reinicio normal esté deshabilitado. Para habilitar la capacidad de reinicio agraciado de larga duración (LLGR) del BGP, incluya la long-lived receiver enable instrucción en el nivel de [edit protocols bgp graceful-restart] jerarquía. Además de habilitar el LLGR del BGP a nivel global o a nivel de todo el sistema, también puede incluir la instrucción receiver enable de larga duración en el nivel de jerarquía [edit protocols bgp group group-name graceful-restart] para configurar LLGR para un grupo de BGP determinado y en el nivel de [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] jerarquía para configurar LLGR para un vecino de BGP determinado. Para deshabilitar el mecanismo LLGR del BGP, incluya la long-lived receiver disable opción , o [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart][edit protocols bgp group-group-name neighbor neighbor-address graceful-restart] nivel de jerarquía. Deshabilitar LLGR desactiva todas las capacidades de LLGR (tanto en modo receptor como en modo de reinicio) para todas las familias de NLRI. Esta propiedad la heredan los grupos de la configuración global y los vecinos de la configuración de grupo.
Topología
Considere un escenario de ejemplo en el que desea aumentar el período de tiempo durante el cual se mantienen las rutas obsoletas para un par BGP o vecino con la dirección 1.2.3.4. Además de especificar la duración durante la cual se deben conservar las rutas para las sesiones obsoletas y cuando se produce un reinicio correcto de un par, también puede configurar enrutadores BGP de ciertos prefijos de dirección para que no se tengan en cuenta al definir el mecanismo de reinicio satisfactorio de larga duración. Puede definir una lista de prefijos de direcciones IPv4 o IPv6 para utilizarlos en una instrucción de política de enrutamiento y una comunidad de BGP que se incluirá en la política de enrutamiento. Si establece el modificador de acción para rechazar rutas de un prefijo determinado, dichas rutas de BGP no se mantendrán durante el período de tiempo aumentado.
También puede configurar el mecanismo de negociación del modo de reinicio elegante de larga duración del BGP para una familia de direcciones determinada en lugar de configurar esta capacidad para todas las familias de direcciones en una instancia de enrutamiento, sistema lógico o sistema. Para habilitar LLGR de BGP para una familia de direcciones específica, incluya la graceful-restart long-lived restarter stale-time interval instrucción en uno de los siguientes niveles de jerarquía.
Cada tabla de enrutamiento se identifica mediante el indicador de familia de protocolos o de familia de direcciones (AFI) y un identificador de familia de direcciones (SAFI) posterior. El parámetro AFI puede ser uno de los (l2vpn | inet | route-target) protocolos y el parámetro SAFI puede ser cualquiera de los protocolos para la (flow | labeled-unicast) familia inet y uno de los protocolos para la (auto-discovery-mspw | auto-discovery-only | signaling) familia L2VPN.
La configuración de LLGR no requiere que también se configure el reinicio correcto del BGP. La sección long-lifed-graceful-restart solo está visible para las familias l2vpn, inet labeled-unidifusión, inet flow y route-target. Está prohibido para inet-mvpn, inet6-mvpn e inet-mdt. Está oculto para otras familias.
Configuración
- Configuración rápida de CLI
- Configuración de un reinicio elegante de larga duración para el modo de reinicio
- Resultados
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, 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, copie y pegue los comandos en la CLI en el nivel de jerarquía y, luego, ingrese commit desde el [edit] modo de configuración.
Configuración de la lista de prefijos de direcciones, la comunidad de BGP y la política de enrutamiento de BGP
set policy-options prefix-list special 44.44.44.44/32 set policy-options community llgr-community llgr-stale set policy-options policy-statement llgr-import from prefix-list special set policy-options policy-statement llgr-import from community llgr-community set policy-options policy-statement llgr-import then reject
Configuración del grupo BGP, NLRI y reinicio agraciado de larga duración
set protocols bgp group ibgp-group type internal set protocols bgp group ibgp-group import llgr-import set protocols bgp group ibgp-group family inet unicast set protocols bgp group ibgp-group family inet unicast graceful-restart long-lived restarter stale-time 12h
Configuración del grupo de vecinos del BGP
set protocols bgp group ibgp-group neighbor 1.2.3.4
Configuración de un reinicio elegante de larga duración para el modo de reinicio
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración de la Guía del usuario de CLI.
-
Configure la lista de prefijos de dirección, la comunidad de BGP y la condición de coincidencia y el modificador de acción para la política de enrutamiento de BGP.
[edit] user@ host# set policy-options prefix-list special 44.44.44.44/32 user@ host# set policy-options community llgr-community llgr-stale user@ host# set policy-options policy-statement llgr-import from prefix-list special user@ host# set policy-options policy-statement llgr-import from community llgr-community user@ host# set policy-options policy-statement llgr-import then reject
-
Configure el grupo BGP, la familia de direcciones y la funcionalidad de reinicio elegante de larga duración para el modo de reinicio con el tiempo obsoleto para los flujos.
[edit] user@ host# set protocols bgp group ibgp-group type internal user@ host# set protocols bgp group ibgp-group import llgr-import user@ host# set protocols bgp group ibgp-group family inet unicast user@ host# set protocols bgp group ibgp-group family inet unicast graceful-restart long-lived restarter stale-time 12h
-
Configure el grupo de vecinos del BGP.
[edit] user@ host# set protocols bgp group ibgp-group neighbor 1.2.3.4
Resultados
Desde el modo de configuración, ingrese los comandos y show protocols para confirmar la show policy-options configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregirla.
[edit]
user@host# show policy-options
policy-options {
prefix-list special 44.44.44.44/32;
community llgr-community llgr-stale;
policy-statement llgr-import {
from {
prefix-list special;
community llgr-community;
}
then {
reject;
}
}
}
user@host# show protocols
protocols {
bgp {
group ibgp-group {
type internal;
import llgr-import;
family inet unicast {
graceful-restart {
long-lived {
restarter {
stale-time 12h;
}
}
}
}
neighbor 1.2.3.4;
}
}
}
Verificación
Confirme que la configuración funcione correctamente.
Verificar que la capacidad de reinicio agraciado de larga duración esté habilitada
Propósito
Compruebe la capacidad de reinicio normal de larga duración del BGP configurada para el nivel de vecino del BGP
Acción
Mientras el modo de receptor LLGR está activo (un par que negoció LLGR se ha desconectado y aún no se ha vuelto a conectar), el resultado del show bgp neighbor comando muestra la cantidad de tiempo que queda hasta que expire el LLGR, el tiempo restante en el temporizador obsoleto de GR y los detalles de RIB:
user@router> show bgp neighbor
Peer: 10.4.12.11 AS 100 Local: 10.6.128.225 AS 100
Type: Internal State: Active Flags: <>
Last State: Idle Last Event: Start
Last Error: None
Export: [ foo ]
Options: <Preference LocalAddress Refresh GracefulRestart>
Options: <LLGR>
Local Address: 10.6.128.225 Holdtime: 90 Preference: 170
Number of flaps: 3
Last flap event: Restart
Error: 'Cease' Sent: 0 Recv: 1
Time until long-lived stale routes deleted: inet-vpn-unicast 10:00:22 route-target 10:00:22
Table bgp.l3vpn.0
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not advertising
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Table foo.inet.0 Bit: 30000
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Send state: not in sync
Active prefixes: 0
Received prefixes: 7
Accepted prefixes: 7
Suppressed due to damping: 0
Significado
El resultado muestra información sobre los vecinos del BGP.