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

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

Puede configurar el BGP y los IGP para que usen LSP para reenviar tráfico destinado a enrutadores de salida mediante la inclusión de 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 el IGP usen LSP para reenviar tráfico destinado a 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 están señalizadas por LDP o RSVP, y es probable que tengan una preferencia menor que otras rutas en inet.0. Es más probable que las rutas con una preferencia más baja se elijan como las rutas activas. Esto puede ser un problema, ya que 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 la selección de rutas

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

Si configura la opción para la mpls-forwardingtraffic-engineering instrucción, los LSP se utilizan para el reenvío, pero se excluyen de la 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 baja 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 los próximos saltos de reenvío.

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

Para usar LSP para el reenvío, pero excluirlos de la selección de ruta, incluya la mpls-forwarding opción de 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]

Cuando configure la opción, las mpls-forwarding rutas de acceso directo de IGP se copian solo 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 para fines de enrutamiento, de modo que las políticas de enrutamiento puedan actuar en consecuencia.

Por ejemplo, supongamos que un enrutador ejecuta BGP y tiene una ruta BGP de 10.10.10.1/32 que debe enviar a otro altavoz BGP. Si utiliza la opción y el bgp-igp-both-ribs enrutador también tiene una ruta de etiqueta conmutada (LSP) a 10.10.10.1, la ruta MPLS para 10.10.10.10.1 se activa en la tabla de enrutamiento inet.0. Esto impide que el enrutador andjunte la ruta 10.10.10.1 al otro enrutador BGP. Por otro lado, si utiliza 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.

Anunciar la métrica del LSP en el resumen de LSA

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

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 instrucció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 de OSPF, consulte la biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.

Requisitos de ingeniería de tráfico del inter-AS

El establecimiento y el funcionamiento adecuados de los LSP de tráfico diseñados entre AS 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.

• El OSPF se utiliza como protocolo de enrutamiento dentro de cada AS, y el EBGP se utiliza como protocolo de enrutamiento entre los AS.

• La información del ASBR está disponible en cada AS.

• La información de enrutamiento de EBGP se distribuye por OSPF, y una malla completa del IBGP está en su lugar dentro de cada AS.

• Los LSP de tránsito no están configurados en los vínculos del interAS, sino que se configuran entre LOS AS de entrada y salida en cada AS.

• El vínculo EBGP entre ASBR en diferentes ASS es un vínculo directo y debe configurarse como un vínculo de ingeniería de tráfico pasivo bajo OSPF. La dirección del vínculo remoto en sí, no la dirección de 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 de 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 del inter-AS

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

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

• No se admite el uso de BGP de varios sup.

• No se admite el uso de policías o topologías que impiden que se conozcan rutas del BGP dentro del AS.

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

• No se admiten reflectores o políticas de enrutamiento que ocultan la información de ASBR o impiden 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 de interAS e intraAS al mismo destino.

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

• No se admiten colores de vínculo de grupo de administración.

• No se admite la espera secundaria.

• No se admite la reoptimización.

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

• No se admite el cálculo de ruta diversa.

• No se admite el reinicio agraciado.

Estas listas de limitaciones o funciones no compatibles con LSP diseñados para el tráfico del interAS no son exhaustivas.

Configuración del modo de TE pasivo de OSPF

Por lo general, 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 del inter-AS funcione correctamente, la información sobre el vínculo del inter-AS, en particular la dirección en la interfaz remota, debe estar disponible en el AS. Esta información no se incluye normalmente ni en los mensajes de accesibilidad del EBGP ni en los anuncios de enrutamiento OSPF.

Para inundar esta información de dirección de vínculo dentro del AS y hacerla disponible 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 de interAS. También debe proporcionar la dirección remota para que OSPF 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 de interAS, incluya la passive instrucción para el vínculo en el [edit protocols ospf area area-id interface interface-name] nivel jerárquico:

