Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Cómo configurar algoritmos flexibles en OSPF para la ingeniería de tráfico de enrutamiento por segmentos

Un algoritmo flexible permite que los IGP calculen rutas basadas en restricciones a través de la red, lo que proporciona una ingeniería de tráfico simple sin usar un controlador de red. Esta es una solución ligera para redes que no han implementado un controlador con enrutamiento de segmentos completo, pero que aún desean aprovechar los beneficios del enrutamiento de segmentos en su red.

¿Qué sigue?

Para obtener más información sobre la configuración de algoritmos flexibles, consulte la Guía del usuario de OSPF

Descripción del algoritmo flexible de OSPF para el enrutamiento de segmentos

A partir de Junos OS versión 21.1R1, puede dividir una red mediante la definición de algoritmos flexibles que calculan rutas utilizando diferentes parámetros y restricciones de vínculo en función de sus requisitos. Por ejemplo, puede definir un algoritmo flexible que calcule una ruta para minimizar la métrica IGP y definir otro algoritmo flexible para calcular una ruta basada en una métrica de ingeniería de tráfico para dividir la red en planos separados. Esta característica permite que las redes sin controlador configuren la ingeniería de tráfico utilizando el enrutamiento por segmentos sin implementar realmente un controlador de red. Puede utilizar los SID de prefijo para dirigir los paquetes a lo largo de las rutas basadas en restricciones. Puede configurar los SID de prefijo para un algoritmo flexible mediante configuraciones de directivas.

Los protocolos IGP utilizan una métrica de enlace para calcular la mejor ruta. Sin embargo, la mejor ruta de IGP puede no ser siempre la mejor ruta para ciertos tipos de tráfico. Por lo tanto, la mejor ruta calculada del IGP basada en la métrica de IGP más corta a menudo se reemplaza por una ruta de ingeniería de tráfico debido a los requisitos de tráfico que no se reflejan en la métrica del IGP. Normalmente, RSVP-TE o SR TE se utilizan para calcular la ruta en función de métricas y restricciones adicionales para superar esta limitación. Junos instala dichas rutas en las tablas de reenvío además de la ruta original calculada por los IGP o como reemplazo de esta.

Beneficios de configurar un algoritmo flexible

  • Una versión ligera de la ingeniería de tráfico de enrutamiento por segmentos que se puede utilizar en el núcleo de la red.

  • Le permite configurar la ingeniería de tráfico mediante el enrutamiento de segmentos, incluso sin instalar un controlador de red.

  • Utilice múltiples rutas (ECMP) y TI-LFA de igual costo por segmento sin configurar BGP-LS ni ruta estática.

  • Calcule la ruta de respaldo de TI-LFA utilizando la misma definición de algoritmo flexible y el mismo cálculo de restricciones.

  • Aproveche la ingeniería de tráfico de enrutamiento por segmentos utilizando solo OSPFv2 sin configurar RSVP o LDP.

  • Capacidad para aprovisionar rutas principales restringidas basadas en una sola etiqueta.

¿Qué es la definición flexible de algoritmo (FAD)?

Un algoritmo flexible permite a IGP calcular mejores rutas adicionales basadas en restricciones especificadas, proporcionando así una ingeniería de tráfico simple sin usar un controlador de red. Esta es una solución ligera para redes que no han implementado un controlador con enrutamiento de segmentos completo, pero que aún desean aprovechar los beneficios del enrutamiento de segmentos en su red. Cada operador puede definir restricciones o colores separados dependiendo de sus requisitos.

