Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

MPLS e ingeniería de tráfico

La ingeniería de tráfico le permite controlar la ruta que siguen los paquetes de datos, sin pasar por alto el modelo de enrutamiento estándar, que utiliza tablas de enrutamiento. La ingeniería de tráfico mueve flujos de vínculos congestionados a vínculos alternativos que no se seleccionarían mediante la ruta más corta calculada automáticamente basada en destinos. Con la ingeniería de tráfico, puede:

  • Haga un uso más eficiente de fibras costosas de largo recorrido.

  • Controle cómo se reenrutiza el tráfico ante una o varias fallas.

  • Clasifique el tráfico crítico y regular por ruta.

El núcleo del diseño de ingeniería de tráfico se basa en la construcción de rutas conmutadas por etiquetas (LSP) entre enrutadores. Un LSP está orientado a la conexión, como un circuito virtual en Frame Relay o ATM. Los LSP no son confiables: Los paquetes que ingresan a un LSP no tienen garantías de entrega, aunque es posible un trato preferencial. Los LSP también son similares a los túneles unidireccionales en que los paquetes que ingresan a una ruta se encapsulan en un sobre y se conmutan a través de toda la ruta sin que los nodos intermedios los toquen. Los LSP proporcionan un control detallado sobre cómo se reenvían los paquetes en una red. Para proporcionar confiabilidad, un LSP puede usar un conjunto de rutas primarias y secundarias.

Los LSP se pueden configurar solo para tráfico BGP (tráfico cuyo destino está fuera de un sistema autónomo [AS]). En este caso, el tráfico dentro del AS no se ve afectado por la presencia de LSP. Los LSP también se pueden configurar para el tráfico del BGP y del protocolo de puerta de enlace interior (IGP); por lo tanto, tanto el tráfico intraAS como el interAS se ven afectados por los LSP.

Descripción general de la ingeniería de tráfico y protocolos de señalización MPLS

La ingeniería de tráfico facilita operaciones de red eficientes y confiables, a la vez que optimiza los recursos de red y el rendimiento del tráfico. La ingeniería de tráfico ofrece la capacidad de alejar el flujo de tráfico de la ruta más corta seleccionada por el protocolo de puerta de enlace interior (IGP) a una ruta física potencialmente menos congestionada a través de una red. Para admitir la ingeniería de tráfico, además del enrutamiento de origen, la red debe hacer lo siguiente:

  • Calcule una ruta en el origen teniendo en cuenta todas las restricciones, como el ancho de banda y los requisitos administrativos.

  • Distribuya la información sobre la topología de red y los atributos de vínculo en toda la red una vez que se calcula la ruta.

  • Reserve recursos de red y modifique atributos de vínculo.

Cuando el tráfico de tránsito se enruta a través de una red IP, la MPLS se utiliza a menudo para diseñar su paso. Aunque la ruta exacta a través de la red de tránsito es de poca importancia para el remitente o el receptor del tráfico, los administradores de red a menudo quieren enrutar el tráfico de manera más eficiente entre ciertos pares de direcciones de origen y destino. Al agregar una etiqueta corta con instrucciones de enrutamiento específicas a cada paquete, MPLS conmuta paquetes de enrutador a enrutador a través de la red en lugar de reenviar paquetes según búsquedas de salto siguiente. Las rutas resultantes se denominan rutas conmutadas por etiquetas (LSP). Los LSP controlan el paso del tráfico a través de la red y aceleran el reenvío de tráfico.

Puede crear LSP manualmente o mediante el uso de protocolos de señalización. Los protocolos de señalización se utilizan dentro de un entorno MPLS para establecer LSP para el tráfico en una red de tránsito. Junos OS admite dos protocolos de señalización: LDP y el protocolo de reserva de recursos (RSVP).

La ingeniería de tráfico MPLS utiliza los siguientes componentes:

  • LSP MPLS para el reenvío de paquetes

  • Extensiones IGP para distribuir información sobre la topología de red y los atributos de vínculo

  • Primero de ruta más corta restringida (CSPF) para el cálculo de rutas y la selección de rutas

  • Extensiones de RSVP para establecer el estado de reenvío a lo largo de la ruta y para reservar recursos a lo largo de la ruta

