Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Descripción del reinicio correcto BGP

Comprensión de la capacidad de BGP de reinicio normal de larga duración

Junos OS admite el mecanismo para conservar BGP detalles de enrutamiento durante un período más largo de un par BGP con errores que la duración de la que dicha información de enrutamiento se mantiene con la funcionalidad BGP reinicio correcto.

Históricamente, los protocolos de enrutamiento y BGP, en particular, se diseñaron con un enfoque en la corrección, en el que 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 este motivo, el protocolo se diseñó para quitar el estado anunciado por enrutadores que se desactivaron (desde el BGP punto de vista) tan rápidamente como sea posible. Si se utiliza BGP reinicio normal definido en el documento RFC 4724, la funcionalidad de convergencia rápida ha sido un intento de quitar rápidamente de la red el estado "obsoleto".

Durante un periodo de tiempo, dos factores que contribuyen han provocado que este método de extracción rápida de Estados obsoletos se modifique y se pueda mejorar. La primera es la adopción generalizada de infraestructuras de reenvío de túnel, por ejemplo MPLS. Estas infraestructuras eliminan el riesgo de algunos tipos de bucles de reenvío que pueden producirse en el reenvío salto a salto y, por lo tanto, reducen una de las motivaciones de una sólida coherencia entre los elementos de reenvío. El segundo es el uso cada vez mayor de BGP como transporte de los datos menos estrechamente relacionados con el reenvío de paquetes que originalmente en el caso. Algunos ejemplos son el uso de BGP para AutoDiscovery (VPLS [RFC4761]) y filtrar la programación (FLOWSPEC [RFC5575]). En estos casos, BGP datos 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 optar por conservar BGP datos durante un periodo más largo cuando el BGP plano de control falle por alguna razón. Aunque las propiedades de BGP reinicio sin problemas se aproximan a este requisito para conservar la información de BGP durante más tiempo, existen varias lagunas, en particular en el plazo máximo para el cual se puede conservar 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 normal de larga duración para que la información obsoleta se pueda conservar durante más tiempo durante el restablecimiento de la sesión. También es compatible con una nueva comunidad BGP, "LLGR_STALE", para marcar dicha información. Esta información obsoleta debe considerarse como lo menos preferida y su anuncio está limitado a BGP altavoces que admiten la nueva capacidad.

BGP un reinicio normal de larga duración (LLGR) permite a un operador de red elegir mantener la información de enrutamiento obsoleta de un par BGP con errores mucho más larga que la utilidad de reinicio normal BGP existente. Esta funcionalidad para mantener las rutas de BGP durante un período de tiempo mayor es conforme al borrador de GTI-I, compatibilidad con un reinicio de larga duración BGP sin problemas, borrador uttaro-IDR-BGP-Persistence-03. Según este borrador, el reinicio correcto de larga duración (LLGR) debe configurarse explícitamente por NLRI e incluye disposiciones para impedir la propagación de información obsoleta a otros iguales que no reconocen ni validan LLGR. Los siguientes beneficios y operaciones están causados por LLGR:

  • Las rutas de los nodos con errores se conservan durante un período de tiempo configurado (en el orden de los días).

  • Puede examinar los Estados de negociación de LLGR por NLRI utilizando los comandos de mostrar apropiados.

  • Puede ver si LLGR está en vigor actualmente para un interlocutor y si es efectivo, el período tras el cual vence.

  • Las rutas obsoletas retenidas por LLGR se marcan explícitamente en la salida del show bgp neighbor comando.

  • Las rutas obsoletas obtenidas de otros vecinos se marcan explícitamente show bgp neighbor en la salida del comando (utilizando comunidades bien definidas).

Aunque la metodología LLGR se puede aplicar a varios escenarios distintos, un escenario específico es el objetivo de esta característica. En una situación en la que se produce una pérdida de conectividad entre un reflector y un cliente, incluida una conectividad intermitente que puede hacer que se restablezca una conexión antes de que pueda transmitirse el nervio completo, un fallo de este tipo no produce un reinicio. Además, un fenómeno de este tipo no significa que exista cualquier problema de conectividad entre los clientes y los próximos saltos anunciados por el reflector de enrutamiento. Se prevé que una hora de reinicio típica de larga duración es del orden de 12 horas.

Se admiten todas las directrices de comportamiento y los puntos operativos descritos en el GTI-I draft, draft-uttaro-IDR-BGP-Persistence-03, para LLGR. Además, se admite la compatibilidad con las funciones de Junos OS existentes en las versiones anteriores a la 15,1, en concreto el reinicio correcto y el enrutamiento nonstop (INE). Cuando se configura LLGR, el reinicio normal funciona de la manera existente, con excepción de lo que se muestra explícitamente en el borrador de Internet. También puede configurar tanto LLGR como INE al mismo tiempo y conseguir la funcionalidad de LLGR completa. Como requisito previo para LLGR, se implementa la compatibilidad con el borrador de GTI-I, la compatibilidad con mensajes de notificación para BGP reinicio correcto (draft-ietf-IDR-BGP-gr-Notification-01). Este borrador extiende el comportamiento de los GR ordinarios para permitirle proteger contra interrupciones de la comunicación y errores de protocolo.

Configuración del período máximo para la generación automática de BGP keepalive mediante temporizadores después del cambio

En Junos OS, el enrutamiento activo no detenido (INE) utiliza la misma infraestructura que el cambio de motor de enrutamiento correcto (con entrada) para conservar la información de interfaz y de núcleo. Sin embargo, INE también ahorra información de protocolos de enrutamiento mediante la ejecución del proceso de protocolo de enrutamiento (RPD) en el motor de enrutamiento de copia de seguridad. Al guardar esta información adicional, la INE es independiente y no se basa en enrutadores (o conmutadores) auxiliares para ayudar a la plataforma de enrutamiento en la restauración de la información del Protocolo de enrutamiento. La INE es una ventaja para las redes en las que los enrutadores vecinos (o conmutadores) no admiten extensiones de protocolo de reinicio normal. Como resultado de esta funcionalidad mejorada, INE es un reemplazo natural de un reinicio correcto.