El OSPF debe estar correctamente configurado en el enrutador. En el siguiente ejemplo, se configura el vínculo so-1/1/0 del 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 asincrónica (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 20 bits y longitud fija. Cuando un paquete que contiene una etiqueta llega a un enrutador, el enrutador la examina y la copia como índice en su tabla de reenvío MPLS. Cada entrada de la tabla de reenvío contiene un par de etiquetas entrantes de interfaz asignados 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 entrante.

Cómo un paquete atraviesa 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 encabezado IP es examinado por el enrutador de entrada. Según este análisis, el paquete se clasifica, se asigna una etiqueta, se encapsula en un encabezado MPLS y se reenvía al siguiente salto en el LSP. MPLS ofrece un alto grado de flexibilidad en la forma en que un paquete IP se puede asignar 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 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 usa 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 entrante y la etiqueta se utilizan como claves de búsqueda en la tabla de reenvío MPLS. La etiqueta antigua se sustituye por una nueva 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, se elimina la etiqueta y el paquete sale del dominio MPLS. Luego, el paquete se reenvía según la dirección IP de destino contenida en el encabezado IP original del paquete según la ruta tradicional más corta calculada por el protocolo de enrutamiento IP.

Componente de distribución de información

La ingeniería de tráfico requiere un conocimiento detallado de 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 de los IGP. Los atributos de vínculo se incluyen como parte del anuncio de estado de vínculo de cada enrutador. Las extensiones IS-IS incluyen la definición de nuevos valores de longitud de tipo (TTL), mientras que las extensiones de OSPF se implementan con anuncios de estado de vínculo (LSA) opacos. El algoritmo de inundación estándar utilizado por las 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 del estado del vínculo del IGP incluyen el ancho de banda máximo del vínculo, el ancho de banda máximo reservado, la reserva de ancho de banda actual y la coloración del vínculo.

Cada enrutador mantiene los atributos de los vínculos de red y la información de topología en una base de datos especializada de 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 independiente para que el cálculo posterior de ingeniería de tráfico sea independiente del IGP y de la base de datos de estado de vínculo del IGP. Mientras tanto, el IGP continúa su funcionamiento sin modificaciones, realizando el tradicional cálculo de la ruta más corta en función de la información contenida en la base de datos de estado de vínculo del enrutador.

Componente de selección de ruta

Después de que los atributos de los vínculos de red y la información de topología se inundan por el IGP y se colocan en la base de datos de ingeniería de tráfico, cada enrutador de entrada usa la base de datos de ingeniería de tráfico para calcular las rutas para su propio conjunto de LSP en el dominio de enrutamiento. La ruta de cada LSP se puede representar mediante una ruta explícita estricta o flexible. Una ruta explícita es una secuencia de enrutadores preconfigurada que debe 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 solo algunos de los enrutadores del LSP, el LSP se describe como una ruta explícita flexible. El soporte para rutas explícitas estrictas y sueltas permite que el proceso de selección de rutas tenga 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 primero de ruta más corta restringida (CSPF) a la información de la base de datos de ingeniería de tráfico. La CSPF es un algoritmo de primera ruta más corta que se ha modificado para tener en cuenta restricciones específicas cuando se calcula la ruta más corta en toda la red. La entrada al algoritmo de 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 se llevan a cabo por las extensiones de 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 requisitos de ancho de banda, recuento máximo de saltos y requisitos de política administrativa) que se obtienen de la configuración del usuario

A medida que CSPF considera cada nodo y vínculo candidatos para un nuevo LSP, acepta o rechaza un componente de ruta específico según la disponibilidad de recursos o 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 consta de una secuencia de direcciones de enrutador que proporciona la ruta más corta a través de la red que cumple con las restricciones. Esta ruta explícita se pasa luego 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 utilizable hasta que el componente de señalización lo establezca realmente. El componente de señalización, que se encarga de establecer el estado de LSP y de distribuir etiquetas, depende de una serie de extensiones a RSVP:

• El objeto Explicit Route 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 flexible.

• 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 que RSVP admita 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 desde nodos descendentes a nodos ascendentes.

Función de un protocolo de puerta de enlace interior

Un protocolo de puerta de enlace interior (IGP) es un tipo de protocolo utilizado para intercambiar información de enrutamiento entre dispositivos dentro de un sistema autónomo (AS). Según el método de computación de la mejor ruta a un destino, las 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 que utilizan direcciones de multidifusión y activa actualizaciones de enrutamiento hasta que todos los enrutadores que ejecutan el protocolo de estado de vínculo tengan información idéntica sobre el trabajo de internet. La mejor ruta a un destino se calcula en función de restricciones como el retraso máximo, el ancho de banda mínimo disponible y la afinidad de clase de recurso.

  OSPF e IS-IS son ejemplos de protocolos de estado de vínculo.