Junos OS también admite la ingeniería de tráfico en diferentes regiones de OSPF.

Capacidades de ingeniería de tráfico

La tarea de asignar flujos de tráfico a una topología física existente se denomina ingeniería de tráfico. La ingeniería de tráfico ofrece la capacidad de alejar el flujo de tráfico de la ruta más corta seleccionada por el protocolo de puerta de enlace interior (IGP) y a una ruta física potencialmente menos congestionada a través de una red.

La ingeniería de tráfico ofrece las capacidades para hacer lo siguiente:

  • Enrutar rutas principales alrededor de cuellos de botella conocidos o puntos de congestión en la red.

  • Proporcione un control preciso sobre cómo se reenrutiza el tráfico cuando la ruta principal se enfrenta a fallas únicas o múltiples.

  • Ofrezca un uso más eficiente del ancho de banda agregado disponible y de la fibra de largo recorrido garantizando que los subconjuntos de la red no se sobreutilicen, mientras que otros subconjuntos de la red a lo largo de las rutas alternativas potenciales están infrautilizados.

  • Maximice la eficiencia operativa.

  • Mejore las características de rendimiento orientadas al tráfico de la red minimizando la pérdida de paquetes, minimizando los períodos prolongados de congestión y maximizando la transferencia de datos.

  • Mejore las características de rendimiento estadísticamente vinculadas de la red (como la relación de pérdidas, la variación de retraso y el retraso de transferencia) necesarias para admitir una Internet de varios servicios.

Componentes de ingeniería de tráfico

En el sistema operativo junos® (OS), la ingeniería de tráfico se implementa con MPLS y RSVP. La ingeniería de tráfico se compone de cuatro componentes funcionales:

Configuración de ingeniería de tráfico para LSP

Cuando configura un LSP, se instala una ruta de host (una máscara de 32 bits) en el enrutador de entrada hacia el enrutador de salida; la dirección de la ruta de host es la dirección de destino del LSP. La bgp opción de la traffic engineering instrucción en el [edit protocols mpls] nivel de jerarquía está habilitada de forma predeterminada (también puede configurar explícitamente la opción), lo que permite que solo el bgp BGP utilice LSP en sus cálculos de ruta. Las otras traffic-engineering opciones de instrucción le permiten modificar este comportamiento en la instancia de enrutamiento maestro. Esta funcionalidad no está disponible para instancias de enrutamiento específicas. Además, solo puede habilitar una de las opciones de instrucción traffic-engineering (bgp, bgp-igp, bgp-igp-both-ribs, o mpls-forwarding) a la vez.

Nota:

Habilitar o deshabilitar cualquiera de las opciones de instrucción traffic-engineering hace que todas las rutas MPLS se eliminen y, luego, se vuelvan a insertar en las tablas de enrutamiento.

Puede configurar OSPF e ingeniería de tráfico para anunciar la métrica LSP en anuncios de estado de vínculo (LSA) resumidos, tal como se describe en la sección Publicidad de la métrica LSP en resumen LSA.

En las siguientes secciones se describe cómo configurar la ingeniería de tráfico para LSP:

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

Puede configurar el BGP y los IGP para que usen LSP para reenviar 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 que funcionen correctamente. En el caso de las VPN, configure la bgp-igp-both-ribs opción de la traffic-engineering instrucción para hacer que el BGP y los IGP usen LSP para reenviar el 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 usa la bgp-igp-both-ribs instrucción, las rutas de la tabla inet.3 se copian en la tabla inet.0. Las rutas copiadas son señaladas 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 menor preferencia se elijan 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 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 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 mpls-forwarding opción para la traffic-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 el reenvío de próximos saltos.

Cuando active la mpls-forwarding opción, las rutas cuyo estado es ForwardingOnly preferido para 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 utilizar LSP para el 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]

Cuando configure la mpls-forwarding opción, las 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ñaladas por LDP y RSVP para el reenvío, y mantener las rutas bgp e IGP activas con fines de enrutamiento, de modo que las políticas de enrutamiento puedan actuar sobre ellas.