Enrutamiento activo sin interrupciones es uno de los componentes de kernel de la replicación del socket. Durante el cambio, este componente fusiona los pares de conexión de forma automática desde la copia de seguridad hasta el motor de enrutamiento. El cambio de NSR de copia de seguridad a principal se produce cuando rpd emite una llamada de fusión para cada par de conector secundario para fusionarlos en un solo conector, lo que podría ocasionar una demora. Para evitar este retraso, un módulo de combinación automática del núcleo desacopla la combinación de sockets secundarios de RPD y combina automáticamente los sockets secundarios en el cambio para que el subproceso de alta prioridad RPD se beneficie de esto y genere un keepalive más rápido para mantener el protocolo TCP. conexiones en el cambio.

De forma predeterminada, BGP no se registra en el servicio de generación automática de keepa live que proporciona el kernel justo después del evento de conmutación de copia de seguridad a principal. Para esto, debe activar la instrucción en nonstop-routing-options el nivel [edit routing-options] Hierarchy y configurar los temporizadores de precisión en BGP. La configuración de temporizadores de precisión en BGP permite que BGP registre todas sus sesiones con el servicio de generación de KeepAlive automático proporcionado por el kernel. Una vez registrado, el núcleo genera automáticamente keepa lives utilizando sus temporizadores en nombre de BGP para sus sesiones de control justo después del evento de cambio de copia de seguridad a principal. Esto permite la generación de Keepalives más confiables para las sesiones de control con temporizadores muy pequeños durante el evento de cambio.

Interoperación de funcionalidades con BGP reinicio correcto de larga duración

Este tema contiene las siguientes secciones que describen el comportamiento de trabajo de diferentes funciones con BGP reinicio correcto y las distintas condiciones del sistema:

A partir de Junos OS versión 15,1, Junos OS admite el mecanismo para conservar BGP datos de enrutamiento durante un período más largo de una par BGP errónea que la duración de dicha información de enrutamiento con BGP funcionalidad de reinicio correcto.

Limitaciones de NLRIs compatibles

LLGR la negociación de la configuración y la capacidad de la red es compatible con las BGP siguientes familias de información de accesibilidad en el nivel de las redes (NLRI):

  • l2vpn

  • inet con etiqueta de unidifusión

  • flujo de inet

  • ruta-destino

  • inet-VPN unicast

  • inet-flujo de VPN

  • inet6: unidifusión VPN

Se impide la negociación de la configuración y la capacidad de LLGR para las familias siguientes:

  • inet-mvpn

  • inet6-mvpn

  • inet-MDT

Para las familias NLRI para las que se impide la LLGR capacidad, indica que se rechaza un intento de confirmar una configuración que incluya una configuración LLGR para estas familias, por lo que dicha configuración no se guardará. Los NLRIs asociados con estas familias no se incluyen en un anuncio de capacidades de LLGR, por lo que no se tienen en cuenta en un anuncio de capacidades LLGR recibido.

LLGR se permite la negociación de la configuración y la capacidad de las otras familias, pero está oculta.

Modo de reinicio LLGR bajo INE

Cuando INE y LLGR se configuran juntos, el enrutador negocia la capacidad LLGR de la forma habitual, incluida una hora obsoleta de larga duración para activar LLGR modo receptor en sus colegas. Sin embargo, la funcionalidad completa del reinicio del LLGR (retraso de la transmisión de los marcadores de fin de las COSTILLAs hasta que EoRs se recibe de todos los interlocutores) no funciona en INE. Durante el reinicio de un sistema completo (ambos motores de enrutamiento), el demonio de protocolo de enrutamiento (RPD) no espera EoRs de otros homólogos antes de enviar su propio EoR. Transmite la EoR tan pronto como haya transmitido el contenido de las COSTILLAs. Esta condición puede provocar interrupciones transitorias cuando la red vuelve a converger. Se considera que INE es adecuado para gestionar todos los escenarios de reinicio de una sola motor de enrutamiento. La restricción del modo de reinicio sólo afecta a los escenarios donde 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 INE.

La configuración ordinaria del modo de reinicio sin problemas sigue siendo incompatible con INE.

Capacidad de LLGR en niveles de vecinos, globales, BGP y BGP

El modo receptor de reinicio correcto de larga duración está habilitado de forma predeterminada, a menos que esté deshabilitado el modo receptor normal de reiniciar. Para habilitar la BGP función de reinicio correcto y sin problemas de vida útil ( long-lived receiver enable LLGR), [edit protocols bgp graceful-restart] incluya la instrucción en el nivel jerárquico. Aparte de permitir BGP LLGR en el nivel global o de todo el sistema, también puede incluir la instrucción enable Receiver de vida prolongada [edit protocols bgp group group-name graceful- restart] en el nivel de la jerarquía para configurar LLGR para un grupo de [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] BGP determinado y en el nivel de jerarquía para configurar LLGR para un en particular BGP vecino. Para deshabilitar el mecanismo de LLGR de la long-lived receiver disable BGP, [edit protocols bgp graceful-restart]incluya [edit protocols bgp group group-name graceful-restart]la opción, o [modificar protocolo BGP de grupo o nombre-Grupo-dirección vecina-reinicio correcto]. Al deshabilitar LLGR se desactivan todas las capacidades del LLGR (modos de receptor y de reinicio) para todas las familias de NLRI. Los grupos heredan esta propiedad de la configuración global y los vecinos de la configuración del grupo.

Supervisar y administrar BGP reinicio correcto de larga duración