• Protocolos de vectores de distancia: anuncie información de tabla de enrutamiento completa a los vecinos directamente conectados 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 protocolo de vector de distancia.

Como su nombre 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, en los que el IGP funciona para anunciar y aprender los prefijos de red (rutas) desde enrutadores vecinos para crear una tabla de rutas que, en última instancia, contenga entradas para todas las fuentes que anuncien la accesibilidad para 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 una conectividad completa entre los enrutadores que conforman un dominio de enrutamiento.

Además de anunciar la accesibilidad a la red interna, las IGP se utilizan a menudo para anunciar información de enrutamiento externa al dominio de enrutamiento de ese IGP a través de un proceso conocido como redistribución de rutas. La redistribución de ruta es el proceso de intercambio de información de enrutamiento entre distintos protocolos de enrutamiento para vincular varios dominios de enrutamiento cuando se desea conectividad intra-AS.

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.

Las IGP están diseñadas para gestionar la tarea de adquirir y distribuir información de topología de red con fines de ingeniería de tráfico. Aunque este modelo ha funcionado bien, las IGP tienen limitaciones inherentes de escalabilidad cuando se trata de distribuir bases de datos de gran tamaño. Las IGP pueden detectar automáticamente a los vecinos, con lo cual adquieren información de topología de red dentro de á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 un único área o AS, lo que limita las aplicaciones, como la ingeniería de tráfico de extremo a extremo, el beneficio de tener visibilidad externa para tomar mejores decisiones.