Por ejemplo, suponga que un enrutador está ejecutando BGP y que tiene una ruta BGP de 10.10.10.1/32 que debe enviar a otro altavoz BGP. Si usa 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 an anuncio 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 aún se utiliza 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 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 MPLS y OSPF para anunciar la métrica LSP en LSA de 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 OSPF, consulte la Biblioteca de protocolos de enrutamiento de Junos OS para dispositivos de enrutamiento.

Habilitación de la ingeniería de tráfico de Interarea

Junos OS puede indicar un LSP contiguo diseñado para el tráfico en varias áreas de OSPF. La señalización LSP debe realizarse mediante el anidamiento o la señalización contigua, como se describe en rfc 4206, jerarquía de rutas conmutadas por etiquetas (LSP) con ingeniería de tráfico (TE) de conmutación de etiquetas multi protocolizada generalizada (GMPLS). Sin embargo, la compatibilidad con señales contiguas se limita a la señalización básica. La reoptimización no se admite con la señalización contigua.

A continuación, se describen algunas de las funciones de ingeniería de tráfico interarea:

  • La ingeniería de tráfico de Interarea se puede habilitar cuando los enrutadores de borde de área de salto suelto (AFL) se configuran en el enrutador de entrada mediante CSPF para el cálculo del objeto de ruta explícito (ERO) dentro de un área OSPF. La expansión de ERO se completa con los ADR.

  • La ingeniería de tráfico de Interarea se puede habilitar cuando se habilita CSPF, pero sin los ABR especificados en la configuración LSP en el enrutador de entrada (los ABR se pueden designar automáticamente).

  • La ingeniería de tráfico de servicios diferenciados (DiffServ) se admite siempre y cuando las asignaciones de tipos de clase sean uniformes en varias áreas.

Para habilitar la ingeniería de tráfico interarea, incluya la expand-loose-hop instrucción en la configuración de cada enrutador de tránsito LSP:

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

  • [edit protocols mpls]

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

Habilitación de ingeniería de tráfico interAS para LSP

Generalmente, la ingeniería de tráfico es posible para LSP que cumplen las siguientes condiciones:

  • Ambos extremos del LSP se encuentran en el mismo área OSPF o en el mismo nivel IS-IS.

  • Los dos extremos del LSP se encuentran en diferentes áreas OSPF dentro del mismo sistema autónomo (AS). Los LSP que terminan en distintos niveles IS-IS no se admiten.

  • Los dos extremos de un LSP de ruta explícita se encuentran en diferentes AS de OSPF y los enrutadores de borde del sistema autónomo (ASBR) se configuran estáticamente como los saltos sueltos admitidos en la LSP de ruta explícita. Para obtener más información, consulte Configurar LSP de ruta explícita.

Sin asbrs definidos estáticamente en LSP, la ingeniería de tráfico no es posible entre un dominio de enrutamiento, o AS, y otro. Sin embargo, cuando los AS están bajo el control de un solo proveedor de servicios, en algunos casos es posible que los LSP diseñados para el tráfico abarquen los AS Y descubran dinámicamente los ASB de OSPF que los vinculan (IS-IS no se admite con esta función).

Los LSP diseñados para el tráfico entre AS son posibles siempre y cuando se cumplan ciertos requisitos de red, no se apliquen ninguna de las condiciones de limitación y el modo pasivo OSPF esté configurado con EBGP. Los detalles se proporcionan en las siguientes secciones:

Requisitos de ingeniería de tráfico entre AS

El establecimiento y el 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 control de un único proveedor de servicios.

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

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

  • OSPF distribuye la información de enrutamiento de EBGP y hay una malla completa de IBGP en cada AS.

  • Los LSP de tránsito no se configuran en los vínculos del interAS, pero se configuran entre los ASB de punto 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 en OSPF. La propia dirección del vínculo remoto, no el circuito cerrado o cualquier 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 OSPF, consulte Configuración del modo de TE pasivo 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 ingeniería de tráfico entre AS

Solo la señalización jerárquica O anidada de LSP se admite para los LSP diseñados para el tráfico del 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 imposible el tráfico interAS diseñado LSP, incluso si se cumplen los requisitos anteriores.

  • No se admite el uso de BGP multihop.

  • No se admite el uso de agentes de policía 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 o 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 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 entre AS:

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

  • No se admite la espera secundaria.

  • No se admite la reoptimización.

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

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

  • No se admite un reinicio correcto.

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

