Configuración de ingeniería de tráfico MPLS

Uso de LSP para el reenvío de tráfico BGP e IGP

Puede configurar BGP y los IGP para que usen LSP para reenviar el tráfico destinado a enrutadores de salida incluyendo la bgp-igp opción para la traffic-engineering instrucción. La bgp-igp opción hace que todas las rutas inet.3 se muevan a la tabla de enrutamiento inet.0.

En el enrutador de entrada, incluya bgp-igp la opción para la traffic-engineering instrucción:

Puede incluir esta instrucción en los siguientes niveles jerárquicos:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

  Nota:

  La bgp-igp opción de la traffic-engineering instrucción no se puede configurar para VPN). Las VPN requieren que las rutas estén en la tabla de enrutamiento inet.3.

Uso de LSP para reenvío en redes privadas virtuales

Las VPN requieren que las rutas permanezcan en la tabla de enrutamiento inet.3 para funcionar correctamente. En el caso de las VPN, configure la bgp-igp-both-ribs opción de la traffic-engineering instrucción para que el BGP y los IGP utilicen LSP para reenviar el tráfico destinado a los enrutadores de salida. La bgp-igp-both-ribs opción instala las rutas de entrada tanto en la tabla de enrutamiento inet.0 (para rutas de unidifusión IPv4) como en la tabla de enrutamiento inet.3 (para información de ruta MPLS).

En el enrutador de entrada, incluya la traffic-engineering bgp-igp-both-ribs instrucción:

Puede incluir esta instrucción en los siguientes niveles jerárquicos:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Cuando se utiliza la bgp-igp-both-ribs instrucción, las rutas de la tabla inet.3 se copian en la tabla inet.0. Las rutas copiadas tienen señal LDP o RSVP, y es probable que tengan una preferencia inferior a otras rutas en inet.0. Las rutas con una preferencia inferior tienen más probabilidades de ser elegidas como rutas activas. Esto puede ser un problema porque las políticas de enrutamiento solo actúan sobre rutas activas. Para evitar este problema, utilice la mpls-forwarding opción en su lugar.

Uso de rutas RSVP y LDP para reenvío, pero no para selección de rutas

Si configura las bgp-igp opciones o bgp-igp-both-ribs para la traffic-engineering instrucción, los LSP de alta prioridad pueden reemplazar a las rutas IGP de la tabla de enrutamiento inet.0. Es posible que las rutas IGP ya no se redistribuyan porque ya no son las rutas activas.

Si configura la mpls-forwarding opción para la instrucción, los LSP se utilizan para el reenvío, pero se excluyen de la traffic-engineering selección de ruta. Estas rutas se agregan a las tablas de enrutamiento inet.0 e inet.3. Los LSP de la tabla de enrutamiento inet.0 tienen una preferencia inferior cuando se selecciona la ruta activa. Sin embargo, los LSP de la tabla de enrutamiento inet.3 tienen una preferencia normal y, por lo tanto, se utilizan para seleccionar el reenvío de los próximos saltos.

Cuando se activa la mpls-forwarding opción, las rutas cuyo estado es ForwardingOnly se prefieren para el reenvío incluso si su preferencia es inferior a la de la ruta actualmente activa. Para examinar el estado de una ruta, ejecute un show route detail comando.

Para usar LSP para reenvío pero excluirlos de la selección de ruta, incluya la mpls-forwarding opción para la traffic-engineering instrucción:

Puede incluir esta instrucción en los siguientes niveles jerárquicos:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Al configurar la opción, las mpls-forwarding rutas de acceso directo de IGP se copian únicamente en la tabla de enrutamiento inet.0.

A diferencia de la bgp-igp-both-ribs opción, la mpls-forwarding opción le permite usar las rutas señalizadas por LDP y RSVP para el reenvío, y mantener las rutas BGP e IGP activas con fines de enrutamiento para que las políticas de enrutamiento puedan actuar sobre ellas.

Por ejemplo, supongamos que un enrutador ejecuta BGP y tiene una ruta BGP de 10.10.10.1/32 que necesita enviar a otro altavoz BGP. Si utiliza la bgp-igp-both-ribs opción y el enrutador también tiene una ruta de conmutación de etiquetas (LSP) a 10.10.10.1, la ruta MPLS para 10.10.10.1 se activa en la tabla de enrutamiento inet.0. Esto impide que el enrutador anuncie la ruta 10.10.10.1 al otro enrutador BGP. Por otro lado, si usa la mpls-forwarding opción en lugar de la bgp-igp-both-ribs opción, la ruta BGP 10.10.10.1/32 se anuncia al otro altavoz BGP y el LSP se sigue utilizando para reenviar tráfico al destino 10.10.10.1.