Este tema describe los comandos operativos y su importancia para permitirle analizar y ver los parámetros relacionados con BGP reinicios correctos y de larga duración. Puede analizar los contadores estadísticos y las métricas relacionadas con cualquier pérdida de tráfico y adoptar una medida correctiva adecuada. Los campos mostrados en el resultado de los comandos show ayudan a diagnosticar y depurar los problemas de rendimiento de la red y eficacia de control de tráfico.

El clear bgp neighbor neighbor-address stale-routes causa cualquier ruta obsoleta que se esté reteniendo actualmente para el vecino especificado debido a operaciones del modo de receptor con un reinicio normal (gr) o un reinicio correcto de larga duración (LLGR). El clear bgp neighbor neighbor-address gracefully comando es el mismo que clear bgp neighbor hard (valor predeterminado para clear bgp neighbor), pero no utiliza el nuevo subcódigo de restablecimiento duro en los mensajes Notify y Cesar que se envían. Esto permite al vecino entrar en modo auxiliar GR o LLGR, si se negocia. La sesión se sigue borrando en este enrutador y este enrutador no entra en modo ayudante GR o LLGR.

Se puede clear agregar un comando oculto para la capacidad de reinicio normal de BGP largo con fines de depuración:

clear bgp neighbor neighbor-address socket.

Este comando rompe la conexión TCP de una sesión de intercambio de tráfico establecida. Ésta es la única implicación directa del comando y todas las demás implicaciones son efectos secundarios de la conexión que se está interrumpiendo. El efecto resultante es que (a menos que se hayan deshabilitado los propietarios de las extensiones de notificación) ambos lados de la conexión entrarán en modo auxiliar GR o LLGR, si se negoció, y se volverá a establecer la conexión TCP.

La salida del show bgp neighbor comando se ha mejorado para mostrar la siguiente información adicional:

  • Opción de reinicio correcto de larga duración

  • Los parámetros LLGR que el elemento del mismo nivel ha negociado

  • Los parámetros LLGR que el enrutador de reinicio ha negociado

  • Las horas se muestran con el demonio de protocolo de enrutamiento (RPD)% #0T formato:

    <weeks>w<days>d <hours>:<minutes>:<seconds>

    Los elementos de cero a la izquierda se omiten, por ejemplo, un valor inferior a una semana no incluye las semanas.

Si el reinicio correcto de larga duración está completamente deshabilitado para un vecino, se muestra lo siguiente:

Si un vecino no admite LLGR completamente, se muestra lo siguiente:

Mientras esté activo el modo de receptor LLGR (un sistema del mismo nivel que negoció LLGR se ha desconectado y aún no se ha reconectado show bgp neighbor ), la salida del comando muestra la cantidad de tiempo restante hasta que la LLGR caduca, el tiempo restante del temporizador de gr obsoletos y los detalles de la costilla.:

Cuando BGP modo de receptor de reinicio sin problemas está activo para un vecino, se mostrará información adicional en show bgp neighbor el resultado del comando. Estos detalles incluyen la lista de NLRIs de que se retienen las rutas obsoletas durante (NLRI se encuentran rutas obsoletas para el campo), el tiempo restante en el temporizador de reinicio (tiempo hasta que se eliminan rutas obsoletas o se convierte en un campo obsoleto de larga duración), el tiempo restante del temporizador obsoleto ( Tiempo hasta que se asumen las rutas obsoletas de fin de la costilla.) y los detalles de las COSTILLAs. La hora se muestra en formato de hora universal coordinada (UTC) (AAAA-MM-DD-HH: MM: SS). Observe que la pantalla del temporizador obsoleto (' hasta el fin de la costilla de nervio ') también está presente cuando una sesión está activa, pero el vecino no envió todavía todas las indicaciones de fin de la costilla.

Ahora, cuando el modo de aplicación auxiliar o el reinicio LLGR está activo, la información sobre show bgp summary los nervio se muestra en el comando. 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 de amortiguación 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 las rutas activas, 10 rutas recibidas, 10 rutas aceptadas y 2 rutas amortiguadas de un par BGP aparecen en la tabla de enrutamiento inet. 0.

  • 2 las rutas activas, 4 rutas recibidas, 4 rutas aceptadas y no hay ninguna ruta amortiguada de un par BGP aparecen en la tabla de enrutamiento inet. 2.

El show route detail comando (con y sin la receive-protocol bgp opción) se ha mejorado para identificar rutas que se encuentran en un estado obsoleto de larga duración. La LongLivedStale marca indica que la ruta estaba marcada LLGR-obsoleta por este enrutador, como parte del funcionamiento del modo receptor LLGR. La LongLivedStaleImport marca indica que la ruta estaba marcada LLGR-obsoleto cuando se recibió de un interlocutor o la Directiva de importación. Puede que se muestre una o ambas marcas para una ruta. Ninguna de estas marcas se mostrará al mismo tiempo que la marca obsoleta (el antiguo GR obsoleto). Si una ruta es de despreferencia porque su duración es obsoleta, el campo motivo inactivo de la salida del comando Mostrar detalle de ruta muestra LLGR obsoleto. La razón de inactividad nueva LLGR obsoleta encaja en la jerarquía de selección de rutas entre la preferencia y la preferencia local.

Consejo:

De acuerdo con el Juniper centro de asistencia técnica (JTAC), un comando útil para ayudar a solucionar problemas relacionados con BGP reinicio correcto de show route table bgp.l2vpn.0 detail hidden larga duración es el comando. El resultado del comando ayuda a detectar si el BGP rutas sigue existiendo después de que haya finalizado la sesión de BGP. El uso de hidden esta opción le permite ver las rutas durante y después de un incidente, y descubrir información que explica por qué se ocultan las rutas. Otras pistas que ayudan a solucionar problemas de este escenario incluyen la apariencia de entradas de registro obsoletas BGP bgp_mark_route_stale(como) y las rutas ocultas que aparecen en el show bgp summary resultado del comando.