Configuración del modo de TE pasivo OSPF

Normalmente, los protocolos de enrutamiento interiores, como OSPF, no se ejecutan en vínculos entre AS. Sin embargo, para que la ingeniería de tráfico entre AS funcione correctamente, la información sobre el vínculo entre AS, en particular, la dirección de la interfaz remota, debe estar disponible dentro del AS. Esta información normalmente no se incluye en los mensajes de accesibilidad de EBGP ni en 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 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 interAS, incluya la passive instrucción para el vínculo en el [edit protocols ospf area area-id interface interface-name] nivel de jerarquía:

El OSPF debe estar configurado correctamente en el enrutador. En el siguiente ejemplo, se configura el vínculo so-1/1/0 entre AS 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.

Componente de reenvío de paquetes

El componente de reenvío de paquetes de la arquitectura de ingeniería de tráfico de Junos es MPLS, que es responsable de dirigir un flujo de paquetes IP a lo largo de una ruta predeterminada a través de una red. Esta ruta se denomina ruta de conmutación de etiquetas (LSP). Los LSP son simples; es decir, el tráfico fluye en una dirección desde el enrutador de cabecera (entrada) hasta un enrutador de extremo final (salida). El tráfico dúplex requiere dos LSP: un LSP para transportar tráfico en cada dirección. Una LSP se crea mediante la concatenación de uno o más saltos conmutados por etiquetas, lo que permite reenviar un paquete de un enrutador a otro a través del dominio MPLS.

Cuando un enrutador de entrada recibe un paquete IP, agrega un encabezado MPLS al paquete y lo reenvía al siguiente enrutador del LSP. Cada enrutador reenvía el paquete etiquetado a lo largo del LSP hasta que llega al extremo final del LSP, el enrutador de salida. En este punto, se elimina el encabezado MPLS y el paquete se reenvía según la información de capa 3, como la dirección de destino IP. El valor de este esquema es que la ruta física del LSP no se limita a lo que el IGP elegiría como la ruta más corta para llegar a la dirección IP de destino.

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 del 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 20 bits y longitud fija. Cuando un paquete que contiene una etiqueta llega a un enrutador, el enrutador examina la etiqueta y la copia como un índice en 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 un paquete atraviesa una red troncal MPLS

Esta sección describe cómo se procesa un paquete IP mientras atraviesa una red troncal MPLS.

En el borde de entrada de la red troncal MPLS, el enrutador de entrada examina el encabezado IP. 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. La MPLS ofrece un alto grado de flexibilidad en la forma en que se puede asignar un paquete IP 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 utiliza la etiqueta para tomar la decisión de reenvío. La decisión de reenvío 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 etiqueta 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 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 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 enrutador. 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 opacos de estado de vínculo (LSA). El algoritmo de inundación estándar utilizado por los IGP de estado de vínculo garantiza que los atributos de vínculo se distribuyen 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 de 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 atributos de vínculo de red e 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 toda la topología física. Se mantiene una base de datos independiente para que el cálculo de ingeniería de tráfico posterior sea independiente de la IGP y la base de datos de estado de vínculo de la IGP. Mientras tanto, el IGP continúa su operación sin modificaciones, realizando el cálculo tradicional de ruta más corta según 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 el IGP inunda los atributos de vínculo de red y la información de topología y se coloca 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 de 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 en el 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 suelta. La compatibilidad con rutas explícitas estrictas y sueltas permite que el proceso de selección de rutas tenga una amplia libertad siempre que sea posible, pero 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. El CSPF es un algoritmo que prioriza la ruta más corta y que se ha modificado para tener en cuenta restricciones específicas cuando se calcula la ruta más corta de la red. La entrada en el algoritmo CSPF incluye:

  • Información de estado de vínculo de topología aprendida del IGP y conservada 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 de vínculo reservado, el ancho de banda del vínculo disponible y el color del vínculo) que son llevados por extensiones IGP y almacenados en la base de datos de ingeniería de tráfico

  • Atributos administrativos necesarios para admitir 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