Para las redes conmutadas por etiquetas, como MPLS y MPLS generalizadas (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 estos casos, el problema de computación de rutas se vuelve complicado debido a la indisponibilidad de la información completa de enrutamiento en toda la red. Esto se debe a que los proveedores de servicios suelen optar por no filtrar información de enrutamiento más allá del área de enrutamiento o del AS por limitaciones de escalabilidad y preocupaciones de confidencialidad.

Necesidad de ampliar la distribución de estado de vínculo

Una de las limitaciones del IGP es su incapacidad para abarcar la distribución de estado de vínculo fuera de un único área o AS. Sin embargo, la expansión de la información del estado del vínculo adquirida por un IGP en varias áreas o AS tiene las siguientes necesidades:

• Computación de ruta de LSP: esta información se utiliza para calcular la ruta de los LSP de MPLS en varios dominios de enrutamiento, por ejemplo, un LSP de TE entre áreas.

• Entidades de computación de rutas externas: las entidades de computación de rutas externas, como la optimización de tráfico de capa de aplicación (ALTO) y los elementos de computación de ruta (PCE), realizan cálculos de rutas según 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 se distribuye normalmente por IGP dentro de la red.

  Sin embargo, dado que las entidades de computación de ruta externa no pueden extraer esta información de los IGP, realizan la supervisión de red para optimizar los servicios de red.

Uso del BGP como solución

• Descripción general
• Implementación

Implementación

En Junos OS, los IGP instalan la información de topología en una base de datos llamada 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 la información de topología del IGP en la base de datos de ingeniería de tráfico, utilice la set igp-topology instrucción de configuración en los [edit protocols isis traffic-engineering] niveles de jerarquía y [edit protocols ospf traffic-engineering] . El mecanismo para distribuir información de estado de vínculo mediante el BGP incluye el proceso de anunciar la base de datos de ingeniería de tráfico en BGP-TE (importación) e instalar entradas del 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 de IPv6 en la base de datos de ingeniería de tráfico (TED) además de direcciones IPv4. El BGP-LS distribuye esta información como rutas desde la base de datos de ingeniería de tráfico hasta la tabla de enrutamiento lsdist.0 mediante el uso de las políticas de importación de base de datos de ingeniería de tráfico. Estas rutas se anuncian a los pares del BGP-TE como información de accesibilidad de la capa de red (NLRI) con tipo de ID de enrutador IPv6, longitud y valor (TLV). Con la adición de información de 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 del BGP

BGP-LS NLRI y ID de confederación

A partir de junos OS versión 23.1R1, Junos OS permite que la información de la capa de acceso (NLRI) de estado de vínculo del BGP (BGP-LS) lleve 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 de sistema autónomo de miembro (número de AS) en TLV 517 como se define en el 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 que origina el NLRI BGP-LS (que se inyecta en la tabla de enrutamiento lsdist.0). En las versiones anteriores a Junos OS versión 23.1R1, el NLRI del BGP-LS 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 base 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 luego 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 fuga de entradas de la base de datos de ingeniería de tráfico en lsdist.0 se denomina importación de base de datos de ingeniería de tráfico, como se muestra en Figura 1.

Hay policías para controlar el proceso de importación de bases de datos de ingeniería de tráfico. De forma predeterminada, no se pierde ninguna entrada de la base de datos de ingeniería de tráfico en la lsdist.0 tabla.

A partir de Junos OS versión 17.4R1, la base de datos de ingeniería de tráfico instala la información de topología del protocolo de puerta de enlace interior (IGP) además de la información de topología RSVP-TE en la tabla de enrutamiento lsdist.0 como se ilustra en Figura 1. Antes de la versión 17.4R1 de Junos OS, la base de datos de ingeniería de tráfico solo exportó información de topología RSVP-TE. Ahora puede supervisar tanto el IGP como la información de topología de ingeniería de tráfico. El BGP-LS lee las entradas de IGP de lsdist.0 y anuncia estas entradas en los pares del BGP. Para importar información de topología de IGP en BGP-LS desde lsdist.0, utilice la set bgp-ls instrucción de configuración en el [edit protocols mpls traffic-engineering database import igp-topology] nivel de jerarquía.

Exportación de base de datos de ingeniería de tráfico

El BGP se puede configurar para exportar o anunciar rutas de la lsdist.0 tabla, sujeto a la 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, el BGP debe configurarse con la familia de direcciones BGP-TE y una política de exportación que seleccione rutas para su redistribución en BGP.

Luego, el BGP propaga estas rutas como cualquier otra NLRI. Los pares de BGP que tienen la familia BGP-TE configurada y negociada reciben BGP-TE NLRIC. El BGP almacena los NLRIs de BGP-TE recibidos en forma de rutas en la lsdist.0 tabla, que es la misma tabla que almacena rutas BGP-TE de origen local. Las rutas instaladas por lsdist.0 el BGP se distribuyen a otros pares como cualquier otra ruta. Por lo tanto, el procedimiento de selección de ruta estándar se aplica a las NLRIs BGP-TE recibidas de varios oradores.

Para lograr te entre dominios, las rutas se filtran en lsdist.0 la base de datos de ingeniería de tráfico a través de una política. Este proceso se denomina exportación de base de datos de ingeniería de tráfico, como se muestra en Figura 1.

Hay policías para controlar el proceso de exportación de bases de datos de ingeniería de tráfico. De forma predeterminada, no se pierde ninguna entrada de la lsdist.0 tabla en 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 del protocolo de enrutamiento por segmentos a la base de datos de ingeniería de tráfico (TED) y en el estado de vínculo del BGP como rutas. El estado de vínculo del BGP recopila la información relacionada con las políticas de TE, de modo que los controladores externos puedan realizar acciones como computación de rutas, optimización y visualización de red dentro y entre dominios.

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 RDS, como PCE y ALTO, la información anunciada del BGP-TE no puede filtrarse en la base de datos de ingeniería de tráfico de un enrutador. En estos casos, se utiliza un servidor externo que se compara con los enrutadores que utilizan BGP-TE para trasladar la información de topología al sistema sky/de orquestación que abarca la red. Estos servidores externos se pueden considerar consumidores de BGP-TE, donde reciben rutas BGP-TE, pero no las anuncian.

Asignar valores de credibilidad

Una vez que se instalan las entradas en la base de datos de ingeniería de tráfico, la información aprendida del BGP-TE está disponible para el cálculo de la ruta de CSPF. La base de datos de ingeniería de tráfico utiliza un esquema de preferencia de protocolo basado en valores de credibilidad. Se prefiere un protocolo con un mayor valor de credibilidad sobre un protocolo con un valor de credibilidad menor. El BGP-TE tiene la capacidad de anunciar información aprendida de varios 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 del BGP-TE que correspondan a más de un protocolo. El componente de exportación de base 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 que admite el 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 a 82

• ISIS nivel 2-83

• Estático— 84

• Directo: 85

Computación de ruta de credibilidad cruzada

Después de asignar valores de credibilidad, cada nivel de credibilidad se trata como un plano individual. El algoritmo Primero de ruta restringida comienza con la credibilidad asignada más alta a la más baja, encontrando una ruta dentro de ese nivel de credibilidad.

Con el BGP-TE, es esencial calcular las rutas entre los niveles de credibilidad para calcular las 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 OSPF instala las entradas del área 0 y las entradas de área 1 las instala el BGP-TE.

Para habilitar la computación de rutas en todos los niveles de credibilidad, incluya la cross-credibility-cspf instrucción en los edit protocols mplsniveles , [edit protocols mpls label-switched-path lsp-name]y [edit protocols rsvp] de jerarquía. En el [edit protocols rsvp] nivel jerárquico, la habilitación cross-credibility-cspf afecta a omitir los LSP y la expansión de saltos sueltos en tránsito.

cross-credibility-cspf La configuración permite la computación de rutas en todos los niveles de credibilidad mediante el algoritmo Restricted Shortest Path First, en el que la restricción no se realiza según la credibilidad, sino como una sola restricción que ignora los valores asignados de credibilidad.

NLRIs y TLV del BGP-TE

Al igual que otras rutas BGP, los NLRI BGP-TE también se pueden distribuir a través de un reflector de ruta que habla NLRI BGP-TE. Junos OS implementa la compatibilidad de reflexión de ruta para la familia BGP-TE.

La siguiente es una lista de NLRIs compatibles:

• Vínculo NLRI

• NLRI de nodo

• Prefijo IPv4 NLRI (recepción y propagación)

• Prefijo NLRI IPv6 (recepción y propagación)

• Política de TE NLRI

Nota:

Junos OS no proporciona soporte para la forma de diferenciador de ruta de los NRL Anteriores.

La siguiente es una lista de campos compatibles en nlris de vínculo y nodo:

• Protocol-ID: la NLRI se origina con los siguientes valores de protocolo:

  • ISIS-L1

  • ISIS-L2

  • OSPF

  • SPRING-TE

• Identificador: este valor se puede configurar. De forma predeterminada, el valor del identificador se establece en 0.

• Descriptor de nodo local o remoto: estas incluyen:

  • Sistema autónomo

  • Identificador BGP-LS: este valor se puede configurar. 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 el vínculo NLRI): esto incluye:

  • Identificadores locales/remotos de vínculo

  • Dirección de interfaz IPv4

  • Dirección de vecino IPv4

  • Dirección de vecino/interfaz IPv6: las direcciones de interfaz y de vecino 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.

