Descripción del reinicio correcto para BGP
Descripción de la capacidad de reinicio satisfactorio de 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 desde un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio correcto 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 importante 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 cayeron (desde una perspectiva BGP) lo antes posible. Mediante el uso del reinicio satisfactorio 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 causado que este método de eliminación rápida de estados obsoletos se modifique y mejore. El primero 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 creciente de BGP como un 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 detección automática (VPLS [RFC4761]) y programación de filtros (FLOWSPEC [RFC5575]). En estos casos, los datos BGP asumen una característica que no está en línea con el enrutamiento tradicional.
Era importante ofrecer a los operadores de red la posibilidad de elegir conservar los datos del BGP durante un período más largo cuando el plano de control del BGP fallara por algún motivo. Aunque las propiedades de BGP Graceful Restart están cerca de este requisito deseado para conservar la información BGP durante más tiempo, existen varias brechas, sobre todo en el tiempo máximo durante el cual se puede retener información "obsoleta": el reinicio correcto impone una limitación de límite superior de 4095 segundos. Junos OS admite una capacidad BGP denominada capacidad de reinicio elegante de larga duración, de modo que la información obsoleta se puede 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 ser tratada como menos preferida, y su anuncio limitado a los altavoces BGP que admiten la nueva capacidad.
El reinicio satisfactorio de larga duración (LLGR) de BGP permite a un operador de red elegir mantener la información de enrutamiento obsoleta de un par BGP fallido por mucho más tiempo que la instalación de reinicio correcto BGP existente. Esta funcionalidad para mantener las rutas BGP durante un período de tiempo más largo está de acuerdo con el borrador del IETF, Support for Long-life BGP Graceful Restart—draft-uttaro-idr-bgp-persistence-03. De acuerdo con 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 y 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 LLGR por NLRI mediante los comandos show adecuados.
Puede ver si LLGR está actualmente vigente para un par y, si es efectivo, el período después del cual expira.
Las rutas obsoletas retenidas 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 (utilizando comunidades bien definidas).
Aunque la metodología LLGR se puede aplicar a varios escenarios diferentes, un escenario específico es el objetivo sobresaliente de esta característica. En un escenario en el que se produce una pérdida de conectividad entre un reflector de ruta y un cliente, incluida la conectividad intermitente que puede hacer que se restablezca una conexión antes de que se pueda transmitir toda la RIB, dicha falla no produce 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 del IETF, draft-uttaro-idr-bgp-persistence-03, para LLGR. Además, se admite la compatibilidad con versiones anteriores a la versión 15.1, específicamente el reinicio elegante y el enrutamiento sin interrupciones (NSR). Cuando se configura LLGR, el reinicio correcto 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 del IETF, la compatibilidad del mensaje de notificación con BGP Graceful Restart—draft-ietf- idr-bgp-gr-notification-01. Este borrador amplía el comportamiento de los recursos genéticos ordinarios para permitirle proteger contra interrupciones de las comunicaciones y errores de protocolo.
Consulte también
Descripción de la configuración del período máximo para la generación automática de keepalives BGP por temporizadores de kernel después del cambio
En Junos OS, el enrutamiento activo sin paradas (NSR) usa la misma infraestructura que el cambio de 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 ejecutando el proceso de protocolo de enrutamiento (rpd) en el motor de enrutamiento de reserva. 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 vecinos (o conmutadores) no admiten extensiones de protocolo de reinicio correcto. Como resultado de esta funcionalidad mejorada, NSR es un reemplazo natural para un reinicio elegante.
La combinación automática de enrutamiento activo sin interrupciones es uno de los componentes del kernel de la replicación de sockets. Al cambiar, este componente combina automáticamente los pares de sockets desde la copia de seguridad al motor de enrutamiento principal. El cambio de NSR de copia de seguridad a principal ocurre cuando rpd emite una llamada de combinación para cada par de sockets secundarios para fusionarlos en un solo socket, lo que podría provocar un retraso. Para evitar este retraso, un módulo de combinación automática en el kernel desacopla la combinación de sockets secundarios de rpd y combina automáticamente sockets secundarios en el switchover para que el subproceso de alta prioridad rpd aproveche esto y genere keepalive más rápido para mantener conexiones TCP en switchover.
De forma predeterminada, BGP no se registra para el servicio de generación keepalive automática proporcionado por el kernel justo después del evento de cambio de copia de seguridad a primaria. Para ello, debe habilitar la instrucción en el nivel de jerarquía [edit routing-options] y configurar temporizadores de nonstop-routing-options precisión en BGP. La configuración de temporizadores de precisión en BGP permite a BGP registrar todas sus sesiones con el servicio de generación automática keepalive proporcionado por el kernel. Una vez registrado, el kernel genera automáticamente keepalives usando sus temporizadores en nombre de BGP para sus sesiones de control justo después del evento de cambio de copia de seguridad a primaria. Esto permite la generación de keepalives más fiables para las sesiones de control con temporizadores muy pequeños durante el evento de cambio.
Consulte también
Interoperación de funcionalidades con BGP Reinicio agraciado
Este tema contiene las siguientes secciones que describen el comportamiento de trabajo de diferentes funcionalidades con el reinicio agraciado de larga duración 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 BGP durante un período más largo desde un par BGP con errores que el tiempo durante el que se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio correcto de BGP.
- Limitaciones de las NLRI compatibles
- Modo de reinicio LLGR bajo NSR
- Capacidad de LLGR a nivel global, de grupo BGP y de vecinos de BGP
Limitaciones de las NLRI compatibles
La configuración de LLGR y la negociación de capacidades se admiten para las siguientes familias de información de accesibilidad de capa de red (NLRI) de BGP:
L2VPN
inet etiquetado-unidifusión
flujo de inet
destino de ruta
Unidifusión inet-VPN
Flujo inet-vpn
Unidifusión Inet6-VPN
Se impide la configuración de LLGR y la negociación de capacidades para las siguientes familias:
inet-mvpn
inet6-mvpn
inet-mdt
Para las familias NLRI para las que se impide la capacidad LLGR, indica que se rechaza un intento de confirmar una configuración que incluye una configuración LLGR para estas familias y dicha configuración no se guarda. Las NLRI asociadas 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 configuración de LLGR y la negociación de capacidades están permitidas, pero ocultas, 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 obsoleto de larga duración para activar el modo receptor LLGR en sus pares. Sin embargo, la funcionalidad completa del reinicio de LLGR (retrasar la transmisión de los marcadores de fin de RIB hasta que se reciban EoR de todos los pares) no funciona bajo NSR. Durante un reinicio completo del sistema (ambos motores de enrutamiento), el demonio de protocolo de enrutamiento (rpd) no espera las EoR de otros pares antes de enviar su propia EoR. Transmite la 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 adecuada para manejar todos los escenarios de reinicio del motor de enrutamiento único. La restricción del modo de reinicio solo afecta a los escenarios en los que ambos motores de enrutamiento (o ambas copias de rpd) se reinician simultáneamente. La configuración del modo de reinicio ordinario no está habilitada con NSR.
La configuración normal del modo de reinicio sin gracia sigue sin ser compatible con NSR.
Capacidad de LLGR a nivel global, de grupo BGP y de vecinos de BGP
El modo de receptor de reinicio agraciado de larga duración está habilitado de forma predeterminada, a menos que el modo de receptor de reinicio normal ordinario esté deshabilitado. Para habilitar la capacidad BGP de reinicio correcto de larga duración (LLGR), incluya la long-lived receiver enable instrucción en el nivel de [edit protocols bgp graceful-restart] jerarquía. Además de habilitar BGP LLGR a nivel global o de todo el sistema, también puede incluir la instrucción receiver enable de larga duración en el nivel de [edit protocols bgp group group-name graceful- restart] jerarquía para configurar LLGR para un grupo 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 de BGP, incluya la long-lived receiver disable opción , [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart]o [editar protocolos bgp group-group-name neighbor neighbor-address graceful-restart]. Al deshabilitar LLGR, se desactivan todas las capacidades de LLGR (modos receptor y 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.
Consulte también
Monitoreo y administración de BGP Reinicio agraciado
En este tema se describen los comandos operativos y su importancia para permitirle analizar y ver los parámetros relacionados con el reinicio elegante de larga duración de 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 la salida de los comandos show ayudan a diagnosticar y depurar el rendimiento de la red y los problemas de eficiencia del manejo del tráfico.
Esto clear bgp neighbor neighbor-address stale-routes causa cualquier ruta obsoleta que se esté reteniendo actualmente para el vecino especificado debido a operaciones de modo de receptor de reinicio correcto (GR) o reinicio correcto 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 de notificación y cese que se envían. Esto permite al vecino entrar en modo auxiliar GR o LLGR, si se negocia. La sesión sigue desactivada en este enrutador y este enrutador no entra en el modo auxiliar GR o LLGR.
Se agrega un comando oculto clear 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 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 la conexión que se está rompiendo. El efecto resultante es que (a menos que se hayan deshabilitado las extensiones de notificación GR) ambos lados de la conexión entrarán en modo auxiliar GR o LLGR, si se negocia, y la conexión TCP se restablecerá.
El resultado del show bgp neighbor comando se ha mejorado 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 ha negociado 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 agraciado 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 receptor LLGR está activo (un par que negoció LLGR se ha desconectado y aún no se ha vuelto a conectar), la salida del show bgp neighbor comando muestra la cantidad de tiempo restante hasta que expire el LLGR, el tiempo restante en el temporizador obsoleto 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 de 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 mantenemos rutas obsoletas para el campo), el tiempo restante en el temporizador de reinicio (tiempo hasta que las rutas obsoletas se eliminen o se conviertan 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 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 obsoleta ("Se asume el tiempo hasta 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 de fin de costilla.
Cuando el reinicio correcto o el modo auxiliar LLGR están activos, el show bgp summary comando muestra ahora la información de RIB. Si se establece una sesión BGP en el dispositivo de enrutamiento principal, el campo muestra el número 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:
8 rutas activas, 10 rutas recibidas, 10 rutas aceptadas y 2 rutas amortiguadas de un par BGP aparecen en la tabla de enrutamiento inet.0.
En la tabla de enrutamiento inet.2 aparecen 2 rutas activas, 4 rutas recibidas, 4 rutas aceptadas y ninguna ruta amortiguada de un par BGP.
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 un estado obsoleto de larga duración. El LongLivedStale indicador indica que la ruta fue marcada como LLGR-obsoleta por este enrutador, como parte de la operación del modo receptor LLGR. El LongLivedStaleImport indicador indica que la ruta se marcó como LLGR-obsoleta cuando se recibió de un par o por política de importación. Una o ambas de estas banderas pueden mostrarse para una ruta. Ninguna de estas banderas se mostrará al mismo tiempo que la bandera obsoleta (obsoleta GR ordinaria). Cuando se desprecia una ruta porque es obsoleta de larga duración, el campo Motivo inactivo de la salida del comando mostrar detalle de ruta muestra LLGR obsoleta. La nueva razón inactiva obsoleta de LLGR encaja en 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 reinicio agraciado 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 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 ayudarán a solucionar este escenario incluyen la aparición de entradas de registro BGP obsoletas (como bgp_mark_route_stale) y rutas ocultas que aparecen en la salida del show bgp summary comando.
Consulte también
Aumento de la duración de la conservación de rutas BGP en pares que se reinician lentamente mediante un reinicio prolongado y duradero de BGP
Junos OS admite el mecanismo para conservar los detalles de enrutamiento del BGP durante un período más largo desde un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio correcto del BGP.
El modo de receptor de reinicio agraciado de larga duración está habilitado de forma predeterminada, a menos que el modo de receptor de reinicio normal ordinario esté deshabilitado. Para habilitar la capacidad BGP de reinicio correcto de larga duración (LLGR), incluya la long-lived receiver enable instrucción en el nivel de [edit protocols bgp graceful-restart] jerarquía. Además de habilitar BGP LLGR a nivel global o de todo el sistema, también puede incluir la instrucción receiver enable de larga duración en el nivel de [edit protocols bgp group group-name graceful-restart] jerarquía para configurar LLGR para un grupo 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 de BGP, incluya la long-lived receiver disable opción , [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart]o [editar protocolos bgp group-group-name neighbor neighbor-address graceful-restart]. Al deshabilitar LLGR, se desactivan todas las capacidades de LLGR (modos receptor y 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 de 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.
El long-lived receiver enable anula una opción de deshabilitación 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 obsoletas de LLGR se anuncien a los vecinos que no anuncian la capacidad LLGR, incluya la advertise-to-non-llgr-neighbor 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] jerárquico. Esta configuración se aplica tanto a las rutas marcadas como LLGR-obsoletas por este enrutador como a las rutas LLGR-obsoletas recibidas de los vecinos. Idealmente, todos los enrutadores en un sistema autónomo admiten el borrador de la especificación IETF antes de que se habilitara. Sin embargo, para facilitar el despliegue incremental, es posible que sea necesario anunciar rutas obsoletas a los vecinos que no hayan anunciado la capacidad de reinicio correcto de larga duración en las siguientes condiciones: Los vecinos deben ser vecinos internos (IBGP o Confederación). La comunidad NO_EXPORT debe estar unida a las rutas obsoletas. Las rutas obsoletas 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 compensa una pequeña reducción en la flexibilidad (es posible que no se conserve el orden entre rutas LLGR de la competencia) para mantener la coherencia entre los enrutadores que admiten y no admiten esta especificación. Dado que la coherencia de la selección de ruta puede ser importante para evitar bucles de reenvío, precede a esta última consideración de los enrutadores que no admiten esta especificación.
Para evitar que la comunidad BGP sin exportación se agregue automáticamente a las rutas anunciadas a vecinos BGP externos (que se supone que son enrutadores CE), incluya la omit- no-export instrucción en el nivel , [edit protocols bgp group group-name graceful-restart long-lived][edit protocols bgp graceful-restart long-lived]o [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] jerárquico. En las implementaciones de VPN, por ejemplo, BGP se usa a menudo como un protocolo PE-CE. Podría ser una necesidad práctica en tales implementaciones acomodar la interoperación con CE que no se pueden actualizar fácilmente para admitir especificaciones como esta. Este requisito causa un problema al tiempo 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 IBGP no se actualizan. En el caso de VPN PE-CE, el protocolo en uso es EBGP y se utiliza el LOCAL_PREF, un atributo de ruta de solo 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 sale del límite de la confederación 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 en una sesión de PE-CE, cuando se configura explícitamente. En tal escenario, la implementación debe adjuntar la comunidad NO_EXPORT a las rutas en cuestión por defecto, como una protección adicional contra las rutas obsoletas que se propagan sin límite. El apego de la comunidad NO_EXPORT puede ser deshabilitado explícitamente para acomodar casos excepcionales. Puede ser necesario anunciar 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 despreferenciar las rutas. Las implementaciones típicas de BGP realizan esta operación haciendo coincidir en la comunidad LLGR_STALE y estableciendo el LOCAL_PREF para hacer coincidir las rutas a cero.
Cuando el modo receptor 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 opción está habilitada o deshabilitada, la advertise-to-non-llgr-neighbor política de exportación se vuelve a evaluar y las rutas obsoletas LLGR pueden anunciarse o retirarse. Cuando se agrega o elimina la omit-no-export opción, se restablece la sesión. Este resto de una 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 en el sistema o a nivel 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 correcto de larga duración del BGP en el nivel de grupo del 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 satisfactorio de larga duración del BGP en el nivel de 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
Configuración de comunidades de reinicio agraciado de larga duración de 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 desde un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio correcto del BGP.
Se introducen dos nuevas comunidades conocidas. Estas nuevas comunidades BGP se pueden utilizar en cualquiera de los niveles de jerarquía de configuración como otras comunidades simbólicas conocidas (como no-advertise, no-export y no-export-subconfed) en el atributo community de definiciones de ruta 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 rutas que un altavoz BGP no desea que LLGR conserve. La característica Mensaje de notificación no tiene ningún parámetro de configuración asociado.
Puede incluir las opciones y no-llgr con la community name members instrucción para asociar información de llgr-stale la comunidad 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 usarlas en una condición de coincidencia de directiva de enrutamiento:
[edit policy-options]
community name {
members [ llgr-stale | nollgr];
}
La configuración de LLGR no requiere que también se configure un reinicio correcto del BGP. Los valores para las comunidades llgr-rancio y no-llgr 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 inet y route-target. Está prohibido para inet-mvpn, inet6-mvpn e inet-mdt. Está escondido para otras familias.
Junos OS también proporciona compatibilidad para configurar una política de exportación de BGP que coincida con el estado de una ruta para un reinicio de larga duración del BGP. Puede asociar la comunidad que definió anteriormente y una lista de prefijos de dirección en una directiva de enrutamiento para aceptar o rechazar selectivamente las rutas para un reinicio agraciado 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 en el nivel de jerarquía ] para la [edit protocols bgp graceful-restartconfiguración global, de nivel de grupo y de grupo de vecinos.
La disable-notification-flag instrucción en el nivel , [edit protocols bgp graceful-restart][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 correcto. La disable-notification-extensions instrucción en el [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart]nivel , o [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] jerárquico también deshabilita la transmisión del indicador N en la negociación de capacidad de reinicio correcto, pero además, deshabilita las nuevas reglas para invocar el modo de receptor de reinicio correcto como se especifica en el borrador de notificación 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 N indicadores y deshabilitar reglas para desencadenar un reinicio correcto 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 N indicadores y deshabilitar reglas para desencadenar un 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 reglas para desencadenar un reinicio correcto a nivel de 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 de larga duración del modo de reinicio 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 desde un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio correcto del BGP.
También puede configurar el mecanismo de negociación del modo de reinicio de larga duración BGP para una familia de direcciones determinada en lugar de configurar esta capacidad para todas las familias de direcciones de 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 la familia de protocolos o el indicador 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 protcols para la (auto-discovery-mspw | auto-discovery-only | signaling) familia L2VPN.
La configuración de LLGR no requiere que también se configure un reinicio correcto del BGP. La sección de reinicio agraciado de larga duración solo es visible para las familias l2vpn, inet labeled-unicast, flujo inet y route-target. Está prohibido para inet-mvpn, inet6-mvpn e inet-mdt. Está escondido 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 en la sección de configuración del reinicio de larga duración por familia permiten la negociación del modo de reinicio LLGR para BGP globalmente, o para un grupo o vecino. Los valores son heredados por grupos de la configuración global y por 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 receptor LLGR; debe deshabilitar el modo receptor LLGR explícitamente para todas las familias según sea necesario. Un atributo oculto enable se puede utilizar para anular un atributo de deshabilitación heredado. La configuración del reinicio de larga duración y reinicio correcto en el nivel del vecino (cuando no está configurado en el nivel del grupo de contención o globalmente) hace que se divida un grupo interno. Cuando el reinicio de 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 de estancamiento 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 con la siguiente notación:
[<semanas>w] [<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, los tiempos también se pueden configurar utilizando 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 obsoleto es 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 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 LLGR normalizados dependen de la configuración del clear bgp neighbor neighbor-address gracefully comando.
Para configurar las características de reinicio satisfactorio de larga duración del BGP por familia de direcciones y por familia de direcciones posteriores a nivel global para un sistema lógico o una instancia de enrutamiento:
Configuración de BGP de larga duración y reinicio 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 de BGP de larga duración y reinicio satisfactorio 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 satisfactorio de larga duración del BGP, por familia de direcciones y por familia de direcciones posteriores en el nivel de grupo de BGP para un sistema lógico o una instancia de enrutamiento:
Configuración de BGP de larga duración y reinicio correcto 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 {
long-lived {
restarter {
disable;
stale-time interval;
}
}
}
}
}
}
Configuración de BGP de larga duración y reinicio correcto por familia de direcciones en el nivel de 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 satisfactorio de larga duración del BGP por familia de direcciones y por familia de direcciones posteriores en el nivel de grupo de vecinos del BGP para un sistema lógico o una instancia de enrutamiento:
Configuración de BGP de larga duración y reinicio correcto por familia de direcciones en el nivel de grupo de vecinos de 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 de BGP de larga duración y reinicio correcto por familia de direcciones en el nivel de grupo de vecinos de 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 par o enrutador auxiliar BGP sobre la retenció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 desde un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio correcto del BGP.
Después de que una sesión BGP deja de funcionar y antes de que se restablezca la sesión, las rutas obsoletas pueden conservarse durante un máximo de dos períodos consecutivos, controlados por los parámetros de tiempo de reinicio y tiempo de caducidad de larga duración, respectivamente. Durante el primer período se evitan las modificaciones de enrutamiento, pero con un posible filtrado de tráfico de ruta nula. Durante el segundo período, el posible filtrado de tráfico de ruta nula podría 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 tener en cuenta las compensaciones, la dinámica de la red y los posibles escenarios de error. Si es necesario, el primer período se puede omitir mediante la configuración local o estableciendo el tiempo de reinicio en la capacidad de reinicio correcto en cero, sin enumerar los indicadores de familia de direcciones (AFI) y los identificadores de familia de direcciones (SAFI) posteriores en esa capacidad.
La configuración 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 se puede interpretar para indicar que el enrutador auxiliar necesita vaciar las rutas asociadas (si el bit se deja claro). 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úneles). Para tales rutas, podría ser útil establecer siempre el bit F, independientemente de otras consideraciones. Del mismo modo, para las entidades de solo plano de control, como los reflectores de ruta dedicados, que no participan en el plano de reenvío, se prefiere que el bit F esté siempre establecido. En general, la directriz que debe adoptarse 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 juiciosamente, dependiendo de si se ha conservado el estado. Puede determinar si es necesario establecer el bit F o no, en función de sus necesidades de implementación y las opciones configuradas. Puede ser necesario anunciar 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 configure su PE para anunciar dichas rutas debe notificar al operador que el CE recibe las rutas, y el CE debe configurarse para despreferenciar las rutas. Normalmente, las implementaciones de BGP realizan este comportamiento haciendo coincidir en la comunidad LLGR_STALE y estableciendo la LOCAL_PREF para hacer coincidir las rutas a cero.
Puede especificar el bit de estado de reenvío, que es una opción de configuración de BGP que se puede definir a nivel global, de grupo y de vecino, para cualquier sistema lógico o instancia de enrutamiento. Para especificar el bit de estado de reenvío en el nivel global, de grupo 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 jerarquía[edit protocols bgp graceful-restart][edit protocols bgp group-group-name graceful-restart]. El atributo de bit de estado de reenvío controla cómo se establece el bit de estado de reenvío tanto en los anuncios de capacidad de reinicio correcto como en los de capacidad de reinicio correcto 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 del FIB asociado 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 la unidifusión inet y la unidifusión inet6, que utilizan el estado de la FIB asociada. La as-rr-client opción establece que el comportamiento de todas las familias de direcciones sea igual que la funcionalidad de un cliente de reflector de ruta. La from-fib opción fuerza que el comportamiento de todas las familias de direcciones sea el mismo que el de un cliente que no es reflector de rutas.
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 del indicador de estado de reenvío en el nivel de grupo:
[edit]
protocols {
bgp {
group group-name {
graceful-restart {
forwarding-state-bit (as-rr-client | from-fib);
}
}
}
}
Para configurar la negociación del indicador de estado de reenvío a 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 del bit Estado de reenvío, se puede especificar el comportamiento del bit Estado de reenvío para familias individuales. Cambiar la configuración del bit de estado de reenvío no afecta a 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 , o [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart family address-family subsequent-address-family] jerárquico en un sistema lógico y una instancia de [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]enrutamiento. Se agregan opciones de configuración de BGP por familia para controlar el bit de estado de reenvío en anuncios de capacidad de reinicio agraciado y 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 de estado de reenvío. La set opción fuerza que el bit Estado de reenvío se establezca 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 del 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 el reinicio satisfactorio de larga duración por familia de direcciones BGP y por familia de direcciones posteriores 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 reinicio satisfactorio de larga duración por familia de direcciones BGP y por familia de direcciones posteriores en el nivel de grupo 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 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 reinicio satisfactorio de larga duración por familia de direcciones BGP y por familia de direcciones subsiguientes en el nivel de grupo de vecinos de 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 de 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);
}
}
}
}
}
Consulte también
Ejemplo: Conservación de detalles de ruta para pares BGP lentos y latentes mediante el reinicio satisfactorio de larga duración de BGP
Junos OS admite el mecanismo para conservar los detalles de enrutamiento del BGP durante un período más largo desde un par BGP con errores que el tiempo durante el cual se mantiene dicha información de enrutamiento mediante la funcionalidad de reinicio correcto 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 importante 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 cayeron (desde una perspectiva BGP) lo antes posible. Mediante el uso del reinicio satisfactorio 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 satisfactorio de larga duración (LLGR) de BGP permite a un operador de red elegir mantener la información de enrutamiento obsoleta de un par BGP fallido por mucho más tiempo que la instalación de reinicio correcto BGP existente. Esta funcionalidad para mantener las rutas BGP durante un período de tiempo más largo está de acuerdo con el borrador del IETF, Support for Long-life BGP Graceful Restart—draft-uttaro-idr-bgp-persistence-03. De acuerdo con 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 y validan LLGR.
En este ejemplo se describe cómo configurar la funcionalidad de reinicio satisfactorio de larga duración BGP en enrutadores de la serie MX y se resumen las siguientes secciones:
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
Un enrutador de la serie MX con un MPC.
Junos OS versión 15.1R1 o posterior para enrutadores serie MX
Antes de configurar el reinicio de larga duración del BGP, asegúrese de que:
Configure las interfaces del dispositivo.
Configure BGP.
Descripción general
El reinicio correcto 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 correcto, el dispositivo de reinicio y sus vecinos continúan reenviando paquetes sin interrumpir el rendimiento de la red. Debido a 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 agraciado de larga duración está habilitado de forma predeterminada, a menos que el modo de receptor de reinicio normal ordinario esté deshabilitado. Para habilitar la capacidad BGP de reinicio correcto de larga duración (LLGR), incluya la long-lived receiver enable instrucción en el nivel de [edit protocols bgp graceful-restart] jerarquía. Además de habilitar BGP LLGR a nivel global o de todo el sistema, también puede incluir la instrucción receiver enable de larga duración en el nivel de [edit protocols bgp group group-name graceful-restart] jerarquía para configurar LLGR para un grupo 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 de BGP, incluya la long-lived receiver disable opción , [edit protocols bgp graceful-restart][edit protocols bgp group group-name graceful-restart]o [editar protocolos bgp group-group-name neighbor neighbor-address graceful-restart]. Al deshabilitar LLGR, se desactivan todas las capacidades de LLGR (modos receptor y 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 rutas obsoletas para un par o vecino BGP 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 a partir de ciertos prefijos de dirección que no se tendrán en cuenta al definir el mecanismo de reinicio correcto de larga duración. Puede definir una lista de prefijos de dirección IPv4 o IPv6 para usarlos en una instrucción de política de enrutamiento y en una comunidad BGP para incluirla en la directiva de enrutamiento. Si configura el modificador de acción para que rechace rutas de un prefijo determinado, dichas rutas 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 de larga duración BGP para una familia de direcciones determinada en lugar de configurar esta capacidad para todas las familias de direcciones de 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 la familia de protocolos o el indicador 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 protcols para la (auto-discovery-mspw | auto-discovery-only | signaling) familia L2VPN.
La configuración de LLGR no requiere que también se configure un reinicio correcto del BGP. La sección de reinicio agraciado de larga duración solo es visible para las familias l2vpn, inet labeled-unicast, flujo inet y route-target. Está prohibido para inet-mvpn, inet6-mvpn e inet-mdt. Está escondido 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 [edit] y, luego, ingrese commit desde el modo de configuración.
Configuración de la lista de prefijos de dirección, la comunidad BGP y la directiva de enrutamiento 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 un reinicio correcto 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 agraciado de larga duración para el modo de reinicio
Procedimiento paso a paso
El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.
Configure la lista de prefijos de dirección, la comunidad BGP y el modificador de condición y acción de coincidencia para la directiva de enrutamiento 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 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, escriba los comandos show policy-options y show protocols para confirmar la 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 funcione correctamente.
Comprobación de que la capacidad de reinicio correcto de larga duración está habilitada
Propósito
Compruebe la capacidad de reinicio satisfactorio de larga duración del BGP configurada para el nivel de vecino del BGP
Acción
Mientras el modo receptor LLGR está activo (un par que negoció LLGR se ha desconectado y aún no se ha vuelto a conectar), la salida del show bgp neighbor comando muestra la cantidad de tiempo restante hasta que expire el LLGR, el tiempo restante en el temporizador obsoleto 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 de BGP.