Como 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 los 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. 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 pueda funcionar hasta que el componente de señalización lo establezca realmente. El componente de señalización, que es responsable de establecer el estado de LSP y distribuir etiquetas, se basa en varias extensiones a RSVP:

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

  • El objeto Solicitud de etiqueta 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.

Planificación y análisis de rutas sin conexión

A pesar de la reducción del esfuerzo de administración resultante del cálculo de rutas en línea, todavía se necesita una herramienta de planificación y análisis sin conexión para optimizar la ingeniería de tráfico a nivel mundial. El cálculo en línea tiene en cuenta las limitaciones de recursos y calcula un LSP a la vez. El desafío con este enfoque es que no es determinista. El orden en que se calculan los LSP desempeña un papel fundamental a la hora de determinar la ruta física de cada LSP en toda la red. Los LSP que se calculan al principio del proceso tienen más recursos disponibles que los LSP calculados más adelante en el proceso, ya que los LSP calculados anteriormente consumen recursos de red. Si se cambia el orden en que se calculan los LSP, el conjunto resultante de rutas físicas para los LSP también puede cambiar.

Una herramienta de planificación y análisis sin conexión examina simultáneamente las restricciones de recursos de cada vínculo y los requisitos de cada LSP. Aunque el enfoque sin conexión puede tardar varias horas en completarse, realiza cálculos globales, compara los resultados de cada cálculo y, luego, selecciona la mejor solución para la red en su conjunto. El resultado del cálculo sin conexión es un conjunto de LSP que optimiza la utilización de los recursos de red. Una vez completado el cálculo sin conexión, los LSP se pueden establecer en cualquier orden, ya que cada uno de ellos se instala de acuerdo con las reglas de la solución optimizada globalmente.

Cálculo y configuración flexibles de LSP

La ingeniería de tráfico implica asignar el flujo de tráfico a una topología física. Puede determinar las rutas en línea mediante enrutamiento basado en restricciones. Independientemente de cómo se calcule la ruta física, el estado de reenvío se instala en toda la red mediante RSVP.

Junos OS admite las siguientes maneras de enrutar y configurar un LSP:

  • Puede calcular la ruta completa para el LSP sin conexión y configurar individualmente cada enrutador en el LSP con el estado de reenvío estático necesario. Esto es análogo a la forma en que algunos proveedores de servicios de Internet (ISP) configuran sus núcleos ip-over-ATM.

  • Puede calcular la ruta completa para el LSP sin conexión y configurar estáticamente el enrutador de entrada con la ruta completa. A continuación, el enrutador de entrada utiliza RSVP como protocolo de señalización dinámica para instalar un estado de reenvío en cada enrutador a lo largo del LSP.

  • Puede confiar en el enrutamiento basado en restricciones para realizar cálculos LSP en línea dinámicos. Configure las restricciones para cada LSP; entonces la propia red determina la ruta que mejor cumple con esas limitaciones. Específicamente, el enrutador de entrada calcula todo el LSP según las restricciones e inicia la señalización en toda la red.

  • Puede calcular una ruta parcial para un LSP sin conexión y configurar estáticamente el enrutador de entrada con un subconjunto de los enrutadores en la ruta; entonces puede permitir el cálculo en línea para determinar la ruta completa.

    Por ejemplo, considere una topología que incluye dos rutas de este a oeste en los Estados Unidos: uno en el norte a través de Chicago y otro en el sur a través de Dallas. Si desea establecer un LSP entre un enrutador en Nueva York y uno en San Francisco, puede configurar la ruta parcial para que el LSP incluya un solo salto de enrutamiento suelto de un enrutador en Dallas. El resultado es un LSP enrutado a lo largo de la ruta sur. El enrutador de entrada utiliza CSPF para calcular la ruta completa y RSVP para instalar el estado de reenvío a lo largo del LSP.

  • Puede configurar el enrutador de entrada sin limitaciones. En este caso, el enrutamiento de ruta más corta normal IGP se utiliza para determinar la ruta del LSP. Esta configuración no proporciona ningún valor en términos de ingeniería de tráfico. Sin embargo, es fácil y puede ser útil en situaciones en las que se necesitan servicios como redes privadas virtuales (VPN).