La siguiente es una lista de LTL de atributo de LINK_STATE compatibles:

• Atributos de vínculo:

  • Grupo administrativo

  • Ancho de banda máximo del vínculo

  • Ancho de banda máximo reservable

  • Ancho de banda sin servicios

  • 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étricas

    • Tipo de protección de vínculo

    • Atributo de nombre de vínculo

• Atributos de nodo:

  • ID de enrutador IPv4

  • Bits de marca 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:

    • Topología múltiple

    • Propiedades de nodo específicas de OSPF

    • Propiedades de nodo opaco

    • Nombre de nodo

    • Identificador de área IS-IS

    • ID de enrutador IPv6

  • Atributos de prefijo: estos TLV se almacenan y propagan como cualquier otro TLV desconocido.

Funciones compatibles y no compatibles

Junos OS admite las siguientes funciones con distribución de estado de vínculo mediante BGP:

• Anuncio de la capacidad de reenvío garantizado de múltiples proveedores

• Transmisión y recepción de nodo y estado de vínculo BGP y BGP-TE NLRIs

• Enrutamiento activo sin interrupciones para BGP-TE NLRIs

• 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

• Soporte de diferenciador de ruta para NLRIs BGP-TE

• Identificadores de varias topologías

• Identificadores de varias instancias (excluyendo el ID de instancia predeterminado 0)

• Anuncio del TLV del área de enlace y nodo

• Anuncio de protocolos de señalización MPLS

• Importación de información de nodo y vínculo con direcciones superpuestas

Extensiones de estado de vínculo del BGP para el enrutamiento de paquetes de origen en redes (SPRING)