Para definir un algoritmo flexible, incluya flex-algorithm id una instrucción en el nivel de [edit routing-options] jerarquía. La definición de algoritmo flexible (FAD) se asigna con un identificador que va del 128 al 255. Este algoritmo flexible se puede definir en uno o más enrutadores de una red. Un algoritmo flexible calcula una mejor ruta en función de los siguientes parámetros:

  • Calculation type—SPF o SPF estricto son las dos opciones de tipo de cálculo disponibles. Puede especificar uno de estos tipos de cálculo en su FAD. Seleccione el tipo de cálculo SPF si desea influir en el cálculo de SPF en su dispositivo en función de una determinada política local, como accesos directos de ingeniería de tráfico. Si selecciona SPF estricto, la política local no puede influir en la selección de la ruta SPF.

  • Metric type- La métrica IGP o la métrica TE son las opciones de tipo métrico disponibles. Puede especificar uno de estos tipos de métricas en el FAD en función de los requisitos de su red. Si no desea usar la métrica IGP para un vínculo específico, puede configurar una métrica TE que OSPFv2 puede usar para calcular la ruta.

  • Priority- Puede asignar una prioridad a sus FAD según sus requisitos y OSPFv2 prioriza un anuncio de FAD en particular sobre otro FAD en función de su prioridad asignada.

  • Set of Link constraints- Puede configurar grupos de administradores para muchos protocolos a nivel [edit protocols mpls admin-groups] de jerarquía para colorear un enlace individual. A admin-groups continuación, se pueden definir como include any, include-all o exclude en el nivel jerárquico [edit routing-options flex-algorithm definition admin-groups] .

Recomendamos configurar un algoritmo flexible en solo unos pocos enrutadores para proporcionar redundancia y evitar conflictos. La definición flexible del algoritmo se anuncia en IGP como FAD sub-TLVs. En redes muy grandes, no recomendamos configurar más de 8 definiciones de algoritmo flexibles, ya que cada algoritmo flexible calculará su propia ruta y podría causar problemas de rendimiento más allá de eso.

El FAD predeterminado tiene los siguientes parámetros:

  • Tipo de cálculo: SPF

  • Tipo métrico: IGP-métrico

  • Prioridad: 0

  • Restricciones de vínculo: ninguna

Nota:

Modificar la definición flexible del algoritmo en una red en vivo o sobre la marcha podría causar interrupciones del tráfico hasta que todos los nodos converjan en las nuevas rutas.

A partir de Junos OS 21.4R1, admitimos la definición flexible de algoritmo (FAD) y la "métrica de prefijo de algoritmo flexible (FAPM)" en TED e implementamos dos nuevos TLV correspondientes "FAD TLV" y "FAPM TLV" en BGP-LS. El valor de FAD TLV contiene Flex-Algorithm, Metric-Type, Calculation-Type y Priority, todos los cuales son de un byte cada uno. Es posible que el TLV tenga cero o más subTLV incluidos. Los cinco sub-tlv son Flex Algo Exclude Any Affinity, Flex Algo Include Any Affinity, Flex Algo Include All Affinity, Flex Algo Definition Flags y Flex Algo Exclude SRLG.

El TLV FAD solo se puede agregar al atributo BGP-LS del nodo NLRI si el nodo correspondiente se origina en el TLV o subTLV IGP subyacente. El atributo BGP-LS asociado con un NLRI de nodo puede incluir uno o más TLV FAD correspondientes a la definición de algoritmo flexible para cada algoritmo que el nodo está anunciando.

El valor de FAPM TLV contiene Flex-Algorithm (1 byte), Reserved (3 bytes) y Metric (4 bytes). El TLV FAPM se puede agregar al atributo BGP-LS del prefijo NLRI originado por un nodo, solo si el nodo correspondiente se origina en el prefijo.

A partir de Junos OS versión 22.4R1, definimos la métrica de prefijo de algoritmo flexible (FAPM) para permitir una ruta óptima de extremo a extremo para un prefijo entre áreas. El enrutador de borde de área (ABR) debe incluir el FAPM cuando anuncie el prefijo entre áreas al que se puede acceder en ese algoritmo flexible dado (flex algo). Cuando un prefijo es inalcanzable, el ABR no debe incluir ese prefijo en ese algoritmo flexible cuando se anuncia entre áreas. El FAPM definido proporciona soporte entre áreas.

Participación en un algoritmo flexible

Puede configurar enrutadores específicos para participar en un algoritmo flexible particular según sus requisitos. Las rutas calculadas en base a una definición de algoritmo flexible son utilizadas por varias aplicaciones, cada una potencialmente utilizando su propio plano de datos específico para reenviar los datos a través de dichas rutas. El dispositivo participante debe anunciar explícitamente su participación en un algoritmo flexible particular a cada aplicación en el segmento de algoritmo flexible de enrutamiento sub TLV para OSPFv2. Puede configurar un nodo para que participe en un algoritmo flexible determinado, siempre que admita las restricciones especificadas en ese FAD.