En todos estos casos, puede especificar cualquier número de LSP como copias de seguridad para el LSP principal, lo que le permite combinar más de un enfoque de configuración. Por ejemplo, puede calcular explícitamente la ruta principal sin conexión, establecer la ruta secundaria para que esté basada en restricciones y que la ruta terciaria no esté restringida. Si falla un circuito en el que se enruta el LSP principal, el enrutador de entrada notará la interrupción de las notificaciones de error recibidas de un enrutador descendente o por la expiración de la información de estado de software RSVP. Luego, el enrutador reenvía dinámicamente el tráfico a un LSP en espera activa o llama a RSVP para crear un estado de reenvío para un nuevo LSP de respaldo.

Descripción general de los planos de transporte con clase bgp

Ventajas de los planes de transporte con clase bgp

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

  • Interoperabilidad entre dominios: extiende el despliegue de la clase de transporte entre dominios cooperativos para que interoperan los distintos protocolos de señalización de transporte de cada dominio. Concilia cualquier diferencia entre espacios de nombres de comunidad extendidos que puedan estar en uso en cada dominio.
  • Resolución de color con respaldo: permite la resolución sobre túneles de colores (RSVP, algoritmo flexible IS-IS) con opciones flexibles de reserva en túneles de mejor esfuerzo o cualquier otro túnel de color.

  • Calidad del servicio: personaliza y optimiza la red para lograr los requisitos de SLA de extremo a extremo.
  • El aprovechamiento de las implementaciones existentes admite protocolos de tunelización bien implementados, como RSVP, junto con nuevos protocolos, como el algoritmo flexible IS-IS, preservando el ROI y reduciendo el OPEX.

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 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 con etiqueta BGP (LU).

  • BGP-VPN-VPN construidas con mecanismos RFC4364.

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

  • Diferenciador de rutas (RD): identificador que se usa 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 a ella.

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

    Asignan las rutas a los diferentes RIB de transporte del sistema según la comunidad de mapeo.

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

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

  • Túnel de transporte: un túnel sobre el que 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.

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

    Un nuevo formato de destino de ruta que se usa para identificar una clase de transporte específica.
  • RIB de transporte: en el nodo de servicio y en el nodo de borde, una clase de transporte tiene un RIB de transporte asociado que contiene sus rutas de túnel.

  • RTI de transporte: una instancia de enrutamiento; contenedor de RIB de transporte, y clase de transporte asociada Destino de ruta y distinguidor de ruta.

  • Plano de transporte: conjunto de RTis de transporte que importan la misma clase de transporte RT. A su vez, estas se unen para abarcar los límites del dominio 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 a comunidad en una ruta de servicio que se asigna para resolver a través de 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 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 clase BGP pueden extender estos túneles a redes entre dominios que abarcan varios dominios (AS o áreas IGP) y conservar la clase de transporte. Para ello, debe configurar la familia bgp de capa de transporte de trasporte con clase BGP entre el borde y los nodos de servicio.

En las implementaciones tanto del interAS como del intraAS, puede haber muchos túneles de transporte (LSP MPLS, algoritmo flexible IS-IS, SR-TE) creados a partir del servicio y los nodos de borde. Los LSP se pueden señalizar utilizando diferentes protocolos de señalización en diferentes dominios, y se pueden configurar 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 con clase BGP para volver a crear servicios a través de LSP con ciertas características de ingeniería de tráfico, ya sea dentro de un solo dominio o en varios dominios.

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

  • La información de accesibilidad de la capa de red (NLRI) es RD:TunnelEndpoint que se usa para ocultar rutas.
  • El destino de ruta indica la clase de transporte de los LSP y pierde 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 destino de ruta VPN y recopila los LSP de la misma clase de transporte en la tabla de enrutamiento transport-class.inet.3.
  • Las rutas en esta instancia de enrutamiento se anuncian en el plano de transporte con clase BGP (transporte de inet) AFI-SAFI siguientes procedimientos similares a RFC-4364.

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

    Del mismo modo, cuando se cruzan regiones del 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 con clase BGP a través de estas clases de transporte, carrrying la comunidad de asignación en ellas.