Publicidad de la métrica LSP en resumen LSA

Puede configurar MPLS y OSPF para tratar un LSP como un vínculo. Esta configuración permite que otros enrutadores de la red utilicen este LSP. Para lograr este objetivo, debe configurar la ingeniería de tráfico MPLS y OSPF para anunciar la métrica LSP en resumen de LSA.

Para MPLS, incluya las traffic-engineering bgp-igp instrucciones y label-switched-path :

Puede incluir estas instrucciones en los siguientes niveles jerárquicos:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

Para OSPF, incluya la lsp-metric-into-summary declaración:

Puede incluir esta instrucción en los siguientes niveles jerárquicos:

• [edit protocols ospf traffic-engineering shortcuts]

• [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

Para obtener más información acerca de la ingeniería de tráfico OSPF, consulte la Biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.

Requisitos de ingeniería de tráfico de Inter-AS

El establecimiento y funcionamiento adecuados de los LSP diseñados para el tráfico interAS dependen de los siguientes requisitos de red, todos los cuales deben cumplirse:

• Todos los AS están bajo el control de un único proveedor de servicios.

• OSPF se usa como protocolo de enrutamiento dentro de cada AS y EBGP se usa como protocolo de enrutamiento entre los AS.

• La información de ASBR está disponible dentro de cada AS.

• OSPF distribuye la información de enrutamiento de EBGP y una malla completa de IBGP está en su lugar dentro de cada AS.

• Los LSP de tránsito no se configuran en los vínculos interAS, sino que se configuran entre ASBR de punto de entrada y salida en cada AS.

• El vínculo EBGP entre ASBR en diferentes AS es un vínculo directo y debe configurarse como un vínculo pasivo de ingeniería de tráfico bajo OSPF. La dirección del vínculo remoto en sí, no el circuito cerrado ni ninguna otra dirección de vínculo, se utiliza como identificador de nodo remoto para este vínculo pasivo. Para obtener más información acerca de la configuración del modo de ingeniería de tráfico pasivo de OSPF, consulte Configuración del modo TE pasivo de OSPF.

Además, la dirección utilizada para el nodo remoto del vínculo de ingeniería de tráfico pasivo OSPF debe ser la misma que la dirección utilizada para el vínculo EBGP. Para obtener más información acerca de OSPF y BGP en general, consulte la Biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.

Limitaciones de la ingeniería de tráfico de Inter-AS

Solo se admite la señalización jerárquica o anidada de LSP para los LSP diseñados para el tráfico interAS. Solo se admiten LSP punto a punto (no hay soporte punto a multipunto).

Además, se aplican las siguientes limitaciones. Cualquiera de estas condiciones es suficiente para hacer imposibles los LSP diseñados para el tráfico interAS, incluso si se cumplen los requisitos anteriores.

• No se admite el uso de BGP de múltiples saltos.

• No se admite el uso de políticas o topologías que impidan que las rutas BGP se conozcan dentro del AS.

• No se admiten varios ASBR en una LAN entre pares EBGP. Solo se admite un ASBR en una LAN entre pares EBGP (otros ASBR pueden existir en la LAN, pero no se pueden anunciar).

• No se admiten reflectores de ruta ni políticas que oculten información de ASBR o impidan que la información de ASBR se distribuya dentro de los AS.

• No se admiten LSP bidireccionales (los LSP son unidireccionales desde la perspectiva de la ingeniería de tráfico).

• No se admiten topologías con rutas interAS e intra-AS al mismo destino.

Además, varias características que son rutinarias con todos los LSP no son compatibles con la ingeniería de tráfico interAS:

• No se admiten los colores de los vínculos del grupo de administradores.

• No se admite el modo de espera secundario.

• No se admite la reoptimización.

• No se admite el crankback en enrutadores de tránsito.

• No se admite el cálculo de rutas diversas.

• No se admite el reinicio correcto.

Estas listas de limitaciones o características no compatibles con los LSP de ingeniería de tráfico interAS no son exhaustivas.

Configuración del modo TE pasivo de OSPF

Normalmente, los protocolos de enrutamiento interior, como OSPF, no se ejecutan en vínculos entre AS. Sin embargo, para que la ingeniería de tráfico interAS funcione correctamente, la información sobre el vínculo interAS, en particular, la dirección en la interfaz remota, debe estar disponible dentro del AS. Esta información normalmente no se incluye ni en los mensajes de accesibilidad del EBGP ni en los anuncios de enrutamiento de OSPF.

Para inundar esta información de dirección de vínculo dentro del AS y ponerla a disposición para cálculos de ingeniería de tráfico, debe configurar el modo pasivo OSPF para la ingeniería de tráfico en cada interfaz interAS. También debe proporcionar la dirección remota para que OSPF la distribuya e incluya en la base de datos de ingeniería de tráfico.

Para configurar el modo pasivo OSPF para la ingeniería de tráfico en una interfaz interAS, incluya la passive instrucción para el vínculo en el nivel de [edit protocols ospf area area-id interface interface-name] jerarquía:

OSPF debe estar configurado correctamente en el enrutador. En el ejemplo siguiente se configura el vínculo so-1/1/0 interAS para distribuir información de ingeniería de tráfico con OSPF dentro del AS. La dirección IP remota es 192.168.207.2.

Reenvío de paquetes basado en el intercambio de etiquetas

El proceso de reenvío de paquetes en cada enrutador se basa en el concepto de intercambio de etiquetas. Este concepto es similar a lo que ocurre en cada conmutador de modo de transferencia asíncrono (ATM) en un circuito virtual permanente (PVC). Cada paquete MPLS lleva un encabezado de encapsulación de 4 bytes que contiene un campo de etiqueta de longitud fija de 20 bits. Cuando un paquete que contiene una etiqueta llega a un enrutador, el enrutador examina la etiqueta y la copia como un índice a su tabla de reenvío MPLS. Cada entrada de la tabla de reenvío contiene un par de etiquetas de entrada de interfaz asignado a un conjunto de información de reenvío que se aplica a todos los paquetes que llegan a la interfaz específica con la misma etiqueta de entrada.

Cómo atraviesa un paquete una red troncal MPLS

En esta sección se describe cómo se procesa un paquete IP a medida que atraviesa una red troncal MPLS.

En el borde de entrada de la red troncal MPLS, el enrutador de entrada examina el encabezado IP. Sobre la base de este análisis, el paquete se clasifica, se le asigna una etiqueta, se encapsula en un encabezado MPLS y se reenvía hacia el siguiente salto en el LSP. MPLS proporciona un alto grado de flexibilidad en la forma en que un paquete IP puede ser asignado a un LSP. Por ejemplo, en la implementación de ingeniería de tráfico de Junos, todos los paquetes que llegan al enrutador de entrada y que están destinados a salir del dominio MPLS en el mismo enrutador de salida se reenvían a lo largo del mismo LSP.

Una vez que el paquete comienza a atravesar el LSP, cada enrutador utiliza la etiqueta para tomar la decisión de reenvío. La decisión de reenvío de MPLS se toma independientemente del encabezado IP original: la interfaz y la etiqueta entrantes se utilizan como claves de búsqueda en la tabla de reenvío de MPLS. La etiqueta antigua se sustituye por una nueva etiqueta y el paquete se reenvía al siguiente salto a lo largo del LSP. Este proceso se repite en cada enrutador del LSP hasta que el paquete llega al enrutador de salida.

Cuando el paquete llega al enrutador de salida, la etiqueta se quita y el paquete sale del dominio MPLS. Luego, el paquete se reenvía en función de la dirección IP de destino contenida en el encabezado IP original del paquete de acuerdo con la ruta más corta tradicional calculada por el protocolo de enrutamiento IP.

Componente de distribución de información

La ingeniería de tráfico requiere conocimientos detallados sobre la topología de red, así como información dinámica sobre la carga de la red. Para implementar el componente de distribución de información, se definen extensiones simples a los IGP. Los atributos de vínculo se incluyen como parte del anuncio de estado de vínculo de cada router. Las extensiones IS-IS incluyen la definición de nuevos valores de longitud de tipo (TLV), mientras que las extensiones OSPF se implementan con anuncios de estado de enlace (LSA) opacos. El algoritmo de inundación estándar utilizado por los IGP de estado de vínculo garantiza que los atributos de vínculo se distribuyan a todos los enrutadores del dominio de enrutamiento. Algunas de las extensiones de ingeniería de tráfico que se agregarán al anuncio de estado de vínculo IGP incluyen ancho de banda máximo de vínculo, ancho de banda máximo reservado, reserva de ancho de banda actual y coloreado de vínculos.

Cada enrutador mantiene los atributos de vínculo de red y la información de topología en una base de datos especializada en ingeniería de tráfico. La base de datos de ingeniería de tráfico se utiliza exclusivamente para calcular rutas explícitas para la colocación de LSP en la topología física. Se mantiene una base de datos separada para que el cálculo de ingeniería de tráfico posterior sea independiente del IGP y de la base de datos de estado de vínculo del IGP. Mientras tanto, el IGP continúa su operación sin modificaciones, realizando el cálculo tradicional de la ruta más corta basada en la información contenida en la base de datos de estado de enlace del enrutador.

Componente de selección de ruta

Después de que el IGP inunde los atributos del vínculo de red y la información de topología y la coloque en la base de datos de ingeniería de tráfico, cada enrutador de entrada utiliza la base de datos de ingeniería de tráfico para calcular las rutas de su propio conjunto de LSP en todo el dominio de enrutamiento. La ruta para cada LSP se puede representar mediante una ruta explícita estricta o suelta. Una ruta explícita es una secuencia preconfigurada de enrutadores que deben formar parte de la ruta física del LSP. Si el enrutador de entrada especifica todos los enrutadores del LSP, se dice que el LSP se identifica mediante una ruta explícita estricta. Si el enrutador de entrada especifica sólo algunos de los enrutadores del LSP, el LSP se describe como una ruta explícita suelta. El soporte para rutas explícitas estrictas y sueltas permite que el proceso de selección de rutas tenga una amplia libertad siempre que sea posible, pero que se limite cuando sea necesario.

El enrutador de entrada determina la ruta física de cada LSP aplicando un algoritmo de Restricted Shortest Path First (CSPF) a la información de la base de datos de ingeniería de tráfico. CSPF es un algoritmo de ruta más corta primero que se ha modificado para tener en cuenta restricciones específicas cuando se calcula la ruta más corta a través de la red. La entrada en el algoritmo CSPF incluye:

• Información de estado de vínculo de topología aprendida del IGP y mantenida en la base de datos de ingeniería de tráfico

• Atributos asociados con el estado de los recursos de red (como el ancho de banda total del vínculo, el ancho de banda del vínculo reservado, el ancho de banda del vínculo disponible y el color del vínculo) que llevan las extensiones IGP y se almacenan en la base de datos de ingeniería de tráfico

• Atributos administrativos necesarios para admitir el tráfico que atraviesa el LSP propuesto (como los requisitos de ancho de banda, el recuento máximo de saltos y los requisitos de política administrativa) que se obtienen de la configuración del usuario

A medida que CSPF considera cada nodo candidato y vínculo para un nuevo LSP, acepta o rechaza un componente de ruta específico en función de la disponibilidad de recursos o de si la selección del componente infringe las restricciones de la política de usuario. El resultado del cálculo de CSPF es una ruta explícita que consiste en una secuencia de direcciones de enrutador que proporciona la ruta más corta a través de la red que cumple con las restricciones. A continuación, esta ruta explícita se pasa al componente de señalización, que establece el estado de reenvío en los enrutadores a lo largo del LSP.

Componente de señalización

No se sabe que un LSP sea viable hasta que sea realmente establecido por el componente de señalización. El componente de señalización, que es responsable de establecer el estado de LSP y distribuir etiquetas, se basa en una serie de extensiones para confirmar su asistencia:

• El objeto Ruta explícita permite que un mensaje de ruta RSVP atraviese una secuencia explícita de enrutadores que es independiente del enrutamiento IP convencional de ruta más corta. La ruta explícita puede ser estricta o suelta.

• El objeto Label Request permite que el mensaje de ruta RSVP solicite que los enrutadores intermedios proporcionen un enlace de etiqueta para el LSP que está estableciendo.

• El objeto Label permite confirmar su asistencia para admitir la distribución de etiquetas sin cambiar sus mecanismos existentes. Dado que el mensaje RSVP Resv sigue la ruta inversa del mensaje de ruta RSVP, el objeto Label admite la distribución de etiquetas de los nodos descendentes a los nodos ascendentes.

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
• Implementación

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.

Figura 1: Implementación de Junos OS de la distribución de estado de vínculo BGP

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.

Nota:

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

Nota:

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

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.

Figura 2: Enrutamiento de paquetes fuente de estado de vínculo BGP en redes (SPRING)

• 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.0 tabla 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.0 enrutamiento. Esta política anuncia una entrada aprendida de la base de datos de ingeniería de tráfico.

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:

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:

Beneficios de los aviones de transporte con clase BGP

• División de red: las capas de servicio y transporte están desacopladas entre sí, sentando las bases para la división de red y la virtualización con la división de extremo a extremo en múltiples dominios, lo que reduce significativamente el CAPEX.

• Interoperabilidad entre dominios: extiende el despliegue de clases de transporte a través de dominios que cooperan para que los diferentes protocolos de señalización de transporte en cada dominio interoperen. Concilia cualquier diferencia entre los espacios de nombres de comunidad extendidos que pueden estar en uso en cada dominio.

• Resolución coloreada con reserva: permite la resolución sobre túneles de color (RSVP, algoritmo flexible IS-IS) con opciones flexibles de reserva sobre túneles de mejor esfuerzo o cualquier otro túnel de color.

• Calidad de servicio: personaliza y optimiza la red para cumplir los requisitos de SLA de extremo a extremo.
• Aprovechamiento de las implementaciones existentes: admite protocolos de tunelización bien implementados, como RSVP, junto con protocolos nuevos, como el algoritmo flexible IS-IS, lo que preserva el retorno de la inversión y reduce los gastos operativos.

Terminología de los planos de transporte con clase BGP

En esta sección se proporciona un resumen de los términos más utilizados para comprender el plano de transporte con clase BGP.

• Nodo de servicio: dispositivos perimetrales del proveedor de entrada (PE) que envían y reciben rutas de servicio (Internet y VPN de capa 3).

• Nodo de borde: dispositivo en el punto de conexión de diferentes dominios (áreas IGP o AS).

• Nodo de transporte: dispositivo que envía y recibe rutas de unidifusión etiquetada con BGP (LU).

• BGP-VPN: VPN creadas con mecanismos de RFC4364.

• Destino de ruta (RT): tipo de comunidad extendida que se utiliza para definir la pertenencia a VPN.

• Diferenciador de ruta (RD): identificador utilizado para distinguir a qué VPN o servicio de LAN privada virtual (VPLS) pertenece una ruta. Cada instancia de enrutamiento debe tener asociado un diferenciador de ruta único.

• Esquema de resolución: se usa para resolver la dirección del protocolo del próximo salto (PNH) en las RIB de resolución que proporcionan respaldo.

  Mapean las rutas a las diferentes RIB de transporte en el sistema basado en el mapeo de la comunidad.

• Familia de servicios: familia de direcciones BGP que se usa para anunciar rutas para el tráfico de datos, en lugar de túneles.

• Familia de transporte : familia de direcciones BGP utilizada para túneles publicitarios, que a su vez son utilizados por las rutas de servicio para la resolución.

• Túnel de transporte: túnel sobre el cual un servicio puede colocar tráfico, por ejemplo, GRE, UDP, LDP, RSVP, SR-TE, BGP-LU.

• Dominio de túnel: dominio de la red que contiene nodos de servicio y nodos de borde bajo un único control administrativo que tiene un túnel entre ellos. Se puede crear un túnel de extremo a extremo que abarca varios dominios de túnel adyacentes uniendo los nodos mediante etiquetas.

• Clase de transporte: grupo de túneles de transporte que ofrecen el mismo tipo de servicio.

• Clase de transporte RT: nuevo formato de destino de ruta que se utiliza para identificar una clase de transporte específica.

  Un nuevo formato de Destino de ruta que se utiliza para identificar una clase de transporte específica.

• RIB de transporte: en el nodo de servicio y el nodo de borde, una clase de transporte tiene una RIB de transporte asociada que contiene sus rutas de túnel.

• RTI de transporte: una instancia de enrutamiento; contenedor de RIB de transporte y clase de transporte asociada Route Target y Route Distinguisher.

• Plano de transporte: conjunto de RTI de transporte que importan la misma clase de transporte RT. Estos, a su vez, se unen para abarcar los límites del dominio del túnel utilizando un mecanismo similar a la opción b de Inter-AS para intercambiar etiquetas en los nodos de borde (nexthop-self), formando un plano de transporte de extremo a extremo.

• Asignación de comunidad: comunidad en una ruta de servicio que se asigna para resolver una clase de transporte.

Descripción de los planos de transporte con clase BGP

Puede usar planos de transporte con clase BGP para configurar clases de transporte para clasificar un conjunto de túneles de transporte en una red intra-AS en función de las características de ingeniería de tráfico y usar estos túneles de transporte para asignar rutas de servicio con el SLA deseado y la reserva prevista.

Los planos de transporte con clase BGP pueden extender estos túneles a redes entre dominios que abarcan varios dominios (áreas AS o IGP) conservando la clase de transporte. Para ello, debe configurar la familia BGP de capa de transporte de transdeporte con clase BGP entre los nodos de borde y servicio.

Tanto en implementaciones de interAS como intraAS, puede haber muchos túneles de transporte (MPLS LSP, IS-IS algoritmo flexible, SR-TE) creados a partir de los nodos de servicio y borde. Los LSP pueden señalizarse utilizando diferentes protocolos de señalización en diferentes dominios y pueden configurarse con diferentes características de ingeniería de tráfico (clase o color). El extremo del túnel de transporte también actúa como extremo de servicio y puede estar presente en el mismo dominio de túnel que el nodo de entrada del servicio, o en un dominio adyacente o no adyacente. Puede utilizar planos de transporte con clase BGP para resove servicios a través de LSP con ciertas características de ingeniería de tráfico, ya sea dentro de un único dominio o en varios dominios.

Los planos de transporte con clase BGP reutilizan la tecnología BGP-VPN, manteniendo los dominios de túnel débilmente acoplados y coordinados.

• La información de accesibilidad de la capa de red (NLRI) es RD:TunnelEndpoint que se utiliza para ocultar rutas.
• El destino de ruta indica la clase de transporte de los LSP y pierde rutas a la RIB de transporte correspondiente en el dispositivo de destino.
• Cada protocolo de tunelización de transporte instala una ruta de entrada en la tabla de enrutamiento transport-class.inet.3, modela la clase de transporte de túnel como destino de ruta VPN y recopila los LSP de la misma clase de transporte en la tabla de enrutamiento transport-class.inet.3 transport-rib.

• Las rutas de esta instancia de enrutamiento se anuncian en el plano de transporte con clase BGP (transporte inet) AFI-SAFI siguiendo procedimientos similares a RFC-4364.

• Al cruzar el límite del vínculo interAS, debe seguir los procedimientos de la opción b para unir los túneles de transporte en estos dominios adyacentes.

  Del mismo modo, al cruzar regiones intra-AS, debe seguir los procedimientos de la opción b para unir los túneles de transporte en los diferentes dominios TE.

• Puede definir esquemas de resolución para especificar la intención de la variedad de clases de transporte en un orden de reserva.

• Puede resolver rutas de servicio y rutas de transporte con clase BGP sobre estas clases de transporte, llevando la comunidad de mapas en ellas.

La familia de transporte con clase BGP se ejecuta junto con la familia de capas de transporte BGP-LU. En una red MPLS sin interrupciones que ejecuta BGP-LU, cumplir con los estrictos requisitos de SLA de 5G es un desafío, ya que las características de ingeniería de tráfico de los túneles no se conocen ni se conservan más allá de los límites del dominio. Los planos de transporte con clase BGP proporcionan medios operacionalmente fáciles y escalables para anunciar múltiples rutas para loopbacks remotos junto con la información de la clase de transporte en la arquitectura MPLS perfecta. En las rutas de la familia de transporte con clase BGP, las diferentes rutas de SLA se representan mediante la comunidad extendida Ruta de transporte-Destino, que lleva el color de la clase de transporte. Los enrutadores BGP receptores utilizan esta ruta de destino de transporte para asociar la ruta de transporte con clase BGP con la clase de transporte adecuada. Al volver a anunciar las rutas de transporte con clase BGP, MPLS intercambia rutas, interconecta los túneles intra-AS de la misma clase de transporte, formando así un túnel de extremo a extremo que conserva la clase de transporte.

Implementación intra-AS de planos de transporte con clase BGP

Figura 4 muestra una topología de red con escenarios de antes y después de la implementación de planos de transporte con clase BGP en un dominio intraAS. Los dispositivos PE11 y PE12 utilizan RSVP LSP como túnel de transporte y todas las rutas del túnel de transporte se instalan en RIB inet.3. La implementación de planos de tranordenación con clase BGP permite que los túneles de transporte RSVP sean conscientes del color de manera similar a los túneles de enrutamiento de segmentos.

Figura 4: Dominio intra-AS: Escenarios antes y después para la implementación de planos de transporte con clase BGP

Para clasificar túneles de transporte en clase de transporte BGP en una configuración intraAS:

1. Defina la clase de transporte en el nodo de servicio (dispositivos de PE de entrada), por ejemplo, oro y bronce, y asigne valores de comunidad de colores a la clase de transporte definida.

   Configuración de ejemplo:

2. Asocie el túnel de transporte a una clase de transporte específica en el nodo de entrada de los túneles.

   Configuración de ejemplo:

Funcionalidad del plano de transporte con clase del BGP intraAS:

• El transporte con clase BGP crea RIB de transporte predefinidas por clase de transporte con nombre (oro y bronce) y deriva automáticamente la comunidad de mapeo a partir de su valor de color (100 y 200).
• Las rutas de transporte intra-AS se rellenan en las RIB de transporte mediante el protocolo de túnel cuando está asociado a una clase de transporte.

  En este ejemplo, las rutas RSVP LSP asociadas con la clase de transporte gold (color 100) y la clase de transporte bronze (color 200) se instalan en las RIB de transporte junos-rti-tc-<100>.inet.3 y junos-rti-tc-<200>.inet.3, respectivamente.

• El nodo de servicio (PE de entrada) hace coincidir la comunidad de colores extendida (color:0:100 y color:0:200) de la ruta de servicio con la comunidad de mapeo en las RIB de resolución predefinidas y resuelve el siguiente salto de protocolo (PNH) en las RIB de transporte correspondientes (junos-rti-tc-<100>.inet.3 o junos-rti-tc-<200>.inet.3).
• Las rutas BGP se enlazan a un esquema de resolución llevando la comunidad de mapeo asimilado.
• Cada clase de transporte crea automáticamente dos esquemas de resolución predefinidos y deriva automáticamente la comunidad de asignación.

  Un esquema de resolución es para resolver rutas de servicio que usan Color:0:<val> como comunidad de mapeo.

  El otro esquema de resolución es para resolver rutas de transporte que usan Transport-Target:0:<val> como comunidad cartográfica.

• Si el PNH de la ruta de servicio no se puede resolver mediante las RIB enumeradas en el esquema de resolución predefinido, puede recurrir a la tabla de enrutamiento inet.3.
• También puede configurar la reserva entre RIB de transporte de diferentes colores mediante esquemas de resolución definidos por el usuario en la jerarquía de [edit routing-options resolution scheme] configuración.

Implementación de Inter-AS de planos de transporte con clase BGP

En una red interAS, BGP-LU se convierte en una red de transporte con clase BGP después de configurar un mínimo de dos clases de transporte (oro y bronce) en todos los nodos de servicio o dispositivos PE y nodos de borde (ABR y ASBR).

Para convertir los túneles de transporte en transporte con clase BGP:

1. Defina la clase de transporte en los nodos de servicio (dispositivos de PE de entrada) y los nodos de borde (ABR y ASBR), por ejemplo, oro y broze.

   Configuración de ejemplo:

2. Asocie los túneles de transporte a una clase de transporte específica en el nodo de entrada de los túneles (PE, ABR y ASBR de entrada).

   Configuración de ejemplo:

   Para RSVP LSP

   Para el algoritmo FLXIBLE IS-IS

3. Habilite una nueva familia para el transporte con clase BGP (transporte inet) y BGP-LU (unidifusión etiquetada con inet) en la red.

   Configuración de ejemplo:

4. Anuncie las rutas de servicio desde el dispositivo de PE de salida con la comunidad de color extendida adecuada.

   Configuración de ejemplo:

Funcionalidad de plano de transporte con clase de InterAS BGP:

1. Los planos de transporte con clase BGP crean RIB de transporte predefinidas por clase de transporte con nombre (oro y bronce) y derivan automáticamente la comunidad de mapeo de su valor de color.

2. Las rutas de transporte intra-AS se rellenan en las RIB de transporte mediante protocolos de tunelización cuando se asocian a una clase de transporte.

   Por ejemplo, las rutas de túnel de transporte asociadas con la clase de transporte oro y bronce se instalan en las RIB de transporte junos-rti-tc-<100>.inet.3 y junos-rti-tc-<200>.inet.3, respectivamente.

3. Los planos de transporte con clase BGP utilizan un diferenciador de ruta y un destino de ruta únicos cuando copia las rutas del túnel de transporte de cada RIB de transporte a la tabla de enrutamiento bgp.transport.3.
4. Los nodos de borde anuncian rutas desde la tabla de enrutamiento bgp.transport.3 a sus pares en otros dominios si el transporte inet familiar se negocia en la sesión BGP.
5. El nodo de borde receptor instala estas rutas bgp-ct en la tabla de enrutamiento bgp.transport.3 y copia estas rutas según el destino de ruta de transporte en las RIB de transporte adecuadas.
6. El nodo de servicio compara la comunidad de colores de la ruta de servicio con una comunidad de asignación en los esquemas de resolución y resuelve PNH en la RIB de transporte correspondiente ( junos-rti-tc-<100>.inet.3 o junos-rti-tc-<200>.inet.3).
7. Los nodos fronterizos utilizan esquemas de resolución predefinidos para la resolución de PNH de rutas de transporte.
8. Predefinidos o definidos por el usuario, ambos esquemas de resolución admiten la resolución PNH de rutas de servicio. Predefinido usa inet.3 como reserva, y el esquema de resolución definido por el usuario permite usar la lista de RIB de transporte en el orden especificado al resolver PNH.
9. Si el PNH de la ruta de servicio no se puede resolver mediante las RIB enumeradas en el esquema de resolución definido por el usuario, se descarta la ruta.

Descripción general del transporte con clase BGP (BGP-CT) con túneles SR-TE de colores subyacentes

Beneficios de BGP-CT con túneles SR-TE de colores subyacentes

• Resuelve problemas de escala que puedan surgir en el futuro a medida que la red crece.
• Proporciona interconectividad para dominios que usan diferentes tecnologías.
• Desacopla los servicios y las capas de transporte, lo que resulta en una red completamente distribuida.
• Proporciona administración independiente del ancho de banda mediante un controlador de ingeniería de tráfico dentro del dominio para SR-TE.

Las grandes redes que crecen y evolucionan continuamente requieren una arquitectura de enrutamiento de segmentos sin fisuras. A partir de Junos OS versión 21.2,R1, admitimos BGP-CT con transporte subyacente como túneles SR-TE de colores. BGP-CT puede resolver rutas de servicio utilizando las RIB de transporte y calcular el siguiente salto. Los servicios que actualmente son compatibles con BGP-CT también pueden usar los túneles de color SR-TE subyacentes para la resolución de rutas. Los servicios ahora pueden usar los túneles de color SR-TE subyacentes, como los túneles de color estáticos, BGP SR-TE, RPD programable y PCEP. BGP-CT utiliza la accesibilidad del salto siguiente para resolver rutas de servicio en la clase de transporte deseada.

Para habilitar la resolución de ruta del servicio BGP-CT sobre túneles de color SR-TE subyacentes, incluya la use-transport-class instrucción en el nivel de [edit protocols source-packet-routing] jerarquía.

Mensajes de PathErr

Los mensajes PathErr informan de una amplia variedad de problemas por medio de diferentes números de código y subcódigo. Puede encontrar una lista completa de estos mensajes de PathErr en RFC 2205, Protocolo de reserva de recursos (RSVP), versión 1, especificación funcional y RFC 3209, RSVP-TE: Extensiones de RSVP para túneles LSP.

Al configurar la rsvp-error-hold-time instrucción, se examinan dos categorías de mensajes PathErr, que representan específicamente errores de vínculo:

• El ancho de banda del vínculo es bajo para este LSP: Ancho de banda solicitado no disponible: código 1, subcódigo 2

  Este tipo de mensaje PathErr representa un problema global que afecta a todos los LSP que transitan por el vínculo. Indican que el ancho de banda del vínculo real es inferior al requerido por el LSP, y que es probable que la información de ancho de banda en la base de datos de ingeniería de tráfico sea una sobreestimación.

  Cuando se recibe este tipo de error, el ancho de banda del vínculo disponible se reduce en la base de datos de ingeniería de tráfico local, lo que afecta a todos los cálculos futuros de LSP.

• Vínculo no disponible para este LSP:

  • Error de control de admisión: código 1, cualquier subcódigo excepto el 2

  • Errores de control de políticas: código 2

  • Servicio preferenciado: código 12

  • Problema de enrutamiento: no hay una ruta disponible hacia el destino: código 24, subcódigo 5

  Estos tipos de mensajes PathErr suelen ser pertinentes al LSP especificado. El fallo de este LSP no implica necesariamente que otros LSP también puedan fallar. Estos errores pueden indicar problemas de unidad de transferencia máxima (MTU), preferencia sobre el servicio (iniciada manualmente por el operador o por otro LSP con una prioridad más alta), que un vínculo del próximo salto está inactivo, que un vecino del próximo salto está inactivo o rechazo del servicio debido a consideraciones de política. Es mejor enrutar este LSP en particular lejos del enlace.

Identificación del vínculo del problema

Cada mensaje PathErr incluye la dirección IP del remitente. Esta información se propaga sin cambios hacia el enrutador de entrada. Una búsqueda en la base de datos de ingeniería de tráfico puede identificar el nodo que originó el mensaje PathErr.

Cada mensaje de PathErr contiene suficiente información para identificar la sesión RSVP que desencadenó el mensaje. Si se trata de un enrutador de tránsito, simplemente reenvía el mensaje. Si este enrutador es el enrutador de entrada (para esta sesión RSVP), tiene la lista completa de todos los nodos y enlaces que debe atravesar la sesión. Junto con la información del nodo de origen, el enlace se puede identificar de forma única.

Configuración del enrutador para mejorar la precisión de la base de datos de ingeniería de tráfico

Para mejorar la precisión de la base de datos de ingeniería de tráfico, configure la rsvp-error-hold-time instrucción. Cuando se configura esta instrucción, un nodo de origen (entrada de un LSP RSVP) aprende de los errores de su LSP supervisando los mensajes de PathErr transmitidos desde nodos descendentes. La información de los mensajes de PathErr se incorpora en cálculos posteriores de LSP, lo que puede mejorar la precisión y la velocidad de la configuración de LSP. Algunos mensajes PathErr también se usan para actualizar la información de ancho de banda de la base de datos de ingeniería de tráfico, lo que reduce las incoherencias entre la base de datos de ingeniería de tráfico y la red.

Para configurar cuánto tiempo MPLS debe recordar los mensajes RSVP PathErr y tenerlos en cuenta en el cálculo de CSPF, incluya la rsvp-error-hold-time instrucción:

Puede incluir esta instrucción en los siguientes niveles jerárquicos:

• [edit protocols mpls]

• [edit logical-systems logical-system-name protocols mpls]

El tiempo puede ser un valor de 1 a 240 segundos. El valor predeterminado es de 25 segundos. La configuración de un valor de 0 deshabilita la supervisión de los mensajes PathErr.