Aumentar la duración de la conservación de BGP rutas en los interlocutores que se reinician lentamente mediante BGP reinicio correcto de larga duración

Junos OS admite el mecanismo para conservar BGP detalles de enrutamiento durante un período más largo de un par BGP con errores que la duración de la que dicha información de enrutamiento se mantiene con la funcionalidad BGP reinicio correcto.

El modo receptor de reinicio correcto de larga duración está habilitado de forma predeterminada, a menos que esté deshabilitado el modo receptor normal de reiniciar. Para habilitar la BGP función de reinicio correcto y sin problemas de vida útil ( long-lived receiver enable LLGR), [edit protocols bgp graceful-restart] incluya la instrucción en el nivel jerárquico. Aparte de permitir BGP LLGR en el nivel global o de todo el sistema, también puede incluir la instrucción enable Receiver de vida prolongada [edit protocols bgp group group-name graceful-restart] en el nivel de la jerarquía para configurar LLGR para un grupo de [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] BGP determinado y en el nivel de jerarquía para configurar LLGR para un en particular BGP vecino. Para deshabilitar el mecanismo de LLGR de la long-lived receiver disable BGP, [edit protocols bgp graceful-restart]incluya [edit protocols bgp group group-name graceful-restart]la opción, o [modificar protocolo BGP de grupo o nombre-Grupo-dirección vecina-reinicio correcto]. Al deshabilitar LLGR se desactivan todas las capacidades del LLGR (modos de receptor y de reinicio) para todas las familias de NLRI. Los grupos heredan esta propiedad de la configuración global y los vecinos de la configuración del grupo.

BGP vecinos se pueden configurar en los siguientes niveles de jerarquía:

  • [edit protocols bgp group group-name]: Sistema lógico predeterminado y 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 configurada y 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.

La long-lived receiver enable anulación de una opción de deshabilitación heredada de un nivel superior de la configuración. No permite el modo de reinicio sin problemas y 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 LLGR se anuncien a los vecinos que no anuncian la capacidad LLGR, advertise-to-non-llgr-neighbor incluya la instrucción [edit protocols bgp graceful-restart long-lived]en [edit protocols bgp group group-name graceful-restart long-lived]el nivel [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] de jerarquía, o. Esta opción se aplica a las rutas marcadas por el enrutador LLGR-obsoletas y LLGR de rutas obsoletas recibidas de vecinos. Idealmente, todos los enrutadores de un sistema autónomo admiten la especificación de borrador de IETF antes de habilitarse. Sin embargo, para facilitar la implementación incremental, es posible que sea necesario anunciar las rutas obsoletas a los vecinos que no han anunciado la capacidad de reinicio correcto de larga duración en las condiciones siguientes: Los vecinos deben ser vecinos (IBGP o Confederación) internos. La comunidad NO_EXPORT debe adjuntarse a las rutas obsoletas. Las rutas obsoletas deben tener su atributo LOCAL_PREF establecido a cero. Si se usa esta técnica para la implementación parcial, debe establecer LOCAL_PREF en cero para todas las rutas LLGR en todo el sistema autónomo. Esta configuración disociará una pequeña reducción de la flexibilidad (es posible que la ordenación no se mantenga entre las rutas de los LLGR de la competencia) por coherencia entre los enrutadores que admiten y no admitan esta especificación. Dado que la coherencia de la selección de rutas puede ser importante para evitar los bucles de reenvío, esta última consideración sobre los enrutadores que no admiten esta especificación precede.

Para evitar que la comunidad no-Export BGP se agregue automáticamente a las rutas anunciadas a los vecinos de BGP externos (supuestamente enrutadores CE), incluya omit- no-export la instrucción en [edit protocols bgp graceful-restart long-lived]el [edit protocols bgp group group-name graceful-restart long-lived]nivel de [edit protocols bgp group group-name neighbor neighbor-address graceful-restart long-lived] jerarquía, o. En las implementaciones de VPN, por ejemplo, BGP se utiliza a menudo como protocolo PE-CE. Puede ser una necesidad práctica de estas implementaciones para acomodar la interoperabilidad con CEs que no puede actualizarse fácilmente para admitir especificaciones como ésta. Este requisito causa un problema, mientras se 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 caso de que uno o varios enrutadores IBGP no se actualicen. En el caso de VPN PE-CE, el protocolo en uso es EBGP y LOCAL_PREF, un atributo de ruta de acceso de sólo IBGP, se utiliza. La motivación principal para restringir la propagación de información de enrutamiento "obsoleta" es la razón para evitar que se extienda sin límites una vez que salga del límite de la BGP de la Confederación. Las implementaciones de VPN suelen estar restringidas de la topología, lo que elimina este problema. Por esta razón, una implementación podría anunciar rutas obsoletas a través de una sesión de PE-CE, cuando se configure explícitamente. En este caso, la implementación debe adjuntar la comunidad NO_EXPORT a las rutas en cuestión de forma predeterminada, como protección adicional frente a las rutas obsoletas que se propagan sin límite. La Unión de la comunidad NO_EXPORT puede deshabilitarse de forma explícita para acomodar casos excepcionales. Puede que sea 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 PE para anunciar estas rutas, debe notificar al operador que la recibe la CE y debe configurarse para que detenga las rutas. Las implementaciones de BGP típicas realizan esta operación haciendo coincidir en la comunidad LLGR_STALE, y estableciendo la LOCAL_PREF para hacer coincidir las rutas con cero.