La familia de transporte con clase BGP se ejecuta a lo largo del lado de la familia de capa de transporte BGP-LU. En una red MPLS sin problemas que ejecuta BGP-LU, cumplir con los estrictos requisitos de SLA del 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 a través de los límites del dominio. Los planos de transporte con clase BGP proporcionan medios operativos fáciles y escalables para anunciar varias rutas para circuitos cerrados remotos junto con la información de la clase de transporte en la arquitectura MPLS sin problemas. En las rutas de familia de tranportes clase BGP, se representan diferentes rutas de SLA mediante la comunidad extendida de destino de ruta de transporte, que lleva el color de la clase de transporte. Los enrutadores bgp de recepción usan este destino de ruta de transporte para asociar la ruta de transporte con clase bgp con la clase de transporte adecuada. Cuando vuelva a anunciar las rutas de transporte con clase 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 intraAS de planos de transporte con clase BGP

Figura 4 muestra una topología de red con escenarios anteriores y posteriores de la implementación de planos de transporte con clase BGP en un dominio intraAS. Los dispositivos PE11 y PE12 utilizan LSP RSVP como el túnel de transporte y todas las rutas de túnel de transporte están instaladas en inet.3 RIB. La implementación de planos de transorto clase BGP permite que los túneles de transporte RSVP sean conscientes del color, similar a los túneles de enrutamiento por segmentos.

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

Para clasificar los túneles de transporte en la 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 del plano de transporte clase BGP intraAS:

  • El transporte con clase BGP crea RIB de transporte predefinidos por clase de transporte denominada (oro y bronce) y deriva automáticamente la comunidad de asignación de su valor de color (100 y 200).
  • Las rutas de transporte intraAS se llenan en RIB de transporte mediante el protocolo de tunelización cuando se asocia a 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 los RIB de transporte junos-rti-tc-<100>.inet.3 y junos-rti-tc-<200>.inet.3, respectivamente.

  • El nodo de servicio (PEs de entrada) hace coincidir la comunidad de color extendida (color:0:100 y color:0:200) de la ruta de servicio con la comunidad de asignación en RIB de resolución predefinida y resuelve el siguiente salto de protocolo (PNH) en los RIB de transporte correspondientes (ya sea junos-rti-tc-<100>.inet.3, o junos-rti-tc-<200>.inet.3).
  • Las rutas bgp se enlazan a un esquema de resolución mediante la comunidad de asignación assiocaited.
  • 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 utilizan Color:0:<val> como comunidad de asignación.

    El otro esquema de resolución es para resolver rutas de transporte que utilizan Transport-Target:0:<val> como la comunidad de asignación.

  • Si no se puede resolver la PNH de ruta de servicio mediante 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 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 interAS de planos de transporte con clase BGP