Para configurar la participación en un algoritmo flexible, incluya la flex-algorithm instrucción en el nivel de [edit protocols isis source-packet- routing] jerarquía. El mismo dispositivo puede anunciar un FAD y también participar en un algoritmo flexible.

Topología de red configurada con definiciones de algoritmo flexibles

La figura 1 muestra la topología de ejemplo, hay 8 enrutadores R0, R1, R2, R3, R4, R5, R6 y R7. Se definen y configuran cuatro algoritmos flexibles, 128, 129, 130 y 135, con los grupos de administradores, como se indica en la tabla siguiente:

Definición de algoritmo flexible (FAD)

Color

128

Incluir cualquier rojo

129

Incluir cualquier verde

130

Incluye cualquier verde y azul

135

Excluir rojo

Figura 1: Topología Flexible Algorithm Topology de algoritmo flexible

La figura 2 muestra cómo FAD 128 enruta el tráfico en cualquier interfaz configurada con el grupo de administración rojo.

Figura 2: Flujo de tráfico para una definición de algoritmo flexible 128 Traffic Flow for Flexible Algorithm Definition 128

La figura 3 muestra cómo FAD 129 enruta el tráfico en cualquier interfaz que esté configurada con el grupo de administración verde.

Figura 3: Flujo de tráfico para una definición de algoritmo flexible 129 Traffic Flow for Flexible Algorithm Definition 129

La figura 4 muestra cómo FAD 130 enruta el tráfico en cualquier interfaz configurada con el grupo de administración verde y azul.

Figura 4: Flujo de tráfico para la definición flexible de algoritmo 130 Traffic flow for Flexible Algorithm Definition 130

La figura 5 muestra cómo FAD 135 enruta el tráfico en cualquier interfaz que no esté configurada con el grupo de administración rojo.

Figura 5: Flujo de tráfico para la definición flexible de algoritmo 135 Traffic Flow for Flexible Algorithm Definition 135

RIB de algoritmo flexible

Por cada algoritmo flexible en el que participa un enrutador, las rutas de algoritmo flexible correspondientes se instalan en los grupos RIB de algoritmo flexible correspondientes, también conocidos como tablas de enrutamiento. De forma predeterminada, las rutas de algoritmo flexible OSPFv2 etiquetadas se instalan en los RIB inet.color inet(6)color.0 y mpls.0 RIB.

Comunidad BGP y algoritmos flexibles

Un algoritmo flexible puede tener asociada una comunidad de colores BGP para resolver rutas de otros servicios, como el servicio VPN. De forma predeterminada, la comunidad de colores BGP asociada es la misma que el ID de algoritmo flexible. Las rutas de entrada de algoritmo flexible que se instalan en las tablas inet(6)color.0 tendrán esta comunidad de colores en la ruta. Sin embargo, puede configurar una comunidad de colores BGP diferente en el nivel jerárquico [edit routing-options flex-algorithm id color desired color community value] .

Nota:

Cambiar la comunidad de colores BGP por un algoritmo flexible puede provocar la interrupción del tráfico. Si modifica una comunidad de colores BGP para un algoritmo flexible, todas las rutas pertenecientes a ese algoritmo flexible se eliminan de la RIB y se agregan de nuevo con nuevos colores.

Características admitidas y no compatibles

Junos OS admite algoritmos flexibles en los siguientes escenarios:

  • Soporte para configurar y publicitar SID de prefijo para diferentes algoritmos flexibles.

  • Parcialmente compatible con Internet Draft draft-ietf-lsr-flex-algo-05.txt IGP Flexible Algorithm

  • La implementación actual para algoritmos flexibles solo se admite para OSPFv2, ya que solo OSPFv2 admite el enrutamiento de segmentos.