Cuando el modo de receptor LLGR está habilitado o deshabilitado, la sesión se restablece. Este comportamiento permite que se envíe el nuevo valor de capacidad al vecino. Cuando la advertise-to-non-llgr-neighbor opción está habilitada o deshabilitada, la Directiva de exportación se vuelve a evaluar y LLGR las rutas obsoletas se pueden anunciar o retirar. Cuando se omit-no-export agrega o quita la opción, la sesión se restablece. En este resto de una sesión se permite que LLGR rutas obsoletas se reanuncien con o sin la comunidad no-Export (que se agrega fuera de la política de exportación).

Para permitir el BGP capacidad de reinicio correcto de larga duración en el nivel de sistema o global y configurar sus propiedades:

Para habilitar la BGP capacidad de reinicio correcto de larga duración en el nivel de grupo BGP y configurar sus propiedades:

Para permitir el BGP capacidad de reinicio correcto de larga duración en el nivel de grupo de vecinos o compañeros y configurar sus propiedades:

Configuración de BGP las comunidades de reinicio correcto de larga duración en las políticas de enrutamiento

Junos OS admite el mecanismo para conservar BGP detalles de enrutamiento durante un período más largo de un par BGP con errores que la duración de la que dicha información de enrutamiento se mantiene con la funcionalidad BGP reinicio correcto.

Se introducen dos nuevas comunidades conocidas. Estas nuevas comunidades de BGP se pueden utilizar en cualquiera de los niveles de jerarquías de configuración como otras comunidades simbólicas conocidas (como publicidad no anunciada, sin exportación y sin exportación) en el atributo comunitario de definiciones de ruta estática o en una opción de políticas definición comunitaria. Las dos nuevas comunidades son las siguientes:

  • llgr-stale: Agrega una comunidad a una ruta obsoleta de larga duración cuando se reanuncia.

  • no-llgr: Marca las rutas que no desea que LLGR retenga un anunciador BGP. La función mensaje de notificación no tiene ningún parámetro de configuración asociado.

Puede incluir las opciones llgr-stale y no-llgr con la community name members instrucción para asociar BGP información de la comunidad con una ruta estática, agregada o generada a los siguientes niveles de jerarquía:

Para configurar las BGP las comunidades de reinicio correcto de larga duración para usarlas en una condición de coincidencia de directiva de enrutamiento:

La configuración de LLGR no requiere que también se configure BGP reinicio correcto. Los valores para las comunidades llgr y obsoletas llgr son 0xFFFF0006 y 0xFFFF0007 respectivamente. Los privilegios son los mismos que para los protocolos BGP. La sección de larga duración de reinicio solo es visible para las familias l2vpn, inet con etiqueta unicast, flujo de inet y destino de enrutamiento. Está prohibido para inet-mvpn, inet6-mvpn e inet-MDT. Está oculta para otras familias.

Junos OS también proporciona compatibilidad con la configuración de una directiva de exportación BGP que coincida con el estado de una ruta BGP un reinicio correcto y de larga duración. Puede asociar la comunidad definida anteriormente y una lista de prefijos de direcciones en una directiva de enrutamiento para aceptar o rechazar selectivamente las rutas del reinicio correcto de larga duración para los prefijos especificados, de la siguiente manera:

Se agregan dos instrucciones de configuración ocultas en el nivel de jerarquía para la [edit protocols bgp graceful-restartconfiguración global, a nivel de grupo y a nivel de grupo vecino.

La disable-notification-flag instrucción en el [edit protocols bgp graceful-restart]nivel [edit protocols bgp group group-name graceful-restart]de jerarquía [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] , o deshabilita la transmisión del indicador N en la negociación de la capacidad de reinicio correcto. La disable-notification-extensions instrucción en el [edit protocols bgp graceful-restart]nivel [edit protocols bgp group group-name graceful-restart]de jerarquía [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] , o, también deshabilita la transmisión del indicador N en la negociación de la capacidad de reinicio correcto, pero además deshabilita las nuevas reglas para invocar el modo de receptor de reinicio normal como especificada en el borrador de notificación de BGP-gr-IETF, y deshabilita la transmisión del subcódigo de restablecimiento duro. El subcódigo de restablecimiento duro sigue siendo observado cuando se recibe en un mensaje Notify o cese.

Para deshabilitar la transmisión de N indicadores y deshabilitar las reglas para activar el reinicio correcto en el nivel global o de todo el sistema:

Para deshabilitar la transmisión de N indicadores y deshabilitar las reglas para activar un reinicio correcto en el nivel de Grupo:

Para deshabilitar la transmisión de N indicadores y deshabilitar las reglas para activar el reinicio correcto en el nivel de vecino o de homólogo:

Configuración de la negociación del modo de reinicio correcto de larga duración para una familia específica de direcciones en sistemas lógicos y instancias de enrutamiento

Junos OS admite el mecanismo para conservar BGP detalles de enrutamiento durante un período más largo de un par BGP con errores que la duración de la que dicha información de enrutamiento se mantiene con la funcionalidad BGP reinicio correcto.

También puede configurar el mecanismo de negociación de modo de reinicio correcto BGP de larga duración para una determinada familia de direcciones en lugar de configurar esta capacidad para todas las familias de direcciones de un sistema, un sistema lógico o una instancia de enrutamiento. Para activar BGP LLGR para una familia específica de direcciones, incluya graceful-restart long-lived restarter stale-time interval la instrucción en uno de los siguientes niveles de jerarquía.

Cada tabla de enrutamiento se identifica por la familia de protocolos o el indicador de familia de direcciones (AFI) y un identificador subsiguiente de familia de direcciones (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 (flow | labeled-unicast) protocolos de la familia inet y uno de (auto-discovery-mspw | auto-discovery-only | signaling) los protcols para L2VPN familia..

La configuración de LLGR no requiere que también se configure BGP reinicio correcto. La sección de larga duración de reinicio solo es visible para las familias l2vpn, inet con etiqueta unicast, flujo de inet y destino de enrutamiento. Está prohibido para inet-mvpn, inet6-mvpn e inet-MDT. Está oculta para otras familias.

El stanzas de la sección de configuración de reinicio correctos de inicio sin problemas de la familia, permite la negociación del modo de reiniciar el LLGR para el BGP globalmente o para un grupo o vecino. Los grupos heredan los valores de la configuración global y, a partir de la configuración del grupo, los vecinos. El atributo Disable se utiliza para invalidar la configuración heredada de un nivel superior. No deshabilita el modo de receptor LLGR; debe desactivar el modo de receptor LLGR de forma explícita para todas las familias según sea necesario. Un atributo enable oculto se puede utilizar para reemplazar un atributo deshabilitado heredado. Configurar el reinicio sin problemas reiniciador de larga duración en el nivel de vecino (cuando no se configura en el nivel de grupo contenedor o globalmente) provoca la división de un grupo interno. Cuando se habilita o deshabilita un reinicio de LLGR para una familia o se cambia la hora obsoleta, la sesión se restablece para que la nueva capacidad pueda enviarse al vecino.

El intervalo de valores para el tiempo obsoleto es de 1 a 16777215 (2 ^ 24 – 1) segundos. El valor es un entero sencillo que da el número de segundos de forma predeterminada, pero también se puede especificar utilizando la notación siguiente:

[<mandas>w] [<d.>d] [< hora>h] [<minutos>m] [< segundos>] 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 agregan a los segundos para obtener el total. Se permite un formato combinado de días y horas en distintas unidades del período de tiempo, como 1d36h, siempre y cuando el total especificado no supere el tiempo máximo obsoleto.

Además, las horas también se pueden configurar mediante la siguiente notación: < hora>:<minutos>:<segundos> Por ejemplo, 12:00: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 en torno a un valor de este tipo con espacios en él.) 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 Mostrar configuración muestra los valores configurados realmente, cuando se muestran los temporizadores asociados en comandos show en tiempo show bgp neighborde ejecución, como, los valores se normalizan, como 1d36h se convierte en 2D 12:00:00. Las reglas completas para mostrar tiempos de LLGR normalizados dependen de clear bgp neighbor neighbor-address gracefully la configuración de los comandos.

Para configurar las BGP características de reinicio correcto de larga duración por familia y familias de direcciones por subsiguientes en el nivel global para un sistema lógico o una instancia de enrutamiento:

Configuración de BGP reinicio correcto de larga duración por familia de direcciones a nivel global para los sistemas lógicos

Configuración de BGP reinicio correcto de larga duración por familia de direcciones en el nivel global para las instancias de enrutamiento

Para configurar las BGP características de reinicio normal de larga duración por dirección y familia de direcciones por subsiguientes en el nivel de grupo BGP para un sistema lógico o una instancia de enrutamiento:

Configuración de BGP reinicio correcto de larga duración por familia de direcciones en el nivel de grupo BGP para los sistemas lógicos

Configuración de BGP reinicio correcto de larga duración por familia de direcciones en el nivel de grupo BGP para las instancias de enrutamiento

Para configurar las BGP características de reinicio correcto de larga duración por familia y familia de direcciones por subsiguientes en el BGP nivel de grupo vecino para un sistema lógico o una instancia de enrutamiento:

Configurar BGP un reinicio correcto y duradero por familia de direcciones en el BGP nivel de grupos vecinos para los sistemas lógicos

Configuración de BGP reinicio correcto de larga duración por familia de direcciones en el BGP nivel de grupos vecinos para instancias de enrutamiento

Informar al enrutador auxiliar o BGP al mismo nivel acerca de 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 específica de direcciones

Junos OS admite el mecanismo para conservar BGP detalles de enrutamiento durante un período más largo de un par BGP con errores que la duración de la que dicha información de enrutamiento se mantiene con la funcionalidad BGP reinicio correcto.

Después de que la sesión de BGP se interrumpe y antes de que se restablezca la sesión, las rutas obsoletas se pueden conservar durante un máximo de dos periodos consecutivos, controlados por los parámetros de hora de reinicio y hora obsoleta de larga duración, respectivamente. Durante el primer período, se impiden las modificaciones de enrutamiento, pero con un posible filtrado de ruta nula del tráfico. Durante el segundo período, es posible que se reduzca el posible filtrado de rutas nulas del tráfico, pero los cambios de enrutamiento son visibles en toda la red. En su entorno de red, el establecimiento de los parámetros relevantes para una aplicación concreta debe tener en cuenta las compensaciones, la dinámica en la red y las situaciones de posibles errores. Si es necesario, el primer período puede omitirse por configuración local o estableciendo la hora de reinicio en cero de forma correcta, no enumerando los indicadores de la familia de direcciones (AFI) y los identificadores de familias de direcciones posteriores (SAFI) en ese capacidad.

La configuración de la bit F (y el bit "estado de reenvío" de la capacidad GR de acompañamiento) depende en parte de las consideraciones relativas a la implementación. El bit de F se puede interpretar para indicar que el enrutador auxiliar debe vaciar las rutas asociadas (si el bit se deja claro). Una situación importante en la que se utiliza LLGR es para rutas más parecidas a las de configuración que al enrutamiento tradicional (envío salto a salto en lugar de enrutamiento basado en túnel). Para estas rutas, podría ser útil establecer siempre el bit F, independientemente de otras consideraciones. Del mismo modo, para entidades de control-plano, como los catadióptricos de ruta dedicados, que no participan en el plano de envío, es preferible que siempre se establezca el bit F. En general, la orientación que se debe 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 se debe establecer de manera juiciosa dependiendo de si se ha mantenido el estado. Puede determinar si es necesario establecer o no el bit F, en función de sus necesidades de implementación y las opciones configuradas. Puede que sea necesario anunciar rutas obsoletas a un CE en algunas implementaciones de VPN, incluso si el CE no admite esta especificación. En este escenario, el operador de red que configura su PE para que anuncie que estas rutas debe notificar al operador que está recibiendo las rutas y se debe configurar el CE para que detenga 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 con cero.

Puede especificar el bit de estado de reenvío, que es una BGP opción de configuración que se puede definir a nivel global, de grupo y de vecino, para cualquier instancia de sistema o de enrutamiento lógico. Para especificar el bit de estado de reenvío en el nivel global, de BGP o de BGP vecino, forwarding-state-bit (as-rr-client | from-fib) incluya la instrucción [edit protocols bgp graceful-restart]en [edit protocols bgp group-group-name graceful-restart]el nivel [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart] de jerarquía, o. El atributo de bits de estado de reenvío controla cómo se establece el bit de estado de reenvío tanto en el reinicio correcto como en los anuncios 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 rutas. Si el vecino no es un cliente de reflector de enrutamiento, el valor se establece de acuerdo con el estado del FIB asociado en conformidad con RFC 4724. Si el vecino es un cliente de reflector de enrutamiento, el valor se establece en 1 para todas las familias, excepto en el caso de unidifusión de inet y una 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 para que sean iguales a la funcionalidad de un cliente de reflector de enrutamiento. Esta from-fib opción hace que el comportamiento de todas las familias de direcciones sea como si fuera un cliente de reflector que no sea de enrutamiento.

Para configurar la negociación del indicador de estado de reenvío en el nivel global:

Para configurar la negociación del indicador de estado de reenvío en el nivel de Grupo:

Para configurar la negociación del indicador de estado de reenvío en el nivel de grupo de vecinos o compañeros:

Además de la configuración global del bit de estado de reenvío, se puede especificar el comportamiento de bits del estado de reenvío para familias individuales. Cambiar el reenvío: la configuración de bits no afecta a ninguna sesión existente. Para especificar el bit de estado de reenvío de una familia de direcciones determinada forwarding-state-bit (set | from-fib) , incluya la [edit protocols bgp graceful-restart family address-family subsequent-address-family]instrucción [edit protocols bgp group-group-name graceful-restart family address-family subsequent-address-family]en el [edit protocols bgp group-group-name neighbor neighbor-address graceful-restart family address-family subsequent-address-family] nivel de jerarquía, o en un sistema lógico y una instancia de enrutamiento. Las opciones de configuración de BGP por familia se agregan para controlar el bit de estado de reenvío en los anuncios de capacidad de reinicio normal y de reinicio correcto de larga duración. Se pueden especificar para el sistema lógico predeterminado o para un sistema lógico específico, así como para la instancia de enrutamiento principal o una instancia de enrutamiento específica. El per-family forwarding-state-bit atributo invalida 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 de estado de reenvío se establezca en 1. La from-fib opción hace que el valor se establezca de acuerdo con el estado del FIB asociado. Cambiar el reenvío por serie: la configuración de bits de estado no surte ningún efecto en las sesiones existentes.

A continuación se muestran los niveles de jerarquías de configuración completos en los forwarding-state-bit (set | from-fib) que puede incluir la instrucción para configurar el bit de reenvío por familia de direcciones:

Para configurar el bit de reenvío para BGP familia de reinicio correcto por dirección y de la familia de direcciones por subsiguientes en el 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 en el nivel global para los sistemas lógicos

Configuración del bit de estado de reenvío por familia de direcciones en el nivel global para las instancias de enrutamiento

Para configurar el bit de reenvío para BGP familia de reinicio correcto por dirección y de la familia de direcciones por las subsiguientes 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 los sistemas lógicos

Configuración del bit de estado de reenvío por familia de direcciones en el nivel de grupo BGP para las instancias de enrutamiento

Para configurar el bit de reenvío para BGP familia de reinicio correcto por dirección y de la familia de direcciones por subsiguientes en el BGP nivel de grupo vecino para un sistema lógico o una instancia de enrutamiento:

Configurando el bit de reenvío por familia de direcciones en el BGP nivel de grupos vecinos para los sistemas lógicos

Configurar el bit de reenvío para la familia de direcciones en el BGP nivel de los grupos vecinos para las instancias de enrutamiento

Ejemplo Conservación de los detalles de ruta para los BGP pares más lentos y latentes mediante el uso de BGP reinicio correcto de larga duración

Junos OS admite el mecanismo para conservar BGP detalles de enrutamiento durante un período más largo de un par BGP con errores que la duración de la que dicha información de enrutamiento se mantiene con la funcionalidad BGP reinicio correcto.

Históricamente, los protocolos de enrutamiento y BGP, en particular, se diseñaron con un enfoque en la corrección, en el que 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 este motivo, el protocolo se diseñó para quitar el estado anunciado por enrutadores que se desactivaron (desde el BGP punto de vista) tan rápidamente como sea posible. Si se utiliza BGP reinicio normal definido en el documento RFC 4724, la funcionalidad de convergencia rápida ha sido un intento de quitar rápidamente de la red el estado "obsoleto".

BGP un reinicio normal de larga duración (LLGR) permite a un operador de red elegir mantener la información de enrutamiento obsoleta de un par BGP con errores mucho más larga que la utilidad de reinicio normal BGP existente. Esta funcionalidad para mantener las rutas de BGP durante un período de tiempo mayor es conforme al borrador de GTI-I, compatibilidad con un reinicio de larga duración BGP sin problemas, borrador uttaro-IDR-BGP-Persistence-03. Según este borrador, el reinicio correcto de larga duración (LLGR) debe configurarse explícitamente por NLRI e incluye disposiciones para impedir la propagación de información obsoleta a otros iguales que no reconocen ni validan LLGR.

En este ejemplo se describe cómo configurar BGP funcionalidad de reinicio correcto de larga duración en enrutadores serie MX, y se incluyen las secciones siguientes:

Aplicables

En este ejemplo se utilizan los siguientes componentes de hardware y software:

  • Un enrutador de la serie MX con una MPC.

  • Junos OS versión 15.1 R1 o posterior para enrutadores serie MX

Antes de configurar BGP reinicio correcto de larga duración, asegúrese de lo siguiente:

  1. Configure las interfaces del dispositivo.

  2. Configure BGP.

Descripción general

El reinicio correcto permite que un dispositivo de enrutamiento se reinicie para informar a sus vecinos y compañeros de su estado adyacentes. Durante un reinicio correcto, el dispositivo de reinicio y sus vecinos siguen reenviando los 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 la operación completa rápidamente sin tener que actualizar los algoritmos.

El modo receptor de reinicio correcto de larga duración está habilitado de forma predeterminada, a menos que esté deshabilitado el modo receptor normal de reiniciar. Para habilitar la BGP función de reinicio correcto y sin problemas de vida útil ( long-lived receiver enable LLGR), [edit protocols bgp graceful-restart] incluya la instrucción en el nivel jerárquico. Aparte de permitir BGP LLGR en el nivel global o de todo el sistema, también puede incluir la instrucción enable Receiver de vida prolongada [edit protocols bgp group group-name graceful-restart] en el nivel de la jerarquía para configurar LLGR para un grupo de [edit protocols bgp group group-name neighbor neighbor-address graceful-restart] BGP determinado y en el nivel de jerarquía para configurar LLGR para un en particular BGP vecino. Para deshabilitar el mecanismo de LLGR de la long-lived receiver disable BGP, [edit protocols bgp graceful-restart]incluya [edit protocols bgp group group-name graceful-restart]la opción, o [modificar protocolo BGP de grupo o nombre-Grupo-dirección vecina-reinicio correcto]. Al deshabilitar LLGR se desactivan todas las capacidades del LLGR (modos de receptor y de reinicio) para todas las familias de NLRI. Los grupos heredan esta propiedad de la configuración global y los vecinos de la configuración del grupo.

Topología

Considere un escenario de ejemplo en el que desea aumentar el período de tiempo durante el que se mantienen las rutas obsoletas para un par BGP o vecino con la dirección 1.2.3.4. Además de especificar el tiempo durante el cual se deben conservar las rutas para sesiones obsoletas y cuando se produce un reinicio normal de un interlocutor, también puede configurar enrutadores de BGP de ciertos prefijos de direcciones para que no se tengan en cuenta cuando defina el reinicio correcto y de larga duración método. Puede definir una lista de prefijos de direcciones IPv4 o IPv6 para su uso en una instrucción de directiva de enrutamiento y una BGP comunidad para que se incluyan en la Directiva de enrutamiento. Si define el modificador de acciones para rechazar rutas de un prefijo determinado, estas BGP rutas no se mantienen para el periodo de tiempo aumentado.

También puede configurar el mecanismo de negociación de modo de reinicio correcto BGP de larga duración para una determinada familia de direcciones en lugar de configurar esta capacidad para todas las familias de direcciones de un sistema, un sistema lógico o una instancia de enrutamiento. Para activar BGP LLGR para una familia específica de direcciones, incluya graceful-restart long-lived restarter stale-time interval la instrucción en uno de los siguientes niveles de jerarquía.

Cada tabla de enrutamiento se identifica por la familia de protocolos o el indicador de familia de direcciones (AFI) y un identificador subsiguiente de familia de direcciones (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 (flow | labeled-unicast) protocolos de la familia inet y uno de (auto-discovery-mspw | auto-discovery-only | signaling) los protcols para L2VPN familia..

La configuración de LLGR no requiere que también se configure BGP reinicio correcto. La sección de larga duración de reinicio solo es visible para las familias l2vpn, inet con etiqueta unicast, flujo de inet y destino de enrutamiento. Está prohibido para inet-mvpn, inet6-mvpn e inet-MDT. Está oculta para otras familias.

Automática

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, quite los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los [edit] comandos en la CLI en el nivel de jerarquía y, a continuación, entrar commit desde el modo de configuración.

Configuración de la lista de prefijos de dirección, BGP comunidad y BGP Directiva de enrutamiento

Configuración del grupo de BGP, NLRI y un reinicio correcto de larga duración

Configuración del grupo de BGP vecinos

Configurar el reinicio correcto sin problemas para el modo de reinicio

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener más información sobre Cómo desplazarse por la CLI, consulte uso del editor de CLI en el modo de configuración en la Guía del usuario de CLI.

  1. Configure la lista prefijo de dirección, BGP comunidad y la condición coincidir y el modificador de acción para la BGP Directiva de enrutamiento.

  2. Configure la funcionalidad del grupo BGP, familia de direcciones y reinicio correcto de larga duración para el modo de reinicio con el tiempo de espera de flujo.

  3. Configure el grupo de BGP vecinos.

Resultados

Desde el modo de configuración, escriba los show policy-options comandos y show protocols para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Comproba

Confirme que la configuración funciona correctamente.

Comprobando que la capacidad de reinicio correcto de larga duración está habilitada

Purpose

Comprobar el BGP capacidad de reinicio correcto de larga duración configurado para BGP nivel de vecino

Intervención

Mientras esté activo el modo de receptor LLGR (un sistema del mismo nivel que negoció LLGR se ha desconectado y aún no se ha reconectado show bgp neighbor ), la salida del comando muestra la cantidad de tiempo restante hasta que la LLGR caduca, el tiempo restante del temporizador de gr obsoletos y los detalles de la costilla.:

Efectos

El resultado muestra información acerca de BGP vecinos.