En una red de interAS, el 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 de PE y nodos de borde (ADR 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 (ACR 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, ADR y ASBR).

    Configuración de ejemplo:

    Para LSP RSVP

    Para algoritmos flxibles IS-IS

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

    Configuración de ejemplo:

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

    Configuración de ejemplo:

Funcionalidad del plano de transporte con clase bgp interAS:

  1. Los planos de transporte con clase BGP crean RIB de transporte predefinidos por clase de transporte denominada (oro y bronce) y derivan automáticamente la comunidad de asignación de su valor de color.
  2. Las rutas de transporte intraAS se llenan en 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 los 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 distinguidor de ruta y un destino de ruta únicos cuando copia 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 desde 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 de recepción 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 los RIB de transporte adecuados.
  6. El nodo de servicio hace coincidir la comunidad de color en la ruta de servicio con una comunidad de asignación 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 utilizan esquemas de resolución predefinidos para la resolución de PNH de ruta de transporte.
  8. Predefinidos o definidos por el usuario, ambos esquemas de resolución admiten la resolución de PNH de ruta de servicio. Los usos predefinidos inet.3 como reserva y el esquema de resolución definido por el usuario permite utilizar la lista de RIB de transporte en el orden especificado mientras se resuelve el PNH.
  9. Si no se puede resolver la PNH de ruta de servicio mediante los RIB enumerados en el esquema de resolución definido por el usuario, se descarta la ruta.

Transporte con clase bgp (BGP-CT) con descripción general de túneles SR-TE de color subyacente

Beneficios de BGP-CT con túneles 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.
  • Desacopla los servicios y las capas de transporte, lo que da como resultado una red completamente distribuida.
  • Ofrece administración de ancho de banda independiente a través de un controlador de ingeniería de tráfico dentro del dominio para SR-TE.

Las grandes redes que están creciendo y evolucionando 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 SR-TE de color. BGP-CT puede resolver rutas de servicio mediante los RIB de transporte y calcular el próximo salto. Los servicios que se admiten actualmente a través de BGP-CT también pueden usar los túneles subyacentes de color SR-TE para la resolución de rutas. Ahora, los servicios pueden usar los túneles subyacentes de color SR-TE, como el color estático, el SR-TE bgp, los túneles rpd programables y de color PCEP. 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 ruta del servicio BGP-CT en túneles subyacentes de color SR-TE, incluya la use-transport-class instrucción en el [edit protocols source-packet-routing] nivel de jerarquía.

Nota:
  1. Habilitar la use-transport-class instrucción

    en el [edit protocols source-packet-routing] nivel jerárquico.

    junto con la auto-create instrucción en el [edit routing-options transport-class] nivel de jerarquía.
  2. No somos compatibles con grupos RIB para SR-TE de colores con use-transport-class túneles SR-TE de solo color con esta función.

Mejora de la precisión de la base de datos de ingeniería de tráfico con los mensajes de RSVP PathErr

Un elemento esencial de la ingeniería de tráfico basada en RSVP es la base de datos de ingeniería de tráfico. La base de datos de ingeniería de tráfico contiene una lista completa de todos los nodos de red y vínculos que participan en la ingeniería de tráfico, y un conjunto de atributos que cada uno de esos vínculos puede contener. (Para obtener más información acerca de la base de datos de ingeniería de tráfico, consulte Computación LSP de ruta restringida.) Uno de los atributos de vínculo más importantes es el ancho de banda.

La disponibilidad de ancho de banda en los vínculos cambia rápidamente a medida que se establecen y terminan los LSP RSVP. Es probable que la base de datos de ingeniería de tráfico desarrolle inconsistencias en relación con la red real. Estas inconsistencias no se pueden corregir mediante el aumento de la tasa de actualizaciones del IGP.

La disponibilidad del vínculo puede compartir el mismo problema de inconsistencia. Un vínculo que deja de estar disponible puede interrumpir todos los LSP RSVP existentes. Sin embargo, es posible que la red no sepa fácilmente su falta de disponibilidad.

Cuando configure la rsvp-error-hold-time 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 PathErr transmitidos desde nodos descendentes. La información de los mensajes PathErr se incorpora a los cálculos LSP subsiguientes, 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.

Puede controlar la frecuencia de las actualizaciones de IGP mediante la update-threshold instrucción. Consulte Configurar el umbral de actualización RSVP en una interfaz.

En esta sección se describen los siguientes temas:

Mensajes patherr

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

Cuando configure 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 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 un sobreestimado.

    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 LSP futuros.

  • El vínculo no está disponible para este LSP:

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

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

    • Servicio anticipado: código 12

    • Problema de enrutamiento(ninguna ruta disponible hacia el destino): código 24, subcódigo 5

    Estos tipos de mensajes PathErr suelen ser 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 de servicio (iniciado manualmente por el operador o por otro LSP con mayor prioridad), que un vínculo de salto siguiente está caído, que un vecino del siguiente salto está caído o un 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 la sesión debe atravesar. Junto con la información del nodo de origen, el vínculo 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 mediante la supervisión de mensajes PathErr transmitidos desde nodos descendentes. La información de los mensajes PathErr se incorpora a los cálculos LSP subsiguientes, 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 computación 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. Configurar un valor de 0 deshabilita la supervisión de mensajes PathErr.

Tabla de historial de versiones
Liberación
Descripción
22.1R1
A partir de Junos OS versión 22.1 R1, hemos agregado prefijos IPv6 y compatibilidad con MPLS SID de adyacencia IPv6 en la base de datos de ingeniería de tráfico (TED) y el estado de vínculo bgp (LS).
20.4R1
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.
17.4R1
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
17.2R1
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 controladores de redes definidas por software (RDS).
17.1R1
A partir de Junos OS versión 17.1R1, la distribución de estado de vínculo mediante BGP se admite en conmutadores QFX10000.