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 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 serían seleccionados por la ruta más corta calculada automáticamente y basada en destino. Con la ingeniería de tráfico, puede:

  • Haga un uso más eficiente de las costosas fibras de larga distancia.

  • Controle cómo se redirige el tráfico frente a fallas únicas o múltiples.

  • 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 creación de rutas de conmutación de etiquetas (LSP) entre los 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 entran en 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 entran en una ruta se encapsulan en una envolvente y se conmutan a través de toda la ruta sin ser tocados por nodos intermedios. Los LSP proporcionan un control detallado sobre cómo se reenvían los paquetes en una red. Para proporcionar confiabilidad, un LSP puede utilizar un conjunto de rutas primarias y secundarias.

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

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

La ingeniería de tráfico facilita operaciones de red eficientes y confiables y, al mismo tiempo, optimiza los recursos de red y el rendimiento del tráfico. La ingeniería de tráfico proporciona 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 calculada la ruta de acceso.

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

Cuando el tráfico de tránsito se enruta a través de una red IP, 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 desean 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 basados en búsquedas de salto siguiente. Las rutas resultantes se denominan rutas de conmutación de etiquetas (LSP). Los LSP controlan el paso del tráfico a través de la red y aceleran el reenvío del 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 a través de 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 reenvío de paquetes

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

  • Ruta restringida más corta primero (CSPF) para cálculo y selección de rutas

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

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

Capacidades de ingeniería de tráfico

La tarea de mapear flujos de tráfico en una topología física existente se denomina ingeniería de tráfico. La ingeniería de tráfico proporciona 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.

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

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

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

  • Proporcionar un uso más eficiente del ancho de banda agregado disponible y la fibra de larga distancia asegurándose de que los subconjuntos de la red no se sobreutilicen mientras que otros subconjuntos de la red a lo largo de posibles rutas alternativas 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 el rendimiento.

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

Componentes de la ingeniería de tráfico

En el sistema operativo (SO) Junos®, 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 la ingeniería de tráfico para LSP

Cuando se 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 para la traffic engineering instrucción en el nivel de [edit protocols mpls] jerarquía está habilitada de forma predeterminada (también puede configurar explícitamente la bgp opción), lo que permite que solo BGP use LSP en sus cálculos de ruta. Las otras traffic-engineering opciones de instrucción permiten modificar este comportamiento en la instancia de enrutamiento maestra. Esta funcionalidad no está disponible para instancias de enrutamiento específicas. Además, sólo puede habilitar una de las traffic-engineering opciones de instrucción (bgp, bgp-igp, bgp-igp-both-ribs, o mpls-forwarding) a la vez.

Nota:

Al habilitar o deshabilitar cualquiera de las opciones de la traffic-engineering instrucción, se quitan todas las rutas MPLS y, a continuación, se vuelven 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) de resumen, tal como se describe en la sección Publicidad de la métrica LSP en resumen LSA.

En las secciones siguientes 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 BGP y los IGP para que usen LSP para reenviar el tráfico destinado a enrutadores de salida incluyendo la bgp-igp opción para la traffic-engineering instrucción. La bgp-igp opción hace que todas las rutas inet.3 se muevan a la tabla de enrutamiento inet.0.

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

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

  • [edit protocols mpls]

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

    Nota:

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

Uso de LSP para reenvío en redes privadas virtuales

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

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

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

  • [edit protocols mpls]

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

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

Nota:

Los LSP con el valor de preferencia numéricamente más bajo se eligen como la ruta preferida.

Por ejemplo:

El LSP con un valor de preferencia de 1000 es superior y, por lo tanto, se prefiere al LSP con un valor de preferencia de 1001.

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

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

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

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

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

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

  • [edit protocols mpls]

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

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

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

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

Publicidad de la métrica LSP en resumen LSA

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

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

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

  • [edit protocols mpls]

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

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

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

  • [edit protocols ospf traffic-engineering shortcuts]

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

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

Habilitación de la ingeniería de tráfico entre áreas

