Descripción del reinicio agraciado para BGP
Comprender la capacidad de reinicio agraciado de BGP de larga duración
Junos OS admite el mecanismo para conservar los detalles del enrutamiento del BGP durante un período más largo desde un par BGP fallido que la duración durante la cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio agraciado del BGP.
Históricamente, los protocolos de enrutamiento y el 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 red converja hacia el estado actual de la red lo antes posible. Por esta razón, el protocolo fue diseñado para eliminar el estado anunciado por los enrutadores que se redujeron (desde una perspectiva del BGP) lo más rápido posible. Mediante el BGP Graceful Restart definido en RFC 4724, la funcionalidad de convergencia rápida ha sido un intento de eliminar rápidamente el estado "rancio" de la red.
Durante un período de tiempo, dos factores contribuyentes han hecho que este método de eliminación rápida de los estados rancios se modifique y potenció. El primero es la adopción generalizada de infraestructuras de reenvío tunelizadas, 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 creciente del BGP como transporte de datos menos estrechamente asociado con el reenvío de paquetes que el caso originalmente. Algunos ejemplos incluyen el uso del BGP para la detección automática (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 elegir conservar los datos del BGP durante un período más largo cuando el plano de control del BGP falla por alguna razón. Aunque las propiedades del BGP Graceful Restart se acercan a este requisito deseado de conservar la información del BGP durante una mayor duración, existen varias lagunas, la más notable en el tiempo máximo para el cual se puede conservar información "obsoleta". El reinicio agraciado impone una limitación de límite superior de 4095 segundos. Junos OS admite una capacidad de BGP llamada 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 de BGP, "LLGR_STALE", para marcar dicha información. Esta información rancia debe ser tratada como la menos preferida, y su anuncio se limita a altavoces BGP que admiten la nueva capacidad.
El reinicio agraciado de larga duración del BGP (LLGR) permite que un operador de red elija mantener la información de enrutamiento rancio desde un par BGP fallido 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 IETF, Soporte para BGP de larga duración graceful Restart—draft-uttaro-idr-bgp-persistencia-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 rancio a otros pares que no reconocen y validan LLGR. LlGR causa los siguientes beneficios y operaciones:
Las rutas desde nodos fallidos se conservan durante un período de tiempo configurado (en el orden de días).
Puede examinar los estados de negociación de LLGR por NLRI mediante los comandos show apropiados.
Puede ver si la LLGR está vigente actualmente para un par y, si es efectiva, el período después del cual caduca.
Las rutas obsoletos conservadas por LLGR se marcan explícitamente en la salida del
show bgp neighborcomando.Las rutas rancios aprendidas de otros vecinos se marcan explícitamente en la
show bgp neighborsalida del comando (usando 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 una conectividad intermitente que puede hacer que se restablezca una conexión antes de que se pueda transmitir todo el RIB, tal error no da como resultado 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 IETF, draft-uttaro-idr-bgp-persistencia-03, para LLGR. Además, se admite compatibilidad con versiones anteriores a la versión 15.1 con funciones existentes de Junos OS, específicamente con reinicio agraciado y enrutamiento sin interrupciones (NSR). Cuando se configura la LLGR, el reinicio agraciado funciona de la manera existente, excepto como se muestra 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 prerrequisito para la LLGR, se implementa la compatibilidad con el borrador de IETF, notification Message support for BGP Graceful Restart—draft-ietf- idr-bgp-gr-notification-01. Este borrador extiende el comportamiento del GR ordinario para permitirle protegerse de interrupciones de las comunicaciones y errores de protocolo.
Consulte también
Descripción de la configuración de período máximo para la generación automática de BGP Keepalives por temporizadores de kernel después de la conmutación
En Junos OS, el enrutamiento activo sin interrupción (NSR) usa la misma infraestructura que el cambio agraciado del motor de enrutamiento (GRES) para conservar la información de interfaz y 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. El NSR es ventajoso en redes en las que los enrutadores (o conmutadores) vecinos no admiten extensiones de protocolo de reinicio agraciado. Como resultado de esta funcionalidad mejorada, NSR es un reemplazo natural para un reinicio agraciado.
La automerja de enrutamiento activo sin interrupciones es uno de los componentes del núcleo de la replicación de sockets. En la conmutación, este componente fusiona los pares de sockets automáticamente desde la copia de seguridad al motor de enrutamiento principal. El cambio NSR de la copia de seguridad a la principal ocurre cuando rpd emite una llamada de fusión para que cada par de socket secundario los combine en un solo socket, lo que podría dar lugar a un retraso. Para evitar este retraso, un módulo de automerge en el kernel desacopla la fusión de socket secundario de rpd y fusiona automáticamente los sockets secundarios en la conmutación, de modo que el subproceso de alta prioridad rpd aproveche esto y genere un mantenimiento más rápido para mantener las conexiones TCP en la conmutación.
De forma predeterminada, el BGP no se registra en el servicio de generación de keepalive automático que proporciona el kernel justo después del evento de conmutación de la copia de seguridad a la principal. Para esto, debe habilitar la instrucción en el nonstop-routing-options nivel de jerarquía [edit routing-options] y configurar temporizadores de precisión en BGP. La configuración de temporizadores de precisión en BGP permite que el 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 keepalives usando sus temporizadores en nombre del BGP para sus sesiones de control justo después del evento de conmutación de copia de seguridad a principal. Esto permite generar elementos de mantención más confiables para las sesiones de control con temporizadores muy pequeños durante el evento de conmutación.
Consulte también
Interoperación de funcionalidades con un reinicio agraciado de larga duración del BGP
Este tema contiene las siguientes secciones en las que se describe el comportamiento de trabajo de las diferentes funcionalidades con el reinicio agraciado de larga duración del BGP 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 desde un par BGP fallido que la duración durante la cual dicha información de enrutamiento se mantiene mediante la funcionalidad de reinicio agraciado del BGP.
- Limitaciones de las NLRIs compatibles
- Modo de reinicio LLGR bajo NSR
- Capacidad de LLGR a nivel global, del grupo BGP y del vecino del BGP
Limitaciones de las NLRIs compatibles
La negociación de capacidad y configuración de LLGR se admite para las siguientes familias de información de accesibilidad de capa de red BGP (NLRI):
l2VPN
inet etiquetado como unidifusión
flujo de inet
ruta-destino
unidifusión inet-VPN
flujo inet-VPN
unidifusión inet6-vpn
La negociación de capacidad y configuración de LLGR se impide para las siguientes familias:
inet-mvpn
inet6-mvpn
inet-mdt
En el caso de las familias NLRI para las que se impide la capacidad LLGR, indica que se rechaza un intento de confirmar una configuración que incluya una configuración LLGR para estas familias y que dicha configuración no se guarda. Los NLRIs asociados con estas familias no se incluyen en un anuncio de capacidades de LLGR y se ignoran en un anuncio de capacidades LLGR recibido.
La negociación de capacidad y configuración de LLGR está permitida, pero oculta, para otras familias.
Modo de reinicio LLGR bajo NSR
Cuando NSR y LLGR se configuran juntos, el enrutador negocia la capacidad de LLGR de la manera habitual y regular, incluyendo un tiempo rancio de larga duración para activar el modo de receptor LLGR en sus pares. Sin embargo, la funcionalidad completa del reinicio de LLGR (lo que retrasa la transmisión de los marcadores de fin de RIB hasta que se reciben los EoR de todos los pares) no funciona bajo NSR. Durante el reinicio de un sistema completo (ambos motores de enrutamiento), el demonio de protocolo de enrutamiento (rpd) no espera a que los EoR de otros pares antes de enviar sus propios EoR. Transmite el EoR tan pronto como ha transmitido el contenido rib actual. Esta condición puede causar interrupciones transitorias cuando la red vuelve a converger. Se considera que NSR es adecuado para manejar todos los escenarios de reinicio de 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 del modo de reinicio normal 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, del grupo BGP y del vecino del BGP
El modo de recepción de reinicio agraciado de larga duración está habilitado de forma predeterminada, a menos que el modo de recepción de reinicio agraciado ordinario esté deshabilitado. Para habilitar la capacidad de reinicio agraciado (LLGR) de larga duración del BGP, incluya la long-lived receiver enable instrucción en el [edit protocols bgp graceful-restart] nivel de jerarquía. Además de habilitar el LLGR del BGP a nivel global o de todo el sistema, también puede incluir la instrucción enable del receptor de larga duración en el [edit protocols bgp group group-name graceful- restart] nivel jerárquico para configurar LLGR para un grupo BGP determinado y en el [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] nivel de jerarquía para configurar LLGR para un vecino de BGP en particular. Para deshabilitar el mecanismo LLGR del BGP, incluya la opción del long-lived receiver disable[edit protocols bgp graceful-restart]nivel de jerarquía , [edit protocols bgp group group-name graceful-restart], o [editar protocolos bgp grupo-grupo-nombre vecino dirección graceful-restart] . La deshabilitación de LLGR desactiva todas las capacidades de LLGR (tanto los modos de receptor como de reinicio) para todas las familias NLRI. Esta propiedad la heredan los grupos de la configuración global y los vecinos de la configuración de grupo.
Consulte también
Monitoreo y administración de 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 agraciado de larga duración del BGP. Puede analizar los contadores estadísticos y métricas relacionados con cualquier pérdida de tráfico y tomar una medida correctiva adecuada. 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.
Las clear bgp neighbor neighbor-address stale-routes causas de que las rutas rancios que se mantienen actualmente para el vecino especificado se deban a las operaciones del modo de receptor de reinicio agraciado (GR) o de reinicio agraciado (LLGR) de larga duración. El clear bgp neighbor neighbor-address gracefully comando es el mismo clear bgp neighbor hard que (el valor predeterminado para clear bgp neighbor), pero no utiliza el nuevo subcódigo de restablecimiento completo en los mensajes Notify and Cease que se envían. Esto permite que el vecino entre en el modo de ayuda GR o LLGR, si se negocia. La sesión aún está desactivada en este enrutador y este enrutador no entra en el modo de ayuda GR o LLGR.
Se agrega un comando oculto clear para la capacidad de reinicio agraciado de larga duración del BGP con fines de depuración:
clear bgp neighbor neighbor-address socket.
Este comando rompe 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 que la conexión se rompa. 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 el modo auxiliar GR o LLGR, si se negocia, y la conexión TCP se restablecerá.
El resultado del show bgp neighbor comando se mejora para mostrar la siguiente información adicional:
La opción de reinicio agraciado de larga duración
Los parámetros LLGR que el par ha negociado
Los parámetros LLGR que el enrutador de reinicio ha negociado
Las horas se muestran con el formato %#0T del demonio de protocolo de enrutamiento (rpd):
<weeks>w<days>d <hours>:<minutes>:<seconds>No se omiten los elementos principales; por ejemplo, un valor inferior a una semana no incluye las semanas.
Si el reinicio agraciado de larga duración está completamente deshabilitado para un vecino, se mostrará 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 completamente, 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}
Aunque el modo de recepción LLGR está activo (un par que negoció la LLGR se desconectó y aún no se ha vuelto a conectar), la salida del show bgp neighbor comando muestra la cantidad de tiempo que falta hasta que caduca la LLGR, el tiempo que queda en el temporizador rancio de GR y los detalles 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 receptor de reinicio agraciado 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 las que se mantienen las rutas rancios (NLRI tenemos rutas rancios para el campo), el tiempo que permanece en el temporizador de reinicio (Tiempo hasta que se eliminan las rutas rancios o se convierten en campo rancio de larga vida), el tiempo que permanece en el temporizador rancio (Tiempo hasta que se asume el fin de la rib para rutas rancios) y los detalles rib. La hora se muestra en formato hora universal coordinada (UTC) (AAAA-MM-DD-HH:MM:SS). Tenga en cuenta que la visualización del temporizador rancio ('Tiempo hasta que se asume el fin de la costilla') también está presente cuando una sesión está activa, pero el vecino aún no envió todas las indicaciones del fin de la costilla.
Cuando el reinicio agraciado o el modo de ayuda LLGR está activo, el comando ahora muestra la show bgp summary información RIB. Si se establece una sesión de BGP en el dispositivo de enrutamiento principal, el campo muestra el número de rutas activas, recibidas, aceptadas y atenuadas 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 atenuadas de un par BGP.
En la tabla de enrutamiento inet.2, aparecen 2 rutas activas, 4 rutas recibidas, 4 rutas aceptadas y ninguna ruta atenuada de un par BGP.
El show route detail comando (con y sin la receive-protocol bgp opción) se mejora para identificar rutas que se mantienen en el estado rancio de larga vida. La LongLivedStale marca indica que la ruta fue marcada como LLGR-rancio por este enrutador, como parte de la operación del modo de receptor llGR. El LongLivedStaleImport indicador indica que la ruta se marcó LLGR-rancio cuando se recibió de un par o mediante política de importación. Es posible que se muestren uno o ambos indicadores para una ruta. Ninguna de estas marcas se mostrará al mismo tiempo que la bandera Ranle (GR rancio normal). Cuando una ruta se desconfia porque es rancio de larga duración, el campo Razón inactiva en la salida del comando show route detail muestra LLGR rancio. La nueva razón inactiva de LLGR se ajusta a la jerarquía de selección de ruta 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 largo reinicio agraciado 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 BGP haya finalizado. El uso de la 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 le ayudan a solucionar problemas de esta situación incluyen la aparición de entradas de registro de BGP rancios (como bgp_mark_route_stale) y rutas ocultas que se muestran en la salida del show bgp summary comando.
Consulte también
Aumentar la duración de la conservación de rutas del BGP en los pares de reinicio lento mediante un reinicio agraciado de larga duración del BGP
Junos OS admite el mecanismo para conservar los detalles del enrutamiento del BGP durante un período más largo desde un par BGP fallido que la duración durante la cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio agraciado del BGP.
El modo de recepción de reinicio agraciado de larga duración está habilitado de forma predeterminada, a menos que el modo de recepción de reinicio agraciado ordinario esté deshabilitado. Para habilitar la capacidad de reinicio agraciado (LLGR) de larga duración del BGP, incluya la long-lived receiver enable instrucción en el [edit protocols bgp graceful-restart] nivel de jerarquía. Además de habilitar el LLGR del BGP a nivel global o de todo el sistema, también puede incluir la instrucción enable del receptor de larga duración en el [edit protocols bgp group group-name graceful-restart] nivel jerárquico para configurar LLGR para un grupo BGP determinado y en el [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] nivel de jerarquía para configurar LLGR para un vecino de BGP en particular. Para deshabilitar el mecanismo LLGR del BGP, incluya la opción del long-lived receiver disable[edit protocols bgp graceful-restart]nivel de jerarquía , [edit protocols bgp group group-name graceful-restart], o [editar protocolos bgp grupo-grupo-nombre vecino dirección graceful-restart] . La deshabilitación de LLGR desactiva todas las capacidades de LLGR (tanto los modos de receptor como de reinicio) para todas las familias 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 jerárquicos:
[edit protocols bgp group group-name]— Sistema lógico predeterminado e instancia de enrutamiento predeterminado.[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]— Configurado sistema lógico e instancia de enrutamiento predeterminado.[edit logical-systems logical-system-name routing-instances instance-name protocols bgp group group-name]— Configurado el sistema lógico con una instancia de enrutamiento especificada.
Anula long-lived receiver enable una opción de deshabilitar heredada de un nivel superior en 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 rancios de LLGR se anuncien a los vecinos que no anuncien la capacidad de LLGR, incluya la advertise-to-non-llgr-neighbor instrucción en el [edit protocols bgp graceful-restart long-lived]nivel , [edit protocols bgp group group-name graceful-restart long-lived]o [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] jerarquía. Esta configuración se aplica tanto a las rutas que este enrutador marcaron LLGR-rancios como a las rutas LLGR-rancios recibidas de los vecinos. Idealmente, todos los enrutadores de un sistema autónomo admiten la especificación preliminar de IETF antes de habilitarla. Sin embargo, para facilitar el despliegue incremental, es posible que deban anunciarse rutas rancios a los vecinos que no hayan anunciado la longeva capacidad de reinicio agraciado bajo las siguientes condiciones: Los vecinos deben ser vecinos internos (IBGP o Confederación). La NO_EXPORT comunidad debe estar unida a las rutas rancios. Las rutas rancios deben tener su atributo LOCAL_PREF establecido en cero. Si se utiliza esta técnica para el despliegue parcial, debe establecer LOCAL_PREF en cero para todas las rutas LLGR en todo el sistema autónomo. Esta configuración supone una pequeña reducción de la flexibilidad (es posible que los pedidos no se conserven entre las rutas LLGR de la competencia) 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 prevenir los bucles de reenvío, la última consideración de los enrutadores que no admiten esta especificación precede.
Para evitar que la comunidad de BGP sin exportación se agregue automáticamente a las rutas anunciadas a vecinos de BGP externos (se supone que son enrutadores CE), incluya la omit- no-export instrucción en el [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] nivel de jerarquía. En implementaciones de VPN, por ejemplo, el BGP se utiliza a menudo como protocolo PE-CE. En este tipo de implementaciones, podría ser una necesidad práctica adaptarse a la interoperación con LAS 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 "rancio" no se filtre más allá del perímetro de los enrutadores que admiten estos procedimientos en los que uno o más enrutadores IBGP no se actualizan. En el caso de PE-CE de VPN, el protocolo en uso es EBGP y se utiliza el LOCAL_PREF, un atributo de ruta de solo IBGP. La motivación principal para restringir la propagación de información de enrutamiento "rancio" es la razón para evitar que se propague sin límite una vez que sale del límite de la confederación BGP. Las implementaciones de VPN suelen estar topológicamente limitadas, lo que elimina esta preocupación. Por esta razón, una implementación puede anunciar rutas rancios a través de una sesión de PE-CE, cuando se configura explícitamente. En tal caso, la implementación debe adjuntar la NO_EXPORT comunidad a las rutas en cuestión de forma predeterminada, como protección adicional contra rutas anticuadas que se propagan sin límite. La adscripción de la comunidad NO_EXPORT puede deshabilitarse explícitamente para dar cabida a casos excepcionales. Es posible que sea necesario anunciar rutas rancios 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 que el CE recibe las rutas, y el CE debe estar configurado para despreferenciar las rutas. Las implementaciones típicas de BGP realizan esta operación haciendo coincidir en la comunidad de LLGR_STALE y estableciendo la LOCAL_PREF para que coincidan con rutas a cero.
Cuando el modo de recepción LLGR está habilitado o deshabilitado, la sesión se restablece. Este comportamiento permite que el nuevo valor de capacidad se envíe al vecino. Cuando la advertise-to-non-llgr-neighbor opción está habilitada o deshabilitada, la política de exportación se reevalua y es posible que se anuncien o retiren las rutas rancios de LLGR. Cuando se agrega o elimina la omit-no-export opción, se restablece la sesión. Este resto de una sesión permite reversar las rutas rancios de LLGR 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 agraciado de larga duración del BGP a nivel global o del sistema, 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 agraciado de larga duración del BGP en el nivel del 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 agraciado de larga duración del BGP en el nivel del grupo vecino o 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;
}
}
}
}
}
}
}
Consulte también
Configurar comunidades de reinicio agraciadas de larga duración del BGP en las políticas de enrutamiento
Junos OS admite el mecanismo para conservar los detalles del enrutamiento del BGP durante un período más largo desde un par BGP fallido que la duración durante la cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio agraciado del BGP.
Se introducen dos nuevas comunidades bien conocidas. Estas nuevas comunidades de BGP se pueden usar en cualquiera de los niveles de jerarquía de configuración como otras comunidades simbólicas bien conocidas (como no anunciar, no exportar y no exportar subconfed) en el atributo de comunidad de definiciones de ruta estática 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 rancio de larga duración cuando se revierte.no-llgr— Marca rutas que llgr no desea que conserve un altavoz BGP. La función de mensaje de notificación no tiene parámetros de configuración asociados.
Puede incluir las llgr-stale y no-llgr opciones con la instrucción para asociar la community name members información de la 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 el reinicio agraciado del BGP también se configure. Los valores para las comunidades llgr-stale y no-llgr bien conocidas son 0xFFFF0006 y 0xFFFF0007 respectivamente. Los privilegios son los mismos que para los protocolos bgp. La sección de reinicio agraciado de larga duración solo es visible para las familias l2vpn, inet labeled-unicast, flujo de inet y ruta-objetivo. 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 del BGP que coincida con el estado de una ruta para el reinicio agraciado de larga duración del BGP. Puede asociar la comunidad que definió anteriormente y una lista de prefijos de direcciones en una política de enrutamiento para aceptar o rechazar selectivamente las rutas para un reinicio agraciado de larga duración para los prefijos especificados, de la siguiente manera:
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 en el [edit protocols bgp graceful-restartnivel de jerarquía ] para la configuración global, de grupo y de nivel de grupo vecino.
La disable-notification-flag instrucción en el [edit protocols bgp graceful-restart]nivel de , [edit protocols bgp group group-name graceful-restart]o [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] jerarquía deshabilita la transmisión del indicador N en la negociación de capacidad de reinicio agraciado. La disable-notification-extensions instrucción en el [edit protocols bgp graceful-restart]nivel de , [edit protocols bgp group group-name graceful-restart]o [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] jerarquía también deshabilita la transmisión del indicador N en la negociación de capacidad de reinicio agraciado, pero, además, deshabilita las nuevas reglas para invocar el modo receptor de reinicio agraciado, tal como se especifica en el borrador de bgp-gr-notification de IETF, y deshabilita la transmisión del subcódigo de restablecimiento completo. El subcódigo de restablecimiento completo se sigue observando cuando se recibe en un mensaje De notificación o cese.
Para deshabilitar la transmisión de indicadores N y deshabilitar las reglas para activar el reinicio agraciado a nivel global o de todo el sistema:
[edit]
protocols {
bgp {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
Para deshabilitar la transmisión de indicadores N y deshabilitar las reglas para activar el reinicio agraciado en el nivel de grupo:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
}
Para deshabilitar la transmisión de indicadores N y deshabilitar las reglas para activar el reinicio agraciado en el nivel vecino o par:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
disable-notification-flag;
disable-notification-extensions;
}
}
}
}
Consulte 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 del enrutamiento del BGP durante un período más largo desde un par BGP fallido que la duración durante la cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio agraciado del BGP.
También puede configurar el mecanismo de negociación del modo de reinicio agraciado 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 un sistema, sistema lógico o instancia de enrutamiento. Para habilitar BGP LLGR 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 protocolo o familia de direcciones (AFI) y un identificador de familia de direcciones posterior (SAFI). 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 de la (flow | labeled-unicast) familia inet y uno de los protcols para la (auto-discovery-mspw | auto-discovery-only | signaling) familia L2VPN.
La configuración de LLGR no requiere que el reinicio agraciado del BGP también se configure. La sección de reinicio agraciado de larga duración solo es visible para las familias l2vpn, inet labeled-unicast, flujo de inet y ruta-objetivo. 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 del reiniciador de larga duración graceful-restart por familia permiten la negociación del modo de reinicio LLGR para el BGP globalmente, o para un grupo o vecino. Los valores se heredan los grupos de la configuración global y los vecinos de la configuración de grupo. El atributo disable se utiliza para invalidar la configuración heredada de un nivel superior. No deshabilita el modo de recepción LLGR; debe deshabilitar explícitamente el modo de recepción LLGR para todas las familias según sea necesario. Se puede usar un atributo oculto enable para invalidar un atributo heredado de deshabilitar. La configuración del reiniciador de larga vida agraciado-reinicio en el nivel vecino (cuando no está configurado en el nivel del grupo que contiene o globalmente) hace que un grupo interno se divida. Cuando el reinicio de LLGR está habilitado o deshabilitado para una familia o cuando cambia el tiempo de espera, la sesión se restablece para que la nueva capacidad se pueda enviar al vecino.
El rango de valores para el tiempo rancio 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 mediante la siguiente notación:
[<weeks>w] [<days>d] [<horas>h] [<minutos>m] [<segundos>] Por ejemplo, puede especificar 27 días como 27d, 648h, 3888m 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 agregan 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 supere el tiempo máximo de inactividad.
Además, los tiempos también se pueden configurar mediante la siguiente notación: <horas>:<minutos>:<segundos> Por ejemplo, a las 12:00:00 se especifican doce horas. Las horas y 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 en torno a un valor como este con espacios en él.) Expresado en esta notación, el tiempo máximo es de 27w5d 04:20:15 (27 semanas, 5 días, 4 horas, 20 minutos y 15 segundos). Mientras que el comando show configuration muestra los valores realmente configurados, cuando los temporizadores asociados se muestran en comandos de show en tiempo de ejecución, como show bgp neighbor, los valores se normalizan, como 1d36h pasando a ser 2d 12:00:00. Las reglas completas para mostrar los tiempos de LLGR normalizados dependen de la configuración del clear bgp neighbor neighbor-address gracefully comando.
Para configurar las características de reinicio agraciado de larga duración del BGP por familia de direcciones y familia de direcciones posteriores a nivel global para un sistema lógico o una instancia de enrutamiento:
Configurar el reinicio agraciado de larga duración del BGP 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;
}
}
}
}
}
Configurar el reinicio agraciado de larga duración del BGP 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 las características de reinicio agraciado de larga duración del BGP por familia de direcciones y familia de direcciones posteriores en el nivel del grupo BGP para un sistema lógico o una instancia de enrutamiento:
Configurar el reinicio agraciado de larga duración del BGP por familia de direcciones en el nivel del 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;
}
}
}
}
}
}
Configurar el reinicio agraciado de larga duración del BGP por familia de direcciones en el nivel del grupo 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 agraciado de larga duración del BGP por familia de direcciones y familia de direcciones posteriores en el nivel del grupo de vecinos del BGP para un sistema lógico o una instancia de enrutamiento:
Configurar el reinicio agraciado de larga duración del BGP por familia de direcciones en el nivel del 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;
}
}
}
}
}
}
}
Configurar el reinicio agraciado de larga duración del BGP por familia de direcciones a nivel del 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;
}
}
}
}
}
}
}
Consulte también
Informar al enrutador auxiliar del BGP o al par 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 del enrutamiento del BGP durante un período más largo desde un par BGP fallido que la duración durante la cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio agraciado del BGP.
Después de que una sesión de BGP cae y antes de que se restablezca la sesión, es posible que se conserven rutas rancios durante hasta dos períodos consecutivos, controlados por el tiempo de reinicio y los parámetros de tiempo rancio de larga duración, respectivamente. Durante el primer período, se evitan las modificaciones de enrutamiento, pero con un potencial filtrado de rutas nulas del tráfico. Durante el segundo período, el posible filtrado de rutas nulas del tráfico puede reducirse, 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 determinada debe considerar las concesiones, la dinámica de red y los escenarios de posibles fallas. Si es necesario, el primer período se puede omitir mediante la configuración local o estableciendo el tiempo de reinicio en cero en la capacidad de reinicio agraciado, sin enumerar los indicadores de familia de direcciones (AFI) y un identificador de familia de direcciones posteriores (SAFI) en esa capacidad.
La configuración del bit F (y el bit "Estado de reenvío" de la capacidad GR adjunta) depende en parte de las consideraciones de despliegue. El bit F se puede interpretar para indicar que el enrutador auxiliar necesita vaciar las rutas asociadas (si el bit se deja despejado). Una situación importante en la que se utiliza 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úneles). Para estas rutas, puede ser útil establecer siempre el bit F, independientemente de otras consideraciones. De manera similar, para las entidades solo para el plano de control, como los reflector de ruta dedicados, que no participan en el plano de reenvío, se prefiere que el bit F siempre se establezca. En general, la pauta que se adoptará es que si se puede esperar razonablemente que la pérdida de estado en el enrutador de reinicio cause un bucle de reenvío o una ruta nula, el bit F debe establecerse con criterio, dependiendo de si el estado se ha mantenido. Puede determinar si el bit F debe establecerse o no, según sus necesidades de implementación y los ajustes configurados. Es posible que sea necesario anunciar rutas rancios a un CE en algunas implementaciones de VPN, incluso si el CE no admite esta especificación. En tal caso, el operador de red que configure su PE para anunciar dichas rutas debe notificar al operador que el CE recibe las rutas, y el CE debe estar configurado para despreferenciar las rutas. Normalmente, las implementaciones de BGP realizan este comportamiento haciendo coincidir en la comunidad de LLGR_STALE y estableciendo la LOCAL_PREF para que coincidan las rutas en cero.
Puede especificar el bit de estado de reenvío, que es una opción de configuración del BGP que se puede definir en los niveles global, de grupo y de vecinos, para cualquier instancia de enrutamiento o sistema lógico. Para especificar el bit de estado de reenvío en el nivel global, del grupo BGP o del vecino del BGP, incluya la forwarding-state-bit (as-rr-client | from-fib) instrucción en el [edit protocols bgp graceful-restart]nivel , [edit protocols bgp group-group-name graceful-restart]o [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart] jerarquía. El atributo de estado de reenvío-bit controla cómo se establece el bit de estado de reenvío en los anuncios de capacidad de reinicio agraciado y 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 de acuerdo con el estado de la FIB asociada en cumplimiento con el RFC 4724. Si el vecino es un cliente de reflector de ruta, el valor se establece en 1 para todas las familias, excepto la unidifusión inet y la unidifusión inet6, que utilizan el estado de la FIB asociada. La as-rr-client opción establece el comportamiento de todas las familias de direcciones como la funcionalidad de un cliente de reflector de ruta. La from-fib opción obliga a que el comportamiento de todas las familias de direcciones sea el mismo que para un cliente de reflector que no sea de ruta.
Para configurar la negociación del indicador 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 marca de estado de reenvío en el nivel del grupo:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
}
Para configurar la negociación de marca de estado de reenvío en el nivel de grupo vecino o 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, el comportamiento del bit de estado de reenvío se puede especificar para familias individuales. Cambiar la configuración de estado de reenvío-bit 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 [edit protocols bgp graceful-restart family address-family subsequent-address-family]nivel de jerarquía [edit protocols bgp group-group-name graceful-restart family address-family subsequent-address-family]o , en [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart family address-family subsequent-address-family] un sistema lógico y una instancia de enrutamiento. Se agregan opciones de configuración del BGP por familia para controlar el bit de estado de reenvío en un reinicio agraciado y los anuncios de capacidad de reinicio agraciado 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 reemplaza las reglas predeterminadas o la configuración global para establecer el bit de estado de reenvío. La set opción obliga al bit de estado de reenvío a establecerse en 1. La from-fib opción hace que el valor se establezca de acuerdo con el estado de la FIB asociada. Cambiar la configuración de bit de estado de reenvío por familia no afecta a ninguna sesión existente.
A continuación, se muestran los niveles completos de jerarquía de configuración 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 una familia de reinicio agraciado de larga duración del BGP y familia de direcciones posteriores a nivel global para un sistema lógico o una instancia de enrutamiento:
Configuración de la familia bit de estado de reenvío por dirección 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 de la familia bit de estado de reenvío por dirección 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 un reinicio agraciado de larga duración del BGP y una familia de direcciones posteriores en el nivel del grupo BGP para un sistema lógico o una instancia de enrutamiento:
Configuración de la familia de bits de estado de reenvío por dirección en el nivel del 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 del grupo 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 un reinicio agraciado de larga duración del BGP con una familia de direcciones y una familia de direcciones posteriores en el nivel del 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 del 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 del 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);
}
}
}
}
}
Consulte también
Ejemplo: Conservar los detalles de la ruta para los pares de BGP lentos y latentes mediante el reinicio agraciado y de larga duración del BGP
Junos OS admite el mecanismo para conservar los detalles del enrutamiento del BGP durante un período más largo desde un par BGP fallido que la duración durante la cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio agraciado del BGP.
Históricamente, los protocolos de enrutamiento y el 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 red converja hacia el estado actual de la red lo antes posible. Por esta razón, el protocolo fue diseñado para eliminar el estado anunciado por los enrutadores que se redujeron (desde una perspectiva del BGP) lo más rápido posible. Mediante el BGP Graceful Restart definido en RFC 4724, la funcionalidad de convergencia rápida ha sido un intento de eliminar rápidamente el estado "rancio" de la red.
El reinicio agraciado de larga duración del BGP (LLGR) permite que un operador de red elija mantener la información de enrutamiento rancio desde un par BGP fallido 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 IETF, Soporte para BGP de larga duración graceful Restart—draft-uttaro-idr-bgp-persistencia-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 rancio a otros pares que no reconocen y validan LLGR.
En este ejemplo, se describe cómo configurar la funcionalidad de reinicio agraciado de larga duración del BGP en enrutadores serie MX, y contiene las siguientes secciones:
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
Un enrutador serie MX con un MPC.
Junos OS versión 15.1R1 o posterior para enrutadores serie MX
Antes de configurar el reinicio agraciado de larga duración del BGP, asegúrese de:
Configure las interfaces del dispositivo.
Configure BGP.
Descripción general
El reinicio elegante permite que un dispositivo de enrutamiento que se está reiniciando informe a sus vecinos y pares adyacentes de su estado. Durante un reinicio agraciado, el dispositivo que está reiniciando 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 volver a calcular los algoritmos.
El modo de recepción de reinicio agraciado de larga duración está habilitado de forma predeterminada, a menos que el modo de recepción de reinicio agraciado ordinario esté deshabilitado. Para habilitar la capacidad de reinicio agraciado (LLGR) de larga duración del BGP, incluya la long-lived receiver enable instrucción en el [edit protocols bgp graceful-restart] nivel de jerarquía. Además de habilitar el LLGR del BGP a nivel global o de todo el sistema, también puede incluir la instrucción enable del receptor de larga duración en el [edit protocols bgp group group-name graceful-restart] nivel jerárquico para configurar LLGR para un grupo BGP determinado y en el [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] nivel de jerarquía para configurar LLGR para un vecino de BGP en particular. Para deshabilitar el mecanismo LLGR del BGP, incluya la opción del long-lived receiver disable[edit protocols bgp graceful-restart]nivel de jerarquía , [edit protocols bgp group group-name graceful-restart], o [editar protocolos bgp grupo-grupo-nombre vecino dirección graceful-restart] . La deshabilitación de LLGR desactiva todas las capacidades de LLGR (tanto los modos de receptor como de reinicio) para todas las familias 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 caso de ejemplo en el que desea aumentar el período de tiempo durante el cual se mantienen rutas rancios para un par o vecino BGP con la dirección de 1.2.3.4. Además de especificar la duración durante la cual se deben conservar las rutas para sesiones rancios y cuando se produce un reinicio agraciado de un par, también puede configurar enrutadores BGP desde ciertos prefijos de dirección que se deben ignorar al definir el mecanismo de reinicio agraciado de larga duración. Puede definir una lista de prefijos de dirección IPv4 o IPv6 para su uso en una instrucción de política de enrutamiento y una comunidad BGP que se incluirá en la política de enrutamiento. Si establece el modificador de acción para rechazar rutas desde un prefijo determinado, estas rutas de BGP no se mantienen durante el período de tiempo aumentado.
También puede configurar el mecanismo de negociación del modo de reinicio agraciado 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 un sistema, sistema lógico o instancia de enrutamiento. Para habilitar BGP LLGR 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 protocolo o familia de direcciones (AFI) y un identificador de familia de direcciones posterior (SAFI). 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 de la (flow | labeled-unicast) familia inet y uno de los protcols para la (auto-discovery-mspw | auto-discovery-only | signaling) familia L2VPN.
La configuración de LLGR no requiere que el reinicio agraciado del BGP también se configure. La sección de reinicio agraciado de larga duración solo es visible para las familias l2vpn, inet labeled-unicast, flujo de inet y ruta-objetivo. 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 agraciado 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, comunidad BGP y 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
Configurar el grupo de vecinos del BGP
set protocols bgp group ibgp-group neighbor 1.2.3.4
Configuración de un reinicio agraciado de larga duración para el modo de reinicio
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue 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 en la Guía del usuario de CLI.
Configure la lista de prefijos de direcciones, la comunidad de BGP y la condición de coincidencia y el modificador de acción para la política de enrutamiento del 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 agraciado de larga duración para el modo de reinicio con el tiempo obsoleto para 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 en este ejemplo para corregir la configuración.
[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 funciona correctamente.
Verificar que la capacidad de reinicio agraciado de larga duración esté habilitada
Propósito
Verificar la capacidad de reinicio agraciado de larga duración del BGP configurada para el nivel de vecino del BGP
Acción
Aunque el modo de recepción LLGR está activo (un par que negoció la LLGR se desconectó y aún no se ha vuelto a conectar), la salida del show bgp neighbor comando muestra la cantidad de tiempo que falta hasta que caduca la LLGR, el tiempo que queda en el temporizador rancio de GR y los detalles 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.