A partir de Junos OS versión 17.2R1, la familia de direcciones de estado de vínculo del BGP se extiende para distribuir la información de topología de enrutamiento de paquetes de origen en redes (SPRING) a controladores de redes definidas por software (SDN). El BGP normalmente aprende la información del estado del vínculo del IGP y la distribuye a los pares del BGP. Además del BGP, el controlador SDN puede obtener información del estado del vínculo directamente del IGP si el controlador forma parte de un dominio IGP. Sin embargo, la distribución de estado de vínculo del BGP proporciona un mecanismo escalable para exportar la información de topología. Las extensiones de estado de vínculo del BGP para SPRING se admiten en redes entre dominios.

• Enrutamiento de paquetes fuente en redes (SPRING)
• Flujo de datos spring del estado de vínculo del BGP
• Atributos de estado de vínculo y TLV del BGP compatibles, y funciones no compatibles para el estado de vínculo del BGP con SPRING

Flujo de datos spring del estado de vínculo del BGP

Figura 2 muestra el flujo de datos de los datos spring del estado del vínculo del BGP que IS-IS envía a la base de datos de ingeniería de tráfico.

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

• IGP envía los atributos SPRING a la base de datos de ingeniería de tráfico.

• Las capacidades de SPRING y la información de algoritmo se trasladan como atributos de nodo a la base de datos de ingeniería de tráfico.

• La información de SID y LAN adyacentes se llevan como atributos de vínculo.

• La información del SID del prefijo o del nodo-SID se lleva como atributos de prefijo.

• Un nuevo conjunto o un cambio de atributos existentes activan actualizaciones del 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 del BGP, incluidos los descriptores de vínculo, nodo y prefijo, se derivan de las 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 política.

• La política predeterminada del BGP es exportar rutas, que solo se conocen para BGP. Configure una política de exportación para rutas que no son 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.

Verificar el nodo NLRI aprendido a través del BGP con OSPF como IGP

La siguiente es una salida de muestra para comprobar que el nodo NLRI aprendió a través del BGP con OSPF como IGP:

Verificar el prefijo NLRI aprendido a través del BGP con OSPF como IGP

La siguiente es una salida de muestra para verificar el prefijo NLRI aprendido a través del BGP con OSPF como IGP:

Beneficios de los aviones de transporte con clase BGP

• División de red: las capas de servicio y transporte se desacoplan entre sí, sentando las bases para la segmentación y la virtualización de red con la división de extremo a extremo en varios dominios, lo que reduce significativamente el CAPEX.

• Interoperabilidad entre dominios: extiende la implementación de clase de transporte a todos los dominios cooperativos, de modo que los diferentes protocolos de señalización de transporte en cada dominio interoperan. Reconcilia cualquier diferencia entre los espacios de nombres de comunidad extendidos que pueden estar en uso en cada dominio.

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

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

Terminología de los planos de transporte con clase BGP

En esta sección, se proporciona un resumen de los términos utilizados comúnmente para comprender el plano de transporte de clase del BGP.

• Nodo de servicio: dispositivos de borde 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 (LU) del BGP.

• BGP-VPN-VPN creadas con mecanismos RFC4364.

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

• Distinguidor de ruta (RD): identificador que se utiliza para distinguir a qué VPN o servicio LAN privada virtual (VPLS) pertenece una ruta. Cada instancia de enrutamiento debe tener un distinguidor de ruta único asociado con ella.

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

  Asignan las rutas a las diferentes RB de transporte en el sistema según la comunidad de mapeo.

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

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

• Túnel de transporte: un 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: un grupo de túneles de transporte que ofrecen el mismo tipo de servicio.

• RT de la clase de transporte: un nuevo formato de destino de ruta utilizado para identificar una clase de transporte específica.

  Se utiliza un nuevo formato de destino de ruta 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 un RIB de transporte asociado que mantiene sus rutas de túnel.

• Instancia de enrutamiento RTI-A de transporte; contenedor de transporte RIB, y el distinguidor de ruta y destino de ruta de la clase de transporte asociado.

• Plano de transporte: conjunto de RT de transporte que importan la misma clase de transporte RT. Estas, a su vez, se unen para abarcar los límites de los dominios de túnel mediante un mecanismo similar a la opción b del interAS para intercambiar etiquetas en 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 sobre una clase de transporte.

Descripción de los planos de transporte clase BGP