Junos OS no admite las siguientes funciones junto con algoritmos flexibles:

  • No se admite la métrica de retraso de vínculo.

  • El algoritmo flexible solo se aplica a la topología de unidifusión predeterminada, no se admite la topología múltiple OSPFv2.

  • Los accesos directos de OSPFv2 y otras opciones de configuración de ingeniería de tráfico de OSPFv2 no son aplicables para el cálculo flexible de algoritmos. .
  • La implementación actual de algoritmos flexibles no es compatible con OSPFv3.
  • No se admite la fuga entre áreas (OSPFv2) de SID de prefijo de algoritmo flexible.

  • No se admite la resolución de conflictos de prefijo ni SID.

  • La funcionalidad alternativa sin bucle remoto no es compatible porque TI-LFA es el cálculo de FRR preferido.

  • No se admite la publicidad de la definición de algoritmo flexible en ausencia de una participación flexible del algoritmo.

  • No se admite la publicidad de atributos de vínculo para el algoritmo flexible mediante anuncios de atributos de vínculo específicos de la aplicación.

  • No se admite la RIB de clase de transporte.

Algoritmo flexible basado en atributos de vínculo específicos de la aplicación

A partir de Junos OS y Junos OS Evolved versión 22.2R1, puede anunciar diferentes atributos te, como te-metric, delay-métric o admin-groups para RSVP y algoritmos flexibles en el mismo vínculo. Esto se hace utilizando el atributo de vínculo específico de la aplicación específico del algoritmo flexible, tal como se define en RFC 8920.

La ventaja de tener un atributo de enlace específico de la aplicación de algoritmo flexible que anuncie te-métrica, métrica de retraso o grupos de administración es que un solo enlace puede anunciar diferentes atributos de vínculo te para aplicaciones heredadas como RSVP y diferentes atributos de enlace te para algoritmos flexibles.

Para configurar un atributo te específico de la aplicación de algoritmo flexible, incluya la application-specific instrucción en el nivel de [edit protocols ospf area interface] jerarquía y la strict-asla-based-flex-algorithm instrucción en el nivel de [edit protocols ospf source-packet-routing] jerarquía. Con esta implementación, ya no es obligatorio que el enlace tenga RSVP habilitado y [edit protocols ospf traffic-engineering advertisement always] configurado, como es el caso del comportamiento existente de los atributos de ingeniería de tráfico publicitario.

Nota:

La implementación de Junos OS y Junos OS Evolved del atributo de vínculo específico de la aplicación solo admite aplicaciones de algoritmos flexibles.

Algoritmo flexible basado en atributos de enlace estrictos específicos de la aplicación

El comportamiento predeterminado del algoritmo flexible específico de la aplicación es usar el algoritmo flexible atributos t específicos de la aplicación para un vínculo si está disponible, y si no, recurrir a los atributos t comunes específicos de la aplicación y, si ninguno de los dos está disponible, usar los atributos te heredados.

La instrucción strict-asla-based-flex-algorithm de configuración en el [edit protocols ospf source-packet-routing] debe aplicarse a todos los algoritmos flexibles que se ejecutan en los dispositivos de la red para evitar bucles de enrutamiento.

Si strict-asla-based-flex-algorithm está configurado en todos los dispositivos, se debe anunciar un atributo te común específico de la aplicación o un atributo t específico de la aplicación flexible para cada enlace de algoritmo flexible. En ausencia de atributos te específicos de la aplicación, el dispositivo no recurre a los atributos te heredados y simplemente ignora el vínculo.

El sistema operativo admite las siguientes características junto con el algoritmo flexible basado en atributos de vínculo específicos de la aplicación:

  • El subTLV de atributo te específico de la aplicación para cumplir con RFC 8920. El subTLV de atributos te específicos de la aplicación es un subTLV del TLV de vínculo extendido OSPFv2 tal como se define en RFC 7684.

  • Admite parcialmente la máscara de bits de identificador de aplicación estándar para anunciar X-bit para algoritmos flexibles. Solo se anuncian los grupos te-metric, delay-metric o admin-group como parte del atributo de vínculo específico de la aplicación sub-TLV.