Junos OS puede señalar un LSP de ingeniería de tráfico contiguo en varias áreas de OSPF. La señalización de LSP debe realizarse mediante anidamiento o 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 multiprotocolo generalizada (GMPLS). Sin embargo, la compatibilidad con la señalización contigua se limita solo 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 características de ingeniería de tráfico entre áreas:

  • La ingeniería de tráfico entre áreas se puede habilitar cuando los enrutadores de borde de área de salto suelto (ABR) 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 en los ABR.

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

  • Se admite la ingeniería de tráfico de servicios diferenciados (DiffServ) siempre que las asignaciones de tipo de clase sean uniformes en varias áreas.

Para habilitar la ingeniería de tráfico entre áreas, 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 la ingeniería de tráfico de interAS para LSP

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

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

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

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

Sin ASBR definidos estáticamente en los LSP, no es posible realizar ingeniería de tráfico entre un dominio de enrutamiento, o AS, y otro. Sin embargo, cuando los AS están bajo el control de un único proveedor de servicios, es posible en algunos casos que los LSP diseñados para el tráfico abarquen los AS y descubran dinámicamente los ASBR de OSPF que los vinculan (IS-IS no es compatible con esta característica).

Los LSP de ingeniería de tráfico entre AS son posibles siempre que se cumplan ciertos requisitos de red, no se aplique ninguna de las condiciones limitantes y el modo pasivo OSPF esté configurado con EBGP. Los detalles se proporcionan en las siguientes secciones:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • No se admite el modo de espera secundario.

  • No se admite la reoptimización.

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

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

  • No se admite el reinicio correcto.

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

Configuración del modo TE pasivo de OSPF

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

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

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

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

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 simplex; es decir, el tráfico fluye en una dirección desde el enrutador de cabecera (entrada) a un enrutador de extremo final (salida). El tráfico dúplex requiere dos LSP: un LSP para transportar tráfico en cada dirección. Un 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. El paquete etiquetado es reenviado a lo largo del LSP por cada enrutador hasta que llega al final del LSP, el enrutador de salida. En este punto, se elimina el encabezado MPLS y el paquete se reenvía en función de 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 de modo de transferencia asíncrono (ATM) en un circuito virtual permanente (PVC). Cada paquete MPLS lleva un encabezado de encapsulación de 4 bytes que contiene un campo de etiqueta de longitud fija de 20 bits. Cuando un paquete que contiene una etiqueta llega a un enrutador, el enrutador examina la etiqueta y la copia como un índice a su tabla de reenvío MPLS. Cada entrada de la tabla de reenvío contiene un par de etiquetas de entrada de interfaz asignado a un conjunto de información de reenvío que se aplica a todos los paquetes que llegan a la interfaz específica con la misma etiqueta de entrada.

Cómo atraviesa un paquete una red troncal MPLS

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

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

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

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

Componente de distribución de información

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

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

Componente de selección de ruta

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

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

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

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

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

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

Componente de señalización

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

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

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

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

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

A pesar de la reducción del esfuerzo de gestión resultante del cálculo de rutas en línea, todavía se requiere una herramienta de planificación y análisis fuera de línea 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 juega un papel crítico en la determinación de la ruta física de cada LSP a través de 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, también puede cambiar el conjunto resultante de rutas físicas para los LSP.