Puede usar planos de transporte con clases del BGP para configurar clases de transporte para clasificar un conjunto de túneles de transporte en una red de intraAS según 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 clases del BGP pueden extender estos túneles a redes entre dominios que abarcan varios dominios (AS o áreas IGP) a la vez que conservan la clase de transporte. Para ello, debe configurar la familia BGP de transporte de transporte con clase BGP entre los nodos de borde y de servicio.

En las implementaciones tanto de interAS como de intraAS, puede haber muchos túneles de transporte (LSP MPLS, algoritmo flexible IS-IS, SR-TE) creados a partir de los nodos de borde y servicio. Los LSP se pueden señalizar mediante diferentes protocolos de señalización en distintos dominios y configurarse con diferentes características de ingeniería de tráfico (clase o color). El punto de conexión del túnel de transporte también actúa como el punto de conexión 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 usar planos de transporte de clase BGP para resove servicios a través de LSP con determinadas características de ingeniería de tráfico, ya sea dentro de un solo dominio o en varios dominios.

Los planos de transporte por clase BGP reutilizan la tecnología BGP-VPN, lo que mantiene los dominios de tunelización libremente acoplados y coordinados.

• La información de accesibilidad de la capa de red (NLRI) es RD:TunnelEndpoint usado para ocultar rutas.
• El destino de ruta indica la clase de transporte de los LSP y fuga rutas al 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 un destino de ruta VPN y recopila los LSP de la misma clase de transporte en la tabla de enrutamiento transport-rib transport-class.inet.3.

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

• Cuando cruce el límite del vínculo del interAS, debe seguir los procedimientos option-b para unir los túneles de transporte en estos dominios adyacentes.

  De manera similar, al cruzar regiones de intraAS, debe seguir los procedimientos de opción b para unir los túneles de transporte en los distintos dominios de TE.

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

• Puede resolver rutas de servicio y rutas de transporte de clase BGP a través de estas clases de transporte, mediante la creación de la comunidad de mapeo en ellas.

La familia de transporte con clases BGP corre junto con la familia de capas de transporte BGP-LU. En una red MPLS sin problemas que ejecuta BGP-LU, cumplir con los estrictos requisitos de SLA de la 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 clases del BGP ofrecen medios operacionalmente fáciles y escalables para anunciar varias rutas para circuito cerrado remoto junto con la información de clase de transporte en la arquitectura MPLS sin problemas. En las rutas de la familia de tranportes con clases del BGP, se representan diferentes rutas de SLA mediante la comunidad extendida de objetivo de ruta de transporte, que lleva el color de la clase de transporte. Los enrutadores BGP receptores utilizan este objetivo de ruta de transporte para asociar la ruta de transporte con clase del BGP con la clase de transporte adecuada. Al volver a anunciar las rutas de transporte de clase del BGP, MPLS intercambia rutas, interconecta los túneles de intraAS de la misma clase de transporte, formando así un túnel de extremo a extremo que conserva la clase de transporte.

Implementación del intraAS de los planos de transporte con clase del BGP

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

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

Para clasificar los túneles de transporte en clase de transporte BGP en una configuración de 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 color 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 de plano de transporte de clase del BGP del Intra-AS:

• El transporte por clase del BGP crea RB de transporte predefinidos 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 de intraAS se completan en las RÍ de transporte mediante el protocolo de tunelización cuando se asocia con una clase de transporte.

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

• El nodo de servicio (PEs de entrada) coincide con la comunidad de color extendida (color:0:100 y color:0:200) de la ruta de servicio con la comunidad de asignación en RI de resolución predefinida y resuelve el salto siguiente del protocolo (PNH) en las RB de transporte correspondientes (ya sea junos-rti-tc-<100>.inet.3, o junos-rti-tc-<200>.inet.3).
• Las rutas del BGP se vinculan a un esquema de resolución mediante el transporte de la comunidad de mapeo unido.
• 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 utilizan Transport-Target:0:<val> como comunidad de mapeo.

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

Implementación del interAS de los planos de transporte de clase del BGP

En una red de interAS, el BGP-LU se convierte en red de transporte de 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 de 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 (PEs de entrada, ABR y ASBR).

   Configuración de ejemplo:

   Para LSP de RSVP

   Para algoritmos flxibles IS-IS

3. Habilite una nueva familia para el transporte de clases BGP (transporte de inet) y BGP-LU (inet labeled-unicast) en la red.

   Configuración de ejemplo:

4. Anuncie rutas de servicio desde el dispositivo PE de salida con una comunidad de colores extendida adecuada.

   Configuración de ejemplo:

Funcionalidad de plano de transporte de clase del BGP del interAS:

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

2. Las rutas de transporte de intraAS se completan en las RÍ 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 gold y bronze se instalan en las RB de transporte junos-rti-tc-<100>.inet.3 y junos-rti-tc-<200>.inet.3, respectivamente.

3. Los planos de transporte con clases del BGP usan el distinguidor de ruta y el destino de ruta únicos cuando copian las rutas de túnel de transporte de cada RIB de transporte a la tabla de enrutamiento bgp.transport.3.
4. Los nodos de borde anuncian rutas de la tabla de enrutamiento bgp.transport.3 a sus pares en otros dominios si el transporte de inet de familia se negocia en la sesión del 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 la ruta de transporte a las RB de transporte adecuadas.
6. El nodo de servicio hace coincidir la comunidad de color de la ruta de servicio con una comunidad de mapeo en los esquemas de resolución y resuelve el PNH en el RIB de transporte correspondiente (ya sea junos-rti-tc-<100>.inet.3, o junos-rti-tc-<200>.inet.3).
7. Los nodos de borde usan esquemas de resolución predefinidos para la resolución PNH de la ruta de transporte.
8. Ambos esquemas de resolución, predefinidos o definidos por el usuario, admiten la resolución PNH de ruta de servicio. La predefinida usa inet.3 como reserva, y el esquema de resolución definido por el usuario permite usar una lista de RI de transporte en el orden especificado al resolver PNH.
9. Si la PNH de la ruta de servicio no se puede resolver mediante LAS RIB enumeradas en el esquema de resolución definido por el usuario, la ruta se descarta.

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

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

• Resuelve las preocupaciones de escala que pueden surgir en el futuro a medida que la red crece.
• Proporciona interconectividad para dominios que utilizan diferentes tecnologías.
• Desvincula los servicios y las capas de transporte, lo que da como resultado una red completamente distribuida.
• Ofrece administración independiente del ancho de banda a través de un controlador de ingeniería de tráfico intradominio para SR-TE.

Las grandes redes que crecen y evolucionan continuamente requieren una arquitectura de enrutamiento por segmentos sin problemas. A partir de Junos OS versión 21.2,R1, somos compatibles con BGP-CT con transporte subyacente como túneles DE SR-TE coloreados. El BGP-CT puede resolver rutas de servicio mediante las RI 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. Ahora, los servicios pueden usar los túneles de color sr-TE subyacentes, como los túneles de color estático, SR-TE BGP, rpd programable y PCEP de color. El BGP-CT utiliza la accesibilidad del salto siguiente para resolver rutas de servicio a través de la clase de transporte deseada.

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

Mensajes de PathErr

Los mensajes PathErr informan de una amplia variedad de problemas mediante diferentes códigos y números de 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.

Cuando se configura 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 real del vínculo es menor que el 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 sobreestimada.

  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:

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

  • Fallas en el control de políticas(código 2)

  • Servicio predeterminado: código 12

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

  Estos tipos de mensajes PathErr generalmente son pertinentes para el LSP especificado. La falla de este LSP no implica necesariamente que otros LSP también podrían fallar. Estos errores pueden indicar problemas de unidad de transferencia máxima (MTU), preferencia del servicio (iniciado manualmente por el operador o por otro LSP con una prioridad más alta), que un vínculo del siguiente salto está inactivo, que un vecino del siguiente salto está inactivo o rechazo del servicio debido a consideraciones de política. Es mejor enrutar este LSP en particular lejos del vínculo.

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 PathErr lleva suficiente información para identificar la sesión RSVP que activó 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 vínculos que debe atravesar la sesión. Junto con la información del nodo de origen, el vínculo se puede identificar de manera ú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 mediante la supervisión de 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 utilizan para actualizar la información de ancho de banda de la base de datos de ingeniería de tráfico, lo que reduce las inconsistencias entre la base de datos de ingeniería de tráfico y la red.

Para configurar cuánto tiempo MPLS debe recordar los mensajes de RSVP PathErr y considerarlos 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 0 deshabilita la supervisión de los mensajes de PathErr.