El sistema operativo no admite las siguientes características junto con el algoritmo flexible basado en atributos de vínculo específicos de la aplicación:

  • No se admite la publicidad de máscaras de bits de identificador de aplicación definidas por el usuario.
  • No se admite la republicidad de un atributo de vínculo específico de la aplicación o, más bien, cualquier atributo de vínculo específico de la aplicación con BGP-LS porque la base de datos de ingeniería de tráfico (TED) no admite el atributo de vínculo específico de la aplicación.
  • No se admite la publicidad de un atributo de vínculo común específico de la aplicación con máscara de bits de identificador de aplicación estándar y máscara de bits de identificador de aplicación definida por el usuario establecida en cero.

  • No se admite la restricción de vínculo SRLG de publicidad en algoritmo flexible.

  • No se admite la ingeniería de tráfico compatible con varias aplicaciones, excepto para algoritmos flexibles.

  • No se admite la definición de grupos de administración independientes de MPLS.

Ejemplo: algoritmo flexible OSPF

Visión general

En este ejemplo se muestra cómo configurar un algoritmo flexible en una red OSPFv2. El algoritmo flexible permite que las redes sin controlador configuren la ingeniería de tráfico utilizando el enrutamiento por segmentos sin tener que implementar realmente un controlador de red.

A partir de Junos OS versión 21.1R1, puede dividir una red mediante la definición de algoritmos flexibles que calculan rutas utilizando diferentes parámetros y restricciones de vínculo en función de sus requisitos. El conjunto que consta de tipo de cálculo, tipo métrico y un conjunto de restricciones se denomina definición de algoritmo flexible (FAD). Puede definir DCP y anunciarlos en una red OSPFv2. Un dispositivo también se puede configurar para participar en un determinado algoritmo flexible siempre que admita las restricciones de ese FAD específico.

Topología

La figura 6 muestra una topología de algoritmo flexible en la que hay 6 dispositivos R0, R1, R2, R3, R4 y R5. Se definen dos algoritmos flexibles 128 y 129 en cada uno de estos dispositivos. Los grupos de administración rojo, azul y verde están configurados en los dispositivos. Los FAD con diferentes parámetros, como tipos métricos, tipos de cálculo y restricciones de vínculo, se definen en cada uno de los dispositivos.

Figura 6: Topología Flexible Algorithm Topology de algoritmo flexible

Requisitos

En este ejemplo se utilizan los siguientes componentes de hardware y software:

  • Seis enrutadores de la serie MX.
  • Junos OS versión 21.1R1 o posterior ejecutándose en todos los dispositivos.

Configuración

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit].

Dispositivo R0

Dispositivo R1

Dispositivo R2

Dispositivo R3

Dispositivo R4

Dispositivo R5

Configuración del dispositivo R0