Una herramienta de planificación y análisis fuera de línea examina simultáneamente las limitaciones de recursos de cada enlace 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, a continuación, 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 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 mapear el flujo de tráfico en una topología física. Puede determinar las rutas en línea mediante el 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 a través de RSVP.

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

  • Puede calcular la ruta completa del LSP sin conexión y configurar individualmente cada enrutador del 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 de IP a través de ATM.

  • Puede calcular la ruta completa del 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 dinámicos de LSP en línea. Las restricciones se configuran para cada LSP; Luego, la propia red determina la ruta que mejor cumple con esas restricciones. En concreto, el enrutador de entrada calcula todo el LSP en función de las restricciones y, a continuación, 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; A continuación, puede permitir el cálculo en línea para determinar la ruta completa.

    Por ejemplo, considere una topología que incluye dos rutas este-oeste a través de 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 de Nueva York y otro de San Francisco, puede configurar la ruta parcial del LSP para que incluya un solo salto de ruta suelta de un enrutador en Dallas. El resultado es un LSP enrutado a lo largo del camino 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 restricción alguna. En este caso, se utiliza el enrutamiento de ruta más corta normal del IGP 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 se base en restricciones y hacer que la ruta terciaria no tenga restricciones. Si falla un circuito en el que se enruta el LSP principal, el enrutador de entrada nota la interrupción debido a las notificaciones de error recibidas de un enrutador descendente o por la expiración de la información de estado suave del RSVP. A continuación, el enrutador reenvía dinámicamente el tráfico a un LSP de 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

Beneficios de los aviones de transporte con clase BGP

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

  • Interoperabilidad entre dominios: extiende el despliegue de clases de transporte a través de dominios que cooperan para que los diferentes protocolos de señalización de transporte en cada dominio interoperen. Concilia cualquier diferencia entre los espacios de nombres de comunidad extendidos que pueden estar en uso en cada dominio.
  • Resolución coloreada con reserva: permite la resolución sobre túneles de color (RSVP, algoritmo flexible IS-IS) con opciones flexibles de reserva sobre túneles de mejor esfuerzo o cualquier otro túnel de color.

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

Terminología de los planos de transporte con clase BGP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Descripción de los planos de transporte con clase BGP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Configuración de ejemplo:

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

    Configuración de ejemplo:

Funcionalidad del plano de transporte con clase del BGP intraAS:

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

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

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

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

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

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

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

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

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

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

    Configuración de ejemplo:

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

    Configuración de ejemplo:

    Para RSVP LSP

    Para el algoritmo FLXIBLE IS-IS

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

    Configuración de ejemplo:

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

    Configuración de ejemplo:

Funcionalidad de plano de transporte con clase de InterAS BGP:

  1. Los planos de transporte con clase BGP crean RIB de transporte predefinidas por clase de transporte con nombre (oro y bronce) y derivan automáticamente la comunidad de mapeo de su valor de color.
  2. Las rutas de transporte intra-AS se rellenan en las RIB de transporte mediante protocolos de tunelización cuando se asocian a una clase de transporte.

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

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

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

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

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

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

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

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 jerárquico.
  2. No se admiten grupos RIB para túneles SR-TE de color con use-transport-class túneles SR-TE de solo color con esta característica.

Mejora de la precisión de la base de datos de ingeniería de tráfico con mensajes 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, vea Cálculo de LSP de ruta restringida). Uno de los atributos de enlace más importantes es el ancho de banda.

La disponibilidad de ancho de banda en los enlaces cambia rápidamente a medida que se establecen y terminan los LSP de 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 solucionar aumentando la tasa de actualizaciones de IGP.

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

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

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

En esta sección se tratan los siguientes temas:

Mensajes de PathErr

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

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

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

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

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

  • Vínculo no disponible para este LSP:

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

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

    • Servicio preferenciado: código 12

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

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

Identificación del vínculo del problema

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

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

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

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

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

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

  • [edit protocols mpls]

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

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

Tabla de historial de cambios

La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.

Liberación
Descripción
23.1R1
A partir de Junos OS versión 23.1R1, Junos OS habilita el estado de vínculo BGP-LS NLRI de BGP para llevar el ID de confederación en TLV 512 cuando la confederación BGP está habilitada. La NLRI lleva el ID de confederación junto con el número de AS miembro en TLV 517 como se define en RFC 9086.
22.1R1
A partir de la versión 22.1 R1 de Junos OS, agregamos 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 enlace 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 información de topología del protocolo de puerta de enlace interior (IGP) además de información de topología RSVP-TE en la tabla de enrutamiento lsdist.0
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 los controladores de redes definidas por software (SDN).
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.