Distribución de estado de vínculo mediante BGP
Descripción general de la distribución de estado de vínculo mediante BGP
- Función de un protocolo de pasarela interior
- Limitaciones de un protocolo de puerta de enlace interior
- Necesidad de una distribución de estado de vínculo que abarque
- Uso de BGP como solución
- Características admitidas y no compatibles
- Extensiones de estado de vínculo BGP para el enrutamiento de paquetes fuente en redes (SPRING)
- Verificación del nodo NLRI aprendido a través de BGP con OSPF como IGP
- Verificación del prefijo NLRI aprendido a través de BGP con OSPF como IGP
Función de un protocolo de pasarela interior
Un protocolo de pasarela interna (IGP) es un tipo de protocolo que se usa para intercambiar información de enrutador entre dispositivos dentro de un sistema autónomo (AS). Según el método de cálculo de la mejor ruta a un destino, los IGP se dividen en dos categorías:
Protocolos de estado de vínculo: anuncia información sobre la topología de red (vínculos conectados directamente y el estado de esos vínculos) a todos los enrutadores mediante direcciones de multidifusión y actualizaciones de enrutamiento activadas hasta que todos los enrutadores que ejecutan el protocolo de estado de vínculo tengan información idéntica sobre la internetwork. La mejor ruta a un destino se calcula en función de restricciones como el retraso máximo, el ancho de banda disponible mínimo y la afinidad de clase de recurso.
OSPF e IS-IS son ejemplos de protocolos de estado de vínculo.
Protocolos de vector de distancia: anuncie la información completa de la tabla de enrutamiento a vecinos conectados directamente mediante una dirección de difusión. La mejor ruta se calcula en función del número de saltos a la red de destino.
RIP es un ejemplo de un protocolo de vector de distancia.
Como su nombre lo indica, la función de un IGP es proporcionar conectividad de enrutamiento dentro o interna de un dominio de enrutamiento determinado. Un dominio de enrutamiento es un conjunto de enrutadores bajo control administrativo común que comparten un protocolo de enrutamiento común. Un AS puede constar de varios dominios de enrutamiento, donde IGP funciona para anunciar y aprender prefijos de red (rutas) de enrutadores vecinos para crear una tabla de rutas que, en última instancia, contiene entradas para todas las fuentes que anuncian la accesibilidad de un prefijo determinado. IGP ejecuta un algoritmo de selección de ruta para seleccionar la mejor ruta entre el enrutador local y cada destino, y proporciona conectividad completa entre los enrutadores que forman un dominio de enrutamiento.
Además de anunciar la accesibilidad de la red interna, los IGP se utilizan a menudo para anunciar información de enrutamiento que es externa al dominio de enrutamiento de ese IGP a través de un proceso conocido como redistribución de ruta. La redistribución de ruta es un proceso que consiste en intercambiar información de enrutamiento entre distintos protocolos de enrutamiento para unir varios dominios de enrutamiento cuando se desea una conectividad de intraAS.
Limitaciones de un protocolo de puerta de enlace interior
Si bien cada IGP individual tiene sus propias ventajas y limitaciones, las mayores limitaciones del IGP en general son el rendimiento y la escalabilidad.
Los IGP están diseñados para manejar la tarea de adquirir y distribuir información de topología de red con fines de ingeniería de tráfico. Si bien este modelo ha funcionado bien, los IGP tienen limitaciones de escala inherentes cuando se trata de distribuir grandes bases de datos. Los IGP pueden detectar automáticamente a los vecinos, con los que adquieren información de topología de red dentro del área. Sin embargo, la base de datos de estado de vínculo o una base de datos de ingeniería de tráfico tiene el alcance de una sola área o AS, lo que limita las aplicaciones, como la ingeniería de tráfico de extremo a extremo, la ventaja de tener visibilidad externa para tomar mejores decisiones.
Para las redes de conmutación de etiquetas, como MPLS y MPLS generalizada (GMPLS), la mayoría de las soluciones de ingeniería de tráfico existentes funcionan en un único dominio de enrutamiento. Estas soluciones no funcionan cuando una ruta del nodo de entrada al nodo de salida sale del área de enrutamiento o el AS del nodo de entrada. En tales casos, el problema de cálculo de la ruta se complica debido a la falta de disponibilidad de la información de enrutamiento completa en toda la red. Esto se debe a que los operadores de telecomunicaciones normalmente optan por no perder información de enrutamiento más allá del área o AS de enrutamiento por limitaciones de escalabilidad y confidencialidad.
Necesidad de una distribución de estado de vínculo que abarque
Una de las limitaciones del IGP es su incapacidad para abarcar la distribución del estado de vínculos fuera de una sola área o AS. Sin embargo, la información que abarca el estado de vínculos obtenida por una IGP de varias áreas o AS requiere lo siguiente:
Cálculo de ruta de LSP: esta información se utiliza para calcular la ruta de los LSP MPLS en varios dominios de enrutamiento, por ejemplo, un LSP de TE entre áreas.
Entidades de computación de ruta externa: las entidades de informática de ruta externas, como la optimización de tráfico de la capa de aplicación (ALTO) y los elementos de cálculo de ruta (PCE), realizan cálculos de ruta basados en la topología de red y el estado actual de las conexiones dentro de la red, incluida la información de ingeniería de tráfico. Esta información suele ser distribuida por IGP dentro de la red.
Sin embargo, dado que las entidades de informática de ruta externa no pueden extraer esta información de los IGP, realizan la supervisión de la red para optimizar los servicios de red.
Uso de BGP como solución
Descripción general
Para satisfacer las necesidades de ampliar la distribución del estado de vínculo en varios dominios, se requiere un protocolo de puerta de enlace exterior (EGP) para recopilar información de ingeniería de tráfico y estado de vínculo de un área de IGP, compartirla con un componente externo y usarla para calcular rutas para LSP MPLS entre dominios.
El BGP es un EGP estandarizado diseñado para intercambiar información de enrutamiento y accesibilidad entre sistemas autónomos (AS). BGP es un protocolo probado que tiene mejores propiedades de escalado porque puede distribuir millones de entradas (por ejemplo, prefijos VPN) de manera escalable. BGP es el único protocolo de enrutamiento en uso hoy en día que es adecuado para transportar todas las rutas en Internet. Esto se debe en gran parte a que BGP se ejecuta sobre TCP y puede hacer uso del control de flujo TCP. Por el contrario, los protocolos de puerta de enlace interna (IGP) no tienen control de flujo. Cuando los IGP tienen demasiada información de ruta, comienzan a agitarse. Cuando BGP tiene un altavoz vecino que envía información demasiado rápido, BGP puede estrangular al vecino retrasando las confirmaciones de TCP.
Otro beneficio de BGP es que utiliza tuplas de tipo, longitud, valor (TLV) e información de accesibilidad de capa de red (NLRI) que proporcionan una extensibilidad aparentemente interminable sin la necesidad de alterar el protocolo subyacente.
La distribución de la información del estado del enlace entre dominios se regula mediante políticas para proteger los intereses del proveedor de servicios. Esto requiere un control sobre la distribución de la topología mediante políticas. BGP, con su marco de políticas implementado, sirve bien en la distribución de rutas entre dominios. En Junos OS, BGP se basa completamente en políticas. El operador debe configurar explícitamente los vecinos para emparejarse y aceptar explícitamente las rutas en BGP. Además, la política de enrutamiento se utiliza para filtrar y modificar la información de enrutamiento. Por lo tanto, las políticas de enrutamiento proporcionan un control administrativo completo sobre las tablas de enrutamiento.
Aunque dentro de un AS tanto el IGP-TE como el BGP-TE proporcionan el mismo conjunto de información, el BGP-TE tiene mejores funciones de escalabilidad que se heredaron del protocolo BGP estándar. Esto hace a la Ing-T de BGP una opción más escalable para adquirir información de topología de varias áreas o AS.
Al usar BGP como solución, la información adquirida por IGP se usa para su distribución en BGP. Los ISP pueden exponer selectivamente esta información con otros ISP, proveedores de servicios y redes de distribución de contenido (CDN) a través del emparejamiento BGP normal. Esto permite la agregación de la información adquirida por el IGP de varias áreas y AS, de manera tal que una entidad de informática de ruta externa pueda acceder a la información al escuchar de manera pasiva un reflector de ruta.
Implementación
En Junos OS, los IGP instalan información de topología en una base de datos denominada base de datos de ingeniería de tráfico. La base de datos de ingeniería de tráfico contiene la información de topología agregada. Para instalar información de topología de IGP en la base de datos de ingeniería de tráfico, utilice la instrucción de set igp-topology configuración en los niveles de [edit protocols isis traffic-engineering] jerarquía y [edit protocols ospf traffic-engineering] . El mecanismo para distribuir información de estado de vínculo mediante BGP incluye el proceso de anunciar la base de datos de ingeniería de tráfico en BGP-TE (importación) e instalar entradas de BGP-TE en la base de datos de ingeniería de tráfico (exportación).
A partir de Junos OS versión 20.4R1, puede configurar la ingeniería de tráfico IS-IS para almacenar información IPv6 en la base de datos de ingeniería de tráfico (TED), además de las direcciones IPv4. BGP-LS distribuye esta información como rutas desde la base de datos de ingeniería de tráfico a la tabla de enrutamiento lsdist.0 mediante las políticas de importación de bases de datos de ingeniería de tráfico. Estas rutas se anuncian a los pares BGP-TE como información de accesibilidad de la capa de red (NLRI) con tipo, longitud y valor (TLV) de ID de enrutador IPv6. Además de la información sobre IPv6, puede beneficiarse de la obtención de la topología de red completa en la base de datos de ingeniería de tráfico.
BGP-LS NLRI e ID de la Confederación
A partir de Junos OS versión 23.1R1, Junos OS habilita la información de accesibilidad de la capa de red (NLRI) de estado de vínculo BGP (BGP-LS) para llevar el ID de confederación en TLV 512 cuando la confederación BGP está habilitada. El NLRI lleva el ID de la confederación junto con el número del sistema autónomo miembro (número AS) en TLV 517 como se define en RFC 9086. El módulo de base de datos de ingeniería de tráfico de Junos OS realiza los cambios necesarios para codificar el ID de confederación y el número de AS miembro en TLV 512 y TLV 517 respectivamente, mientras origina el BGP-LS NLRI (que se inyecta en la tabla de enrutamiento lsdist.0). En versiones anteriores a Junos OS versión 23.1R1, BGP-LS NLRI solo lleva el número de AS miembro en TLV 512 y el ID de confederación no está codificado en la tabla de enrutamiento lsdist.0.
Importación de bases de datos de ingeniería de tráfico
Para anunciar la base de datos de ingeniería de tráfico en BGP-TE, las entradas de vínculo y nodo en la base de datos de ingeniería de tráfico se convierten en forma de rutas. Estas rutas convertidas son instaladas por la base de datos de ingeniería de tráfico en nombre del IGP correspondiente, en una tabla de enrutamiento visible por el usuario llamada lsdist.0, en condiciones sujetas a políticas de ruta. El procedimiento de filtrar entradas de la base de datos de ingeniería de tráfico a lsdist.0 se denomina importación de bases de datos de ingeniería de tráfico, como se ilustra en Figura 1.
Existen políticas que rigen el proceso de importación de bases de datos de ingeniería de tráfico. De forma predeterminada, no se filtran entradas de la base de datos de ingeniería de tráfico a la lsdist.0 tabla.
A partir de Junos OS versión 17.4R1, la base de datos de ingeniería de tráfico instala información de topología del protocolo de puerta de enlace interior (IGP) además de información de topología RSVP-TE en la tabla de enrutamiento lsdist.0, como se ilustra en Figura 1. Antes de Junos OS versión 17.4R1, la base de datos de ingeniería de tráfico solo exportaba información de topología RSVP-TE. Ahora puede supervisar la información de topología de ingeniería de tráfico y de IGP. El BGP-LS lee entradas IGP de lsdist.0 y anuncia estas entradas a los pares BGP. Para importar información de topología de IGP en BGP-LS desde lsdist.0, utilice la instrucción configuration set bgp-ls en el [edit protocols mpls traffic-engineering database import igp-topology] nivel de jerarquía.
Exportación de bases de datos de ingeniería de tráfico
BGP se puede configurar para exportar o anunciar rutas desde la tabla, sujeto a la lsdist.0 política. Esto es común para cualquier tipo de originación de ruta en BGP. Para anunciar BGP-TE en la base de datos de ingeniería de tráfico, BGP debe configurarse con la familia de direcciones BGP-TE y una política de exportación que seleccione rutas para redistribuir en BGP.
BGP luego propaga estas rutas como cualquier otro NLRI. Los pares BGP que tienen la familia BGP-TE configurada y negociada reciben NLRI BGP-TE. BGP almacena las NLRI BGP-TE recibidas en forma de rutas en la lsdist.0 tabla, que es la misma tabla que almacena las rutas BGP-TE originadas localmente. Las rutas instaladas por BGP se distribuyen a otros pares como lsdist.0 cualquier otra ruta. Por lo tanto, el procedimiento estándar de selección de ruta se aplica a las NLRI BGP-TE recibidas de múltiples altavoces.
Para lograr la TE entre dominios, las rutas se lsdist.0 filtran a la base de datos de ingeniería de tráfico a través de una política. Este proceso se denomina exportación de bases de datos de ingeniería de tráfico, como se ilustra en Figura 1.
Existen políticas que rigen el proceso de exportación de bases de datos de ingeniería de tráfico. De forma predeterminada, no se filtran entradas de la lsdist.0 tabla a la base de datos de ingeniería de tráfico.
A partir de Junos OS versión 22.4R1, puede distribuir las políticas de ingeniería de tráfico (TE) que se originan desde el protocolo de enrutamiento de segmentos a la base de datos de ingeniería de tráfico (TED) y en el estado de vínculo BGP como rutas. BGP link-state recopila la información relacionada con las políticas de TE para que los controladores externos puedan realizar acciones como cálculo de rutas, reoptimización y visualización de red dentro de dominios y entre ellos.
Configure set protocols source-packet-routing traffic-engineering database para permitir que las políticas de enrutamiento por segmentos (SR) se almacenen en TED.
Para aplicaciones SDN, como PCE y ALTO, la información anunciada BGP-TE no puede filtrarse a la base de datos de ingeniería de tráfico de un enrutador. En tales casos, se utiliza un servidor externo que se empareja con los enrutadores mediante BGP-TE para mover la información de topología hacia el cielo/sistema de orquestación que abarca la red. Estos servidores externos pueden considerarse consumidores de BGP-TE, donde reciben rutas BGP-TE, pero no las anuncian.
Asignación de valores de credibilidad
Una vez que las entradas se instalan en la base de datos de ingeniería de tráfico, la información aprendida de BGP-TE está disponible para el cálculo de la ruta CSPF. La base de datos de ingeniería de tráfico utiliza un esquema de preferencias de protocolo que se basa en valores de credibilidad. Se prefiere un protocolo con un mayor valor de credibilidad sobre un protocolo con un valor de credibilidad más bajo. BGP-TE tiene la capacidad de anunciar información aprendida de múltiples protocolos al mismo tiempo, por lo que además de las entradas instaladas por IGP en la base de datos de ingeniería de tráfico, puede haber entradas instaladas BGP-TE que correspondan a más de un protocolo. El componente de exportación de bases de datos de ingeniería de tráfico crea un protocolo de base de datos de ingeniería de tráfico y un nivel de credibilidad para cada protocolo compatible con BGP-TE. Estos valores de credibilidad se pueden configurar en la CLI.
El orden de credibilidad para los protocolos BGP-TE es el siguiente:
-
Desconocido: 80
-
OSPF—81
-
ISIS Nivel 1—82
-
ISIS Nivel 2—83
-
Estático: 84
-
Directo: 85
Cálculo de ruta de credibilidad cruzada
Después de asignar valores de credibilidad, cada nivel de credibilidad se trata como un plano individual. El algoritmo Restricted Shorted Path First comienza con la credibilidad asignada más alta a la más baja, encontrando una ruta dentro de ese nivel de credibilidad.
Con la Ing-T de BGP, es fundamental calcular las rutas en todos los niveles de credibilidad para calcular rutas de interAS. Por ejemplo, se ven diferentes configuraciones de credibilidad en un dispositivo desde el área 0 que calcula la ruta a través del área 1, porque las entradas del área 0 son instaladas por OSPF y las entradas del área 1 son instaladas por BGP-TE.
Para habilitar el cálculo de rutas en todos los niveles de credibilidad, incluya la cross-credibility-cspf instrucción en los niveles , y [edit protocols rsvp] jerárquicoedit protocols mpls[edit protocols mpls label-switched-path lsp-name]. En el nivel jerárquico, los impactos habilitantes cross-credibility-cspf evitan los LSP y la [edit protocols rsvp] expansión de saltos sueltos en tránsito.
La configuración cross-credibility-cspf permite el cálculo de rutas en todos los niveles de credibilidad mediante el algoritmo Restricted Shortest Path First, en el que la restricción no se realiza credibilidad por credibilidad, sino como una restricción única que ignora los valores de credibilidad asignados.
BGP-TE NLRI y TLV
Al igual que otras rutas BGP, las NLRI BGP-TE también se pueden distribuir a través de un reflector de ruta que habla BGP-TE NLRI. Junos OS implementa la compatibilidad de reflexión de ruta para la familia BGP-TE.
La siguiente es una lista de NLRI compatibles:
-
Enlace NLRI
-
NLRI de nodo
-
Prefijo IPv4 NLRI (recibir y propagar)
-
Prefijo IPv6 NLRI (recepción y propagación)
-
Política de TE NLRI
Junos OS no proporciona compatibilidad con la forma de distinguir rutas de los NRLI anteriores.
A continuación se muestra una lista de campos admitidos en NLRI de vínculo y nodo:
-
Id. de protocolo: NLRI se origina con los siguientes valores de protocolo:
-
ISIS-L1
-
ISIS-L2
-
OSPF
-
PRIMAVERA-TE
-
-
Identificador: este valor es configurable. De forma predeterminada, el valor del identificador se establece en
0. -
Descriptor de nodo local/remoto: incluyen:
-
Sistema autónomo
-
Identificador BGP-LS: este valor es configurable. De forma predeterminada, el valor del identificador BGP-LS se establece en
0 -
ID de área
-
ID de enrutador IGP
-
-
Descriptores de vínculo (solo para NLRI de vínculo): esto incluye:
-
Vincular identificadores locales/remotos
-
Dirección de interfaz IPv4
-
Dirección de vecino IPv4
-
Dirección de vecino/interfaz IPv6: las direcciones de vecino e interfaz IPv6 no se originan, sino que solo se almacenan y propagan cuando se reciben.
-
ID de varias topologías: este valor no se origina, sino que se almacena y propaga cuando se recibe.
-
A continuación se muestra una lista de TLV de atributos LINK_STATE compatibles:
-
Atributos del vínculo:
-
Grupo administrativo
-
Ancho de banda máximo del vínculo
-
Ancho de banda máximo reservable
-
Ancho de banda no reservado
-
Métrica predeterminada de TE
-
SRLG
-
Los siguientes TLV, que no se originan, sino que solo se almacenan y propagan cuando se reciben:
-
Atributos de vínculo opacos
-
Máscara de protocolo MPLS
-
Métrico
-
Tipo de protección de vínculo
-
Atributo de nombre de vínculo
-
-
-
Atributos del nodo:
-
ID de enrutador IPv4
-
Bits de indicador de nodo: solo se establece el bit de sobrecarga.
-
Los siguientes TLV, que no se originan, sino que solo se almacenan y propagan cuando se reciben:
-
Multitopología
-
Propiedades del nodo específico de OSPF
-
Propiedades del nodo opaco
-
Nombre del nodo
-
Identificador de área IS-IS
-
ID de enrutador IPv6
-
-
Atributos de prefijo: estos TLV se almacenan y propagan como cualquier otro TLV desconocido.
-
Características admitidas y no compatibles
Junos OS admite las siguientes funciones con la distribución de estado de vínculo mediante BGP:
Anuncio de la capacidad de reenvío asegurado multiprotocolo
Transmisión y recepción de NLRI BGP y BGP-TE de nodo y estado de enlace
Enrutamiento activo sin interrupciones para NLRI BGP-TE
Políticas
Junos OS admite not la siguiente funcionalidad para la distribución de estado de vínculo mediante BGP:
Topologías, vínculos o nodos agregados
Compatibilidad con el distinguidor de rutas para NLRI BGP-TE
Identificadores de varias topologías
Identificadores de varias instancias (excluyendo el ID de instancia predeterminado 0)
Anuncio del TLV de enlace y área de nodo
Publicidad de protocolos de señalización MPLS
Importación de información de nodos y vínculos con direcciones superpuestas
Extensiones de estado de vínculo BGP para el enrutamiento de paquetes fuente en redes (SPRING)
A partir de Junos OS versión 17.2R1, la familia de direcciones de estado de vínculo BGP se extiende para distribuir la información de topología del enrutamiento de paquetes de origen en redes (SPRING) a los controladores de redes definidas por software (SDN). BGP normalmente aprende la información del estado del vínculo de IGP y la distribuye a los pares de BGP. Además de BGP, el controlador SDN puede obtener información de estado de vínculo directamente de IGP si el controlador forma parte de un dominio IGP. Sin embargo, la distribución de estado de vínculo BGP proporciona un mecanismo escalable para exportar la información de topología. Las extensiones de estado de vínculo BGP para SPRING son compatibles con redes entre dominios.
- Enrutamiento de paquetes fuente en redes (SPRING)
- Flujo de datos SPRING de estado de enlace BGP
- Atributos y TLV de estado de enlace BGP compatibles, y características no compatibles con BGP Link-State con SPRING
Enrutamiento de paquetes fuente en redes (SPRING)
SPRING es una arquitectura de plano de control que permite a un enrutador de entrada dirigir un paquete a través de un conjunto específico de nodos y enlaces en la red sin depender de los nodos intermedios de la red para decidir la ruta real que debe tomar. SPRING involucra IGP, como IS-IS y OSPF, para segmentos de redes publicitarias. Los segmentos de red pueden representar cualquier instrucción, topológica o basada en servicios. Dentro de las topologías IGP, los segmentos IGP se anuncian mediante los protocolos de enrutamiento de estado de vínculo. Hay dos tipos de segmentos de IGP:
| Adjacency segment |
Una ruta de un salto sobre una adyacencia específica entre dos nodos en el IGP |
| Prefix segment |
Una ruta más corta con múltiples saltos, de igual costo y con reconocimiento de múltiples rutas a un prefijo, según el estado de la topología de IGP |
Cuando SPRING está habilitado en una red BGP, la familia de direcciones de estado de vínculo BGP aprende la información de SPRING de los protocolos de enrutamiento de estado de vínculo IGP y anuncia segmentos en forma de identificadores de segmento (SID). La familia de direcciones de estado del vínculo BGP se ha ampliado para transportar SID y otra información relacionada con SPRING a los pares BGP. El reflector de ruta puede dirigir un paquete a través de un conjunto deseado de nodos y enlaces anteponiendo el paquete con una combinación adecuada de túneles. Esta característica permite que la familia de direcciones de estado de vínculo BGP también anuncie la información de SPRING a los pares BGP.
Flujo de datos SPRING de estado de enlace BGP
Figura 2 representa el flujo de datos de los datos SPRING de estado de vínculo BGP que IS-IS envía a la base de datos de ingeniería de tráfico.
-
IGP inserta los atributos SPRING a la base de datos de ingeniería de tráfico.
-
Las capacidades de SPRING y la información del algoritmo se trasladan como atributos de nodo a la base de datos de ingeniería de tráfico.
-
La información SID adyacente y SID adyacente LAN se lleva como atributos de vínculo.
-
La información del SID del prefijo o del SID del nodo se lleva como atributos del prefijo.
-
Un nuevo conjunto o un cambio en los atributos existentes desencadena actualizaciones de IGP en la base de datos de ingeniería de tráfico con datos nuevos.
Precaución:Si la ingeniería de tráfico está deshabilitada en el nivel de IGP, ninguno de los atributos se inserta en la base de datos de ingeniería de tráfico.
-
Todos los parámetros de la NLRI de ingeniería de tráfico de BGP, incluidos los descriptores de vínculo, nodo y prefijo, se derivan de entradas en la base de datos de ingeniería de tráfico.
-
La base de datos de ingeniería de tráfico importa entradas de ruta en la
lsdist.0tabla de enrutamiento desde IGP sujeto a directiva. -
La política predeterminada de BGP es exportar rutas, que solo conocen BGP. Puede configurar una directiva de exportación para rutas que no sean BGP en la tabla de
lsdis.0enrutamiento. Esta política anuncia una entrada aprendida de la base de datos de ingeniería de tráfico.
Atributos y TLV de estado de enlace BGP compatibles, y características no compatibles con BGP Link-State con SPRING
El estado de vínculo BGP con SPRING admite los siguientes atributos y tipos, longitud y valores (TLV) que se originan, reciben y propagan en la red:
Node attributes
-
Capacidades de enrutamiento por segmentos
-
Algoritmo de enrutamiento de segmentos
Link attributes
-
SID adyacente
-
LAN adyacente-SID
Prefix descriptors
-
Información de accesibilidad IP
Prefix attributes
-
Prefijo SID
La siguiente lista admite TLV que no se originan, sino que solo se reciben y propagan en la red:
Prefix descriptors
-
ID de multitopología
-
Tipo de ruta OSPF
Prefix attributes
-
Gama
-
SID de enlace
Junos OS no admite las siguientes funciones con el estado de vínculo BGP con extensiones SPRING:
-
Originación del prefijo IPv6
-
Identificadores de multitopología
-
Exportación de bases de datos de ingeniería de tráfico para parámetros SPRING
-
Nuevos TLV con tcpdump (los TLV existentes tampoco son compatibles).
-
SPRING sobre IPv6
Verificación del nodo NLRI aprendido a través de BGP con OSPF como IGP
A continuación se muestra un resultado de ejemplo para comprobar el nodo NLRI aprendido a través de BGP con OSPF como IGP:
Propósito
Compruebe las entradas de la tabla de enrutamiento lsdist.0.
Acción
Desde el modo operativo, ejecute el show route table lsdist.0 comando.
user@host> show route table lsdist.0 te-node-ip 10.7.7.7 extensive
lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden)
NODE { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 OSPF:0 }/1536 (1 entry, 1 announced)
TSI:
LINK-STATE attribute handle 0x61d5da0
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x61b07cc
Next-hop reference count: 216
Source: 10.2.2.2
Protocol next hop: 10.2.2.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State:<Active Int Ext>
Local AS: 65100 Peer AS: 65100
Age: 30:22 Metric2: 2
Validation State: unverified
Task: BGP_65100.10.2.2.2
Announcement bits (1): 0-TED Export
AS path: I
Accepted
Area border router: No
External router: No
Attached: No
Overload: No
SPRING-Capabilities:
- SRGB block [Start: 900000, Range: 90000, Flags: 0x00]
SPRING-Algorithms:
- Algo: 0
Localpref: 100
Router ID: 10.2.2.2
Indirect next hops: 1
Protocol next hop: 10.2.2.2 Metric: 2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1
Session Id: 0x143
10.2.2.2/32 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.11.1.2 via et-0/0/0.1
Session Id: 143Significado
Las rutas aparecen en la tabla de enrutamiento lsdist.0.
Verificación del prefijo NLRI aprendido a través de BGP con OSPF como IGP
A continuación se muestra un resultado de ejemplo para comprobar el prefijo NLRI aprendido a través de BGP con OSPF como IGP:
Propósito
Compruebe las entradas de la tabla de enrutamiento lsdist.0.
Acción
Desde el modo operativo, ejecute el show route table lsdist.0 comando.
user@host> show route table lsdist.0 te-ipv4-prefix-node-ip 10.7.7.7 extensive
lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden)
PREFIX { Node { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 } { IPv4:10.7.7.7/32 } OSPF:0 }/1536 (1 entry, 0 announced)
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x61b07cc
Next-hop reference count: 216
Source: 10.2.2.2
Protocol next hop: 10.2.2.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Active Int Ext>
Local AS: 65100 Peer AS: 65100
Age: 30:51 Metric2: 2
Validation State: unverified
Task: BGP_65100.10.2.2.2
AS path: I
Accepted
Prefix Flags: 0x00, Prefix SID: 1007, Flags: 0x50, Algo: 0
Localpref: 65100
Router ID: 10.2.2.2
Indirect next hops: 1
Protocol next hop: 10.2.2.2 Metric: 2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1
Session Id: 0x143
10.2.2.2/32 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.11.1.2 via et-0/0/0.1
Session Id: 143Significado
Las rutas aparecen en la tabla de enrutamiento lsdist.0.
Ejemplo: Configuración de la distribución de estado de vínculo mediante BGP
En este ejemplo se muestra cómo configurar BGP para transportar información de estado de vínculo a través de varios dominios, que se usa para calcular rutas de acceso para LSP MPLS que abarcan varios dominios, como TE LSP entre áreas, y proporcionar un medio escalable y controlado por políticas para que entidades de informática de ruta externas, como ALTO y PCE, adquieran topología de red.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Cuatro enrutadores que pueden ser una combinación de enrutadores serie M, serie MX o serie T
-
Junos OS versión 14.2 o posterior ejecutándose en todos los enrutadores
Antes de empezar:
-
Configure las interfaces del dispositivo.
-
Configure los números de sistema autónomo y los ID de enrutador para los dispositivos.
-
Configure los protocolos siguientes:
-
Confirmación de asistencia (RSVP)
-
MPLS
-
protocolo de puerta de enlace de frontera (BGP)
-
SI-SI
-
OSPF
-
Descripción general
A partir de Junos OS versión 14.2, se introduce un nuevo mecanismo para distribuir información de topología entre varias áreas y sistemas autónomos (AS) mediante la extensión del protocolo BGP para transportar información de estado de vínculo, que inicialmente se adquirió mediante IGP. Los protocolos IGP tienen limitaciones de escalamiento cuando se trata de distribuir grandes bases de datos. El BGP no es solo un vehículo más escalable para llevar la información de varias áreas y topologías, sino que también proporciona controles de políticas que pueden ser útiles para la distribución topológica de varios AS. La información de topología de estado de vínculo BGP se utiliza para calcular rutas para rutas de conmutación de etiquetas (LSP) MPLS que abarcan varios dominios, como TE LSP entre áreas, y proporciona un medio escalable y controlado por políticas para que entidades de informática de ruta externas, como ALTO y PCE, adquieran topología de red.
A partir de Junos OS versión 17.1R1, la distribución de estado de vínculo mediante BGP se admite en conmutadores QFX10000.
Topología
En Figura 3, los enrutadores R0 y R1 y los enrutadores R2 y R3 pertenecen a sistemas autónomos diferentes. Los enrutadores R0 y R1 ejecutan OSPF, y los enrutadores R2 y R3 ejecutan IS-IS.
Configuración
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.
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.101/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.137/32 set routing-options router-id 10.255.105.137 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls cross-credibility-cspf set protocols mpls label-switched-path to-R3-inter-as to 10.255.105.135 set protocols mpls label-switched-path to-R3-inter-as bandwidth 40m set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.137 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.141 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
R1
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.103/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.102/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.141/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5501.8181 set routing-options router-id 10.255.105.141 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.141 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.137 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 set protocols bgp group ebgp neighbor 10.8.42.104 peer-as 65534 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept
R2
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.104/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.104/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.139/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4211.00 set routing-options router-id 10.255.105.139 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database import policy ted2nlri set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.139 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.135 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp export nlri2bgp set protocols bgp group ebgp peer-as 65533 set protocols bgp group ebgp neighbor 10.8.42.102 set protocols isis level 1 disable set protocols isis interface ge-0/0/0.0 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept set policy-options policy-statement ted2nlri term 1 from protocol isis set policy-options policy-statement ted2nlri term 1 from protocol ospf set policy-options policy-statement ted2nlri term 1 then accept set policy-options policy-statement ted2nlri term 2 then reject
R3
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.106/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.135/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4250 set routing-options router-id 10.255.105.135 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.135 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.139 set protocols isis interface ge-0/0/0.0 level 1 disable set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
Procedimiento
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar 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.
Para configurar el enrutador R1:
-
Configure las interfaces del enrutador R1.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.8.31.103/24 user@R1# set ge-0/0/0 unit 0 family iso user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set ge-0/0/1 unit 0 family inet address 10.8.42.102/24 user@R1# set ge-0/0/1 unit 0 family iso user@R1# set ge-0/0/1 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.255.105.141/32 user@R1# set lo0 unit 0 family iso address 47.0005.0102.5501.8181
-
Configure el ID del enrutador y el sistema autónomo del enrutador R1.
[edit routing-options]user@R1# set router-id 10.255.105.141 user@R1# set autonomous-system 65533 -
Active RSVP en todas las interfaces del enrutador R1 (excluyendo la interfaz de administración).
[edit protocols]user@R1# set rsvp interface all user@R1# set rsvp interface fxp0.0 disable -
Habilite MPLS en todas las interfaces del enrutador R1 (excluyendo la interfaz de administración).
[edit protocols]user@R1# set mpls interface all user@R1# set mpls interface fxp0.0 disable -
Configure el grupo BGP para que el enrutador R1 se empareje con el enrutador R0 y asigne la dirección local y la dirección del vecino.
[edit protocols]user@R1# set bgp group ibgp type internal user@R1# set bgp group ibgp local-address 10.255.105.141 user@R1# set bgp group ibgp neighbor 10.255.105.137 -
Incluya la información de accesibilidad de la capa de red de señalización BGP-TE (NLRI) al grupo BGP de ibgp.
[edit protocols]user@R1# set bgp group ibgp family traffic-engineering unicast -
Habilite la exportación de la directiva nlri2bgp en el enrutador R1.
[edit protocols]user@R1# set bgp group ibgp export nlri2bgp -
Configure el grupo BGP para que el enrutador R1 se empareje con el enrutador R2 y asigne la dirección local y el sistema autónomo vecino al grupo BGP ebgp.
[edit protocols]user@R1# set bgp group ebgp type external user@R1# set bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 user@R1# set bgp group ebgp neighbor 10.8.42.104 peer-as 65534 -
Incluya la NLRI de señalización BGP-TE al grupo BGP ebgp.
[edit protocols]user@R1# set bgp group ebgp family traffic-engineering unicast -
Habilite la ingeniería de tráfico pasivo en el vínculo interAS.
[edit protocols]user@R1# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 user@R1# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 -
Habilite OSPF en la interfaz que conecta el enrutador R1 con el enrutador R0 y en la interfaz de circuito cerrado del enrutador R1, y habilite las capacidades de ingeniería de tráfico.
[edit protocols]user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 -
Habilite la ingeniería de tráfico pasivo en el vínculo interAS.
[edit protocols]user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 -
Configure políticas para aceptar tráfico de BGP-TE NLRI.
[edit policy-options]user@R1# set policy-statement accept-all from family traffic-engineering user@R1# set policy-statement accept-all then accept user@R1# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R1# set policy-statement nlri2bgp term 1 then accept
Resultados
Desde el modo de configuración, ingrese los comandos show interfaces, show routing-options, show protocols y show policy-options 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.
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.8.31.103/24;
}
family iso;
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.8.42.102/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.105.141/32;
family iso {
address 47.0005.0102.5501.8181:00;
}
}
}
user@R1# show routing-options router-id 10.255.105.141; autonomous-system 65533;
user@R1# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group ibgp {
type internal;
local-address 10.255.105.141;
family traffic-engineering {
unicast;
}
export nlri2bgp;
neighbor 10.255.105.137;
}
group ebgp {
type external;
family traffic-engineering {
unicast;
}
neighbor 10.8.42.104 {
local-address 10.8.42.102;
peer-as 65534;
}
}
}
isis {
interface ge-0/0/1.0 {
passive {
remote-node-iso 0102.5502.4211;
remote-node-id 10.8.42.104;
}
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/0.0;
interface ge-0/0/1.0 {
passive {
traffic-engineering {
remote-node-id 10.8.42.104;
remote-node-router-id 10.255.105.139;
}
}
}
}
}
user@R1# show policy-options
policy-statement accept-all {
from family traffic-engineering;
then accept;
}
policy-statement nlri2bgp {
term 1 {
from family traffic-engineering;
then {
accept;
}
}
}
Procedimiento
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar 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.
Para configurar el enrutador R2:
-
Configure las interfaces del enrutador R2.
[edit interfaces] user@R2# set ge-0/0/0 unit 0 family inet address 10.8.64.104/24 user@R2# set ge-0/0/0 unit 0 family iso user@R2# set ge-0/0/0 unit 0 family mpls user@R2# set ge-0/0/1 unit 0 family inet address 10.8.42.104/24 user@R2# set ge-0/0/1 unit 0 family iso user@R2# set ge-0/0/1 unit 0 family mpls user@R2# set lo0 unit 0 family inet address 10.255.105.139/32 user@R2# set lo0 unit 0 family iso address 47.0005.0102.5502.4211.00
-
Configure el ID del enrutador y el sistema autónomo del enrutador R2.
[edit routing-options]user@R2# set router-id 10.255.105.139 user@R2# set autonomous-system 65534 -
Active RSVP en todas las interfaces del enrutador R2 (excluyendo la interfaz de administración).
[edit routing-options]user@R2# set rsvp interface all user@R2# set rsvp interface fxp0.0 disable -
Habilite MPLS en todas las interfaces del enrutador R2 (excluyendo la interfaz de administración).
[edit routing-options]user@R2# set mpls interface all user@R2# set mpls interface fxp0.0 disable -
Habilite la importación de parámetros de base de datos de ingeniería de tráfico mediante la política ted2nlri.
[edit protocols]user@R2# set mpls traffic-engineering database import policy ted2nlri -
Configure el grupo BGP para que el enrutador R2 se empareje con el enrutador R3 y asigne la dirección local y la dirección del vecino.
[edit protocols]user@R2# set bgp group ibgp type internal user@R2# set bgp group ibgp local-address 10.255.105.139 user@R2# set bgp group ibgp neighbor 10.255.105.135 -
Incluya la información de accesibilidad de la capa de red de señalización BGP-TE (NLRI) al grupo BGP de ibgp.
[edit protocols]user@R2# set bgp group ibgp family traffic-engineering unicast -
Habilite la exportación de la directiva nlri2bgp en el enrutador R2.
[edit protocols]user@R2# set bgp group ibgp export nlri2bgp -
Configure el grupo BGP para que el enrutador R2 se empareje con el enrutador R1.
[edit protocols]user@R2# set bgp group ebgp type external -
Incluya la NLRI de señalización BGP-TE al grupo BGP ebgp.
[edit protocols]user@R2# set bgp group ebgp family traffic-engineering unicast -
Asigne la dirección local y el sistema autónomo vecino al grupo BGP ebgp.
[edit protocols]user@R2# set bgp group ebgp peer-as 65533 user@R2# set bgp group ebgp neighbor 10.8.42.102 -
Habilite la exportación de la directiva nlri2bgp en el enrutador R2.
[edit protocols]user@R2# set bgp group ebgp export nlri2bgp -
Active IS-IS en la interfaz que conecta el enrutador R2 con el enrutador R3 y la interfaz de circuito cerrado del enrutador R2.
[edit protocols]user@R2# set isis level 1 disable user@R2# set isis interface ge-0/0/0.0 user@R2# set isis interface lo0.0 -
Habilite solo la publicidad IS-IS en la interfaz que conecta el enrutador R2 con el enrutador R1.
[edit protocols]user@R2# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 user@R2# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 -
Configure la capacidad de ingeniería de tráfico en el enrutador R2.
[edit protocols]user@R2# set ospf traffic-engineering -
Active solo los anuncios OSPF en la interfaz que conecta el enrutador R2 con el enrutador R1.
[edit protocols]user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 -
Configure políticas para aceptar tráfico de la NLRI BGP-TE.
[edit policy-options]user@R2# set policy-statement accept-all from family traffic-engineering user@R2# set policy-statement accept-all then accept user@R2# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R2# set policy-statement nlri2bgp term 1 then accept user@R2# set policy-statement ted2nlri term 1 from protocol isis user@R2# set policy-statement ted2nlri term 1 from protocol ospf user@R2# set policy-statement ted2nlri term 1 then accept user@R2# set policy-statement ted2nlri term 2 then reject
Resultados
Desde el modo de configuración, ingrese los comandos show interfaces, show routing-options, show protocols y show policy-options 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.
user@R2# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.8.64.104/24;
}
family iso;
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.8.42.104/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.105.139/32;
family iso {
address 47.0005.0102.5502.4211.00;
}
family iso;
}
}
user@R2# show routing-options router-id 10.255.105.139; autonomous-system 65534;
user@R2# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
traffic-engineering {
database {
import {
policy ted2nlri;
}
}
}
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group ibgp {
type internal;
local-address 10.255.105.139;
family traffic-engineering {
unicast;
}
export nlri2bgp;
neighbor 10.255.105.135;
}
group ebgp {
type external;
family traffic-engineering {
unicast;
}
export nlri2bgp;
peer-as 65533;
neighbor 10.8.42.102;
}
}
isis {
level 1 disable;
interface ge-0/0/0.0;
interface ge-0/0/1.0 {
passive {
remote-node-iso 0102.5501.8181;
remote-node-id 10.8.42.102;
}
}
interface lo0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0 {
passive {
traffic-engineering {
remote-node-id 10.8.42.102;
remote-node-router-id 10.255.105.141;
}
}
}
}
}
user@R2# show policy-options
policy-statement accept-all {
from family traffic-engineering;
then accept;
}
policy-statement nlri2bgp {
term 1 {
from family traffic-engineering;
then {
accept;
}
}
}
policy-statement ted2nlri {
term 1 {
from protocol [ isis ospf ];
then accept;
}
term 2 {
then reject;
}
}
Verificación
Compruebe que la configuración funciona correctamente.
- Comprobación del estado del resumen del BGP
- Comprobación del estado de LSP de MPLS
- Comprobación de las entradas de la tabla de enrutamiento lsdist.0
- Comprobación de las entradas de la base de datos de ingeniería de tráfico
Comprobación del estado del resumen del BGP
Propósito
Verifique que BGP esté funcionando en los enrutadores R0 y R1.
Acción
Desde el modo operativo, ejecute el show bgp summary comando.
user@R0> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
lsdist.0
10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.255.105.141 65533 20 14 0 79 5:18 Establ
lsdist.0: 10/10/10/0Desde el modo operativo, ejecute el show bgp summary comando.
user@R1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
lsdist.0
10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.8.42.104 65534 24 17 0 70 6:43 Establ
lsdist.0: 10/10/10/0
10.255.105.137 65533 15 23 0 79 6:19 Establ
lsdist.0: 0/0/0/0Significado
El enrutador R0 está emparejado con el enrutador R1.
Comprobación del estado de LSP de MPLS
Propósito
Verifique el estado del LSP MPLS en el enrutador R0.
Acción
Desde el modo operativo, ejecute el show mpls lsp comando.
user@R0> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.255.105.135 10.255.105.137 Up 0 * to-R3-inter-as Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Significado
Se establece el LSP MPLS del enrutador R0 al enrutador R3.
Comprobación de las entradas de la tabla de enrutamiento lsdist.0
Propósito
Verifique las entradas de la tabla de enrutamiento lsdist.0 en los enrutadores R0, R1 y R2.
Acción
Desde el modo operativo, ejecute el show route table lsdist.0 comando.
user@R0> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:8.42.1.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:02:03, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10. 8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0Desde el modo operativo, ejecute el show route table lsdist.0 comando.
user@R1> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:02:19, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0Desde el modo operativo, ejecute el show route table lsdist.0 comando.
user@R2> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[IS-IS/18] 1d 00:24:39
Fictitious
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[OSPF/10] 1d 00:24:39
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:58
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:02:34
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[OSPF/10] 00:20:57
FictitiousSignificado
Las rutas aparecen en la tabla de enrutamiento lsdist.0.
Comprobación de las entradas de la base de datos de ingeniería de tráfico
Propósito
Verifique las entradas de la base de datos de ingeniería de tráfico en el enrutador R0.
Acción
Desde el modo operativo, ejecute el show ted database comando.
user@R0> show ted database
TED database: 5 ISIS nodes 5 INET nodes
ID Type Age(s) LnkIn LnkOut Protocol
0102.5501.8168.00(10.255.105.137) Rtr 1046 1 1 OSPF(0.0.0.0)
To: 10.8.31.101-1, Local: 10.8.31.101, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5501.8181.00 --- 1033 1 0
0102.5502.4211.00(10.255.105.139) Rtr 3519 2 3 Exported ISIS-L2(1)
To: 0102.5502.4250.02, Local: 10.8.64.104, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 0102.5501.8181.00, Local: 10.8.42.104, Remote: 10.8.42.102
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
Exported OSPF(2)
To: 10.255.105.141, Local: 10.8.42.104, Remote: 10.8.42.102
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5502.4250.00(10.255.105.135) Rtr 1033 1 1 Exported ISIS-L2(1)
To: 0102.5502.4250.02, Local: 10.8.64.106, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5502.4250.02 Net 1033 2 2 Exported ISIS-L2(1)
To: 0102.5502.4211.00(10.255.105.139), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 0102.5502.4250.00(10.255.105.135), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
10.8.31.101-1 Net 1046 2 2 OSPF(0.0.0.0)
To: 0102.5501.8168.00(10.255.105.137), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 10.255.105.141, Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.105.141 Rtr 1045 2 2 OSPF(0.0.0.0)
To: 0102.5502.4211.00(10.255.105.139), Local: 10.8.42.102, Remote: 10.8.42.104
Local interface index: 0, Remote interface index: 0
To: 10.8.31.101-1, Local: 10.8.31.103, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0Significado
Las rutas aparecen en la base de datos de ingeniería de tráfico.
Configuración de la distribución de estado de vínculo mediante BGP
Puede habilitar la distribución de información de topología entre varias áreas y sistemas autónomos (AS) extendiendo el protocolo BGP para transportar información de estado de vínculo, que se adquirió inicialmente mediante IGP. Los protocolos IGP tienen limitaciones de escalamiento cuando se trata de distribuir grandes bases de datos. El BGP no es solo un vehículo más escalable para llevar la información de varias áreas y topologías, sino que también proporciona controles de políticas que pueden ser útiles para la distribución topológica de varios AS. La información de topología de estado de vínculo BGP se utiliza para calcular rutas para LSP MPLS que abarcan varios dominios, como TE LSP entre áreas, y para proporcionar un medio escalable y controlado por políticas para que entidades de informática de ruta externas, como ALTO y PCE, adquieran topología de red.
Antes de empezar:
Configure las interfaces del dispositivo.
Configure el ID del enrutador y el número de sistema autónomo del dispositivo.
Configure los protocolos siguientes:
Confirmación de asistencia (RSVP)
MPLS
SI-SI
OSPF
Para habilitar la distribución de estado de vínculo mediante BGP:
Distribución de estado de vínculo mediante SRv6
Extensiones de estado de vínculo BGP para SRv6
A partir de la versión 21.3R1 de Junos OS, admitimos SRv6 en BGP-LS y en la base de datos de ingeniería de tráfico (TED). Las extensiones BGP-LS exportan la información de la topología SRv6 a los controladores SDN. Los controladores reciben la información de topología al formar parte de un dominio IGP o a través de BGP-LS. BGP LS proporciona un mecanismo escalable para exportar la información de topología. También se puede utilizar para las redes entre dominios. Además, ahora puede filtrar NLRI según el prefijo IPv6 (localizador SRv6) y SRv6 SID NLRI.
Flujo de datos SRv6 de estado de vínculo BGP
BGP LS recupera los datos de ingeniería de tráfico (TE) de la base de datos de TE (TED) y los distribuye a los altavoces BGP pares. Para ello, TED convierte sus entradas, enlaces, nodos y prefijos (IPv4 e IPv6) en forma de rutas. La siguiente figura muestra el flujo de datos en BGP-LS.
-
Los atributos SRv6 intercambiados a través de ISIS IGP ahora son compatibles con Junos, como se describe en el estándar IETF [3].
-
Los atributos SRv6 se agregan a la base de datos de ingeniería de tráfico (TED).
-
Los atributos SRv6 aprendidos a través de ISIS IGP se almacenan en TED a medida que los nodos y los enlaces se convierten en rutas. Estas rutas se someten a la política de importación de TED y, si la política lo permite, se instalan en una tabla de enrutamiento denominada lsdist.0.
-
BGP se puede configurar para "exportar" o anunciar rutas de la tabla lsdist.0 sujeta a la política. BGP luego propaga estas rutas como cualquier otro NLRI. Es decir, los pares que tienen la familia BGP-LS configurada y negociada reciben BGP-LS NLRI. BGP almacena las NLRI BGP-LS recibidas en forma de rutas en la tabla "lsdist.0", que es la misma tabla que almacena las rutas BGP-LS originadas localmente. La información SRv6 recién agregada se propaga a BGP como atributos de NLRI ya existentes (nodo, vínculo y prefijo) y un nuevo NLRI de localizador SRv6.
-
Las NLRI BGP-LS recibidas que se instalan en forma de rutas en la tabla "lsdist.0" pueden estar sujetas a la política de exportación de TED y, si la política lo permite, los atributos SRv6 de estas rutas se agregan a la instancia local de la base de datos TE.
Prefijos IPv6 y SID de adyacencia IPv6 Soporte MPLS en bases de datos de ingeniería de tráfico y estado de vínculo BGP
Hemos realizado las siguientes mejoras de IPv6.
- Soporte para agregar los atributos IPv6 y la información a la base de datos de ingeniería de tráfico (TED) desde un sistema intermedio a un sistema intermedio (IS-IS).
- Compatibilidad con la importación de atributos IPv6 desde la base de datos de ingeniería de tráfico a la tabla de enrutamiento lsdist.0.
- Compatibilidad con la exportación de atributos IPv6 a estado de vínculo BGP (BGP-LS).
- Compatibilidad con BGP-LS IPv6 Network Layer Reachability Information (NLRIs) y exportación de atributos desde la tabla de enrutamiento lsdist.0 a la base de datos de ingeniería de tráfico.
Solo admitimos el protocolo de puerta de enlace interior (IGP) IS-IS.
- Beneficios de los prefijos IPv6 y la adyacencia IPv6 SID Compatibilidad con MPLS en bases de datos de ingeniería de tráfico y BGP-LS
- Implementación
- Compatibilidad para agregar los atributos IPv6 y la información a la base de datos de ingeniería de tráfico desde IS-IS
- Compatibilidad con la importación de atributos IPv6 desde la base de datos de ingeniería de tráfico a la tabla de enrutamiento lsdist.0
- Compatibilidad con la exportación de atributos IPv6 a BGP-LS
- Compatibilidad con NLRI IPv6 BGP-LS y exportación de atributos desde la tabla de enrutamiento lsdist.0 a la base de datos de ingeniería de tráfico
- Comando de configuración
Beneficios de los prefijos IPv6 y la adyacencia IPv6 SID Compatibilidad con MPLS en bases de datos de ingeniería de tráfico y BGP-LS
Hemos mejorado los resultados de los comandos operativos existentes y hemos agregado los comandos show para mostrar la lista de prefijos IPv6 e IPv4, respectivamente, en la base de datos de ingeniería de tráfico.
show ted database extensive: se ha mejorado el resultado para incluir los atributos MPLS de enrutamiento de segmentos (SR) IPv6.show ted link detail: se mejoró la salida para incluir los atributos SR-MPLS IPv6 correspondientes a los vínculos de la base de datos de ingeniería de tráfico.show route table lsdist.0 [extensive | detail]: se mejoró la salida para incluir los atributos IPv6 NLRI e IPv6 SR-MPLS.show route: se incluyeron parámetros adicionales para filtrar las entradas y verlas en la tabla lsdist.0. Hemos agregado opciones adicionales para incluir prefijos IPv6. Las opciones sonte-ipv6-prefix-ipv6-addryte-ipv6-prefix-node-iso.show ted ipv6-prefix: se agregó el comando show para mostrar la lista de prefijos IPv6 en la base de datos de ingeniería de tráfico.show ted ipv4-prefix: se agregó el comando show para mostrar la lista de prefijos IPv4 en la base de datos de ingeniería de tráfico.
Implementación
BGP-LS recupera los datos de ingeniería de tráfico (TE) de la base de datos de ingeniería de tráfico y distribuye los datos a sus pares BGP. Para lograr esto, la base de datos de ingeniería de tráfico convierte sus enlaces, nodos y entradas de prefijo (IPv4 e IPv6) en forma de rutas. La siguiente figura muestra el flujo de información desde BGP-LS y hacia BGP-LS.
Compatibilidad para agregar los atributos IPv6 y la información a la base de datos de ingeniería de tráfico desde IS-IS
Junos OS admite atributos SR-MPLS para el plano de datos IPv6, intercambiados a través de IS-IS IGP. Como resultado de esta mejora, se pueden agregar atributos e información IPv6 a la base de datos de ingeniería de tráfico (TED).
Compatibilidad con la importación de atributos IPv6 desde la base de datos de ingeniería de tráfico a la tabla de enrutamiento lsdist.0
Atributos IPv6 recibidos de IS-IS IGP y almacenados en la base de datos de ingeniería de tráfico a medida que los nodos, vínculos y prefijos se convierten en rutas. Estas rutas se someten a la política de importación de bases de datos de ingeniería de tráfico. Si la política lo permite, las rutas se instalan en una tabla de enrutamiento denominada lsdist.0.
Compatibilidad con la exportación de atributos IPv6 a BGP-LS
BGP está configurado para exportar o anunciar rutas desde la tabla lsdist.0, sujeto a la política. Es un escenario rutinario para cualquier originación de ruta en BGP. A continuación, BGP propaga estas rutas como cualquier otra NLRI a los pares con BGP-LS configurado y establecido con la vecindad de BGP. BGP almacena las NLRI BGP-LS recibidas en forma de rutas en la tabla lsdist.0, que es la misma tabla que almacena las rutas BGP-LS originadas localmente. Como resultado de esta funcionalidad, la información IPv6 recién agregada se propaga a BGP como atributos de NLRI de vínculo ya existente y como un nuevo prefijo IPv6 NLRI.
Compatibilidad con NLRI IPv6 BGP-LS y exportación de atributos desde la tabla de enrutamiento lsdist.0 a la base de datos de ingeniería de tráfico
En Junos OS, las NLRI BGP-LS recibidas instaladas en forma de rutas en la tabla lsdist.0 se someten a la política de exportación de bases de datos de ingeniería de tráfico. Si la política lo permite, los atributos IPv6 y la información de estas rutas se agregan a la instancia local de la base de datos de ingeniería de tráfico.
Comando de configuración
El comando de política BGP-TE se ha mejorado para permitir el filtrado de NLRI basado en el prefijo IPv6 NLRI. Consulte ipv6-prefix.
Consulte también
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.