Para configurar un algoritmo flexible para OSPFv2, realice los pasos siguientes en el dispositivo R0:

  1. Configure las interfaces de dispositivo para habilitar el transporte IP.

  2. Configure la dirección de interfaz de circuito cerrado (lo0) que se utiliza como ID de enrutador para las sesiones OSPF.

  3. Configure el ID del enrutador y el número de sistema autónomo (AS) para propagar la información de enrutamiento dentro de un conjunto de dispositivos de enrutamiento que pertenezcan al mismo AS.

  4. Defina una política para equilibrar la carga de paquetes y aplique la política por paquete para habilitar el equilibrio de carga del tráfico.

  5. Configure el filtro de ruta para el término de política de enrutamiento que permite que el dispositivo R0 llegue a la red 192.168.255.10/32.

  6. Configure MPLS en todas las interfaces, excepto en la de administración.
  7. Configure el intervalo de etiquetas MPLS para asignar etiquetas estáticas para los vínculos.

  8. Configure TI-LFA para habilitar la protección contra fallas de vínculos y nodos. El SR que usa TI-LFA proporciona una restauración más rápida de la conectividad de red al enrutar el tráfico instantáneamente a una copia de seguridad o una ruta alternativa si la ruta principal falla o no está disponible.

  9. Configure el número máximo de etiquetas para las rutas enrutadas de enrutamiento de segmentos para proteger los atributos de ruta más corta de copia de seguridad.

  10. Configure los atributos de segmento de prefijo, la etiqueta de inicio y el rango de índice para bloques globales de enrutamiento de segmentos (SRGB) en SPRING para el protocolo OSPF.

  11. Habilite la protección de vínculo de nodo en las interfaces OSPF que siguen la ruta posterior a la convergencia.

  12. Configure la interfaz de circuito cerrado como pasiva para asegurarse de que los protocolos no se ejecutan en la interfaz de circuito cerrado y de que la interfaz de circuito cerrado se anuncia correctamente en toda la red.

  13. Definir algoritmos flexibles en el dispositivo R0. Asigne un nombre para cada uno de los DCP que van del 128 al 255.

    Especifique los parámetros de la definición. OSPFv2 calcula la ruta en función de estos parámetros especificados del FAD.

    1. Especifique el tipo de cálculo en función del cual el protocolo OSPFv2 calcula la ruta de acceso.

    2. Especifique el tipo de métrica en función del cual OSPFv2 calcula la ruta.

    3. Si ha habilitado la ingeniería de tráfico RSVP, puede configurar grupos de administradores para muchos protocolos para colorear un enlace individual.

    4. Asigne las directivas de grupos de administradores configuradas a las interfaces R0 del dispositivo.

    5. Defina los grupos de administración según sus requisitos.

      Nota:

      Para que los FAD con restricciones de vínculo funcionen, todos los enlaces relevantes deben anunciar los colores de administración en OSPFv2. Debe habilitar RSVP en las interfaces o, si no ha configurado RSVP para ingeniería de tráfico, asegúrese de configurar set traffic-engineering advertise siempre en el nivel jerárquico [edit protocols ospf] .

  14. Configure la participación flexible del algoritmo en el dispositivo R0. El mismo dispositivo puede anunciar un FAD y también participar en un algoritmo flexible.
  15. Anuncie segmentos de prefijos mediante la configuración de políticas.

Resultados

Compruebe los resultados de la configuración:

Desde el modo de configuración, escriba los comandos , , y para confirmar la configuración. show interfacesshow routing-optionsshow protocolsshow policy-options Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Verificación

Para confirmar que la configuración funciona correctamente, realice las siguientes tareas:

Verificación de la base de datos OSPF

Propósito

Verificar que la señalización flexible del algoritmo se muestra en la base de datos OSPF.

Acción

Desde el modo operativo, ejecute el show ospf database opaque-area extensive comando.

En R0

Significado

Este resultado en R0 ilustra que:

Este dispositivo anuncia tres algoritmos de enrutamiento por segmentos (incluidos dos algoritmos flexibles).

Este dispositivo anuncia dos DCP.

Verificación de los detalles flexibles del algoritmo

Propósito

Verificar que se muestran los detalles flexibles del algoritmo.

Acción

Desde el modo operativo, ejecute el show ospf spring flex-algorithm <flex-algorithm-id> comando.

En R0

Significado

Se muestran los detalles flexibles del algoritmo que se configuran en R0.

Verificación de rutas internas OSPF específicas de algoritmo flexible

Propósito

Comprobación de que se muestran las rutas internas OSPF específicas del algoritmo fexible.

Acción

Desde el modo operativo, ejecute el show ospf route flex-algorithm <flex-algorithm-id> comando.

En R0

Significado

El show ospf route comando se extiende con flex-algorithm la opción de mostrar rutas internas OSPF específicas del algoritmo flexible. Cada ruta tiene el prefijo flex-algo-id:

Verificación de rutas de colores flexibles

Propósito

Comprobación de que se muestran las rutas internas OSPF específicas del algoritmo fexible.

Acción

Desde el modo operativo, ejecute el show route protocol ospf comando.

En R0

Significado

La salida muestra todas las rutas flex coloreadas programadas en la tabla inetcolor.0 en el siguiente formato: prefix_address-flex-algo-id<c>/64

Comprobación de registros OSPF

Propósito

Al comprobar que los registros de OSPF se muestra la palabra clave flexible del algoritmo.

Acción

Desde el modo operativo, ejecute el show ospf log comando.

En R0

Significado

El resultado muestra la palabra clave FlexAlgo agregada para los registros SPF.