Mecanismo de convergencia de rutas explícitas basadas en políticas SR-TE con protección de nodo TI-LFA

Introducción

Este documento describe la protección de nodos para la ruta principal explícita mediante la opción Topology Independent (TI) - Loop-Free Alternative (LFA) y la solución mediante la ruta Segment Routing (SR) - Traffic Engineering (TE) con la métrica SR-TE y el algoritmo flexible Open Shortest Path First (OSPF) .

Problema

En esta sección se explican los requisitos de las redes XYZ, las restricciones de diseño y la razón por la que la ruta de copia de seguridad de TI-LFA no protege ningún fallo de nodo intermedio para una ruta principal definida explícitamente.

Requirements

Según las redes XYZ, estos son los requisitos de su diseño de red desde cero:

1. La ruta de tráfico principal debe estar definida y controlada explícitamente por la política SR-TE (admin), pero no por la métrica IGP.

2. En caso de fallo de enlace o nodo, el tráfico debe converger a una ruta de copia de seguridad en menos de 50 milisegundos de tiempo con una red de escala cero.

Si observa la Figura 1., se ha configurado una política SR-TE de extremo a extremo en el nodo de origen PE1, siendo PE3 el nodo de destino.

Las sinopsis de las configuraciones SR-TE y OSPF son:

segment-routing
 traffic-eng
   !
  !
  segment-list PrimaryPath1
   index 10 mpls adjacency 10.1.11.0 --> First Hop (P1 node) of the explicit-path
   index 20 mpls adjacency 10.1.3.1  --> Second Hop (P3 node) of the explicit-path
   index 30 mpls adjacency 10.3.13.1 --> Third Hop (PE3 node) of the explicit-path
  !
  policy POL1
   source-address ipv4 11.11.11.11          --> Source Node of the explicit-path
   color 10 end-point ipv4 33.33.33.33      --> Destination Node of the explicit-path
   candidate-paths
    preference 100         --> Secondary Path taken care of dynamically by IGP TI-LFA 
     dynamic
      metric
       type igp         
      !
     !
    !
    preference 200
     explicit segment-list PrimaryPath1   --> Primary Explicit-Path of the SR-TE policy 
     !
    !

router ospf CORE
 nsr
distribute link-state
 log adjacency changes
 router-id 11.11.11.11
 segment-routing mpls
 nsf cisco
 microloop avoidance segment-routing
 max-metric router-lsa on-startup 360
 area 0
  interface Bundle-Ether111    --> Primary Explicit-Path Interface
   authentication null
   network point-to-point
   fast-reroute per-prefix     
   fast-reroute per-prefix ti-lfa enable       --> Enabling TI-LFA on the primary interface
   fast-reroute per-prefix tiebreaker node-protecting index 100
   fast-reroute per-prefix tiebreaker srlg-disjoint index 200
   prefix-suppression
  !
  interface Bundle-Ether211    --> Secondary Dynamic Path Interface
   authentication null
   network point-to-point
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa enable       --> Enabling TI-LFA on the secondary interface
   fast-reroute per-prefix tiebreaker node-protecting index 100
   fast-reroute per-prefix tiebreaker srlg-disjoint index 200
   prefix-suppression
  !
  interface Loopback80
   passive enable
   prefix-sid index 32130         --> Enabling Node SID on the loopback interface
  !
 !

Esta configuración es un método de ejemplo para configurar una política SR-TE controlada por ruta explícita; también hay otras maneras. Y en OSPF, se observa que TI-LFA está habilitado.

Sin embargo, con la combinación de las funciones SR-TE y OSPF, se encuentra en el laboratorio con la política de ruta explícita SR-TE que OSPF TI-LFA no puede curvar e instalar una ruta de respaldo post-convergencia, de extremo a extremo (PE1 a PE3) de la ruta principal explícita SR-TE para escenarios de falla de nodo intermedios, como se muestra en la Figura 2. Como resultado, el tiempo de convergencia de la protección del tráfico supera con creces los 50 ms en caso de que el nodo P1 o P3 deje de funcionar.

Se ha elegido un ejemplo simple para explicar el problema:

Figura 1: Situación de tráfico normal

Como en la Figura 1., el nodo de origen del tráfico es PE1 y el nodo de destino es PE3. Aquí, si configuramos una política de trayectoria explícita de SR-TE donde existe una necesidad administrativa de enviar el tráfico a través de la trayectoria de tráfico primaria explícita PE1> P1> P3> PE3, se indica que debe hacerlo.

En esta situación, si configuramos una trayectoria SR-TE explícita a través de PE1> P1 > P3> PE3, entonces en caso de falla del nodo como se muestra en la Figura 2., TI-LFA no puede proteger el escenario de falla del nodo pero sólo puede proteger el escenario de falla del link. El escenario de falla de link se ha tratado en detalle en el documento de referencia Convergencia de la Trayectoria Explícita SR-TE para la Protección de Link.

Figura 2: Escenario de tráfico de failover

TI-LFA, una vez configurado en OSPF, de forma predeterminada, señala al SID de nodo del nodo de destino para calcular e instalar la ruta de copia de seguridad en el plano de datos.

Pero para esta configuración de escenario y conjunto de funciones, la cobertura de TI-LFA desde el nodo de origen al nodo de destino no funciona, o en otras palabras, la trayectoria de respaldo de TI-LFA no puede proteger cualquier falla del nodo intermedio por debajo de 50 mseg para la trayectoria primaria definida explícitamente.

El análisis muestra que el algoritmo de cálculo de la trayectoria de respaldo TI-LFA toma el primer salto/nodo siguiente en la trayectoria explícita como el punto final de destino en lugar del nodo de destino real y calcula la trayectoria de respaldo tratando de proteger solamente el primer salto/nodo siguiente, por ejemplo, el nodo P1 como en la Figura 2. Como resultado, TI-LFA no puede calcular e instalar una trayectoria de respaldo para proteger el punto final real o el nodo de destino, por ejemplo, el nodo PE3.

Por lo tanto, no puede proporcionar protección de extremo a extremo dentro de los 50 mseg de la convergencia para el nodo de destino PE3 real para una falla de nodo intermedio en una trayectoria de tráfico primario definida explícitamente.

Otra manera de verlo es en la Figura 1., si configura el nodo P3 como el salto siguiente en la trayectoria explícita, entonces TI-LFA puede proporcionar menos de 50 mseg de protección para la falla del nodo P1 y viceversa. Pero la protección del nodo no puede ocurrir para ese nodo en particular que se define como uno de los saltos explícitos de la trayectoria explícita de extremo a extremo.

Solución

Esta sección se centra en los puntos para escenarios específicos de trayectoria primaria explícita:

Una solución probada y probada es incorporar algunas características/modificaciones adicionales al escenario para permitir que TI-LFA se ocupe de los menos de 50 mseg de convergencia durante el escenario de falla del nodo, así como de la falla del link. Esta solución se ha elegido en función de los requisitos de la red XYZ, como se menciona en la sección de problemas.

1. Explicit-Path es necesario, pero la métrica IGP no se puede utilizar según el requisito.

2. Por lo tanto, se utiliza una métrica alternativa (métrica SR-TE) para dirigir el tráfico en un trayecto determinado sin especificar los saltos explícitos.

3. OSPF Flex-Algo se utiliza para enviar tráfico al nodo de destino (mediante un SID de nodo de Flex-Algo independiente al que se puede acceder a través de flex algo) a través de la topología que utiliza la métrica SR-TE.

3. Después de agregar OSPF Flex-Algo, TI-LFA puede funcionar normalmente ya que ahora puede proteger el SID de nodo de destino real.

Comprensión Diferentes componentes de la solución

Característica de ruta explícita

Dado que, según uno de los requisitos, la métrica IGP no se puede utilizar para el control explícito de la ruta principal, la característica simplificada explícita de la ruta principal SR-TE se controla a través de la métrica TE configurada adicionalmente en las interfaces SR-TE (en routing de segmentos) para todos los nodos, incluido el nodo PE de cabecera hasta el PE de destino remoto. Sus métricas SR-TE son a su vez utilizadas por OSPF Flex Algo para crear una trayectoria explícita bajo el paradigma flex-algo.

Métrica SR-TE en Segment Routing en PE1:

segment-routing
 global-block 100000 299999
 traffic-eng
  interface Bundle-Ether111
   metric 10  --> SR-TE Metric of BE111 is less that BE211, so it is a more preferred explicit path given that rest of the SR-TE link cost is same
  !
 interface Bundle-Ether211
   metric 100
  !
  logging
   policy status
  !
  policy er100_to_er102   --> SR-TE policy defined
   source-address ipv4 11.11.11.11.       --> Source Node of the explicit-path
   color 150 end-point ipv4 33.33.33.33   --> Destination Node of the explicit-path
   autoroute
    force-sr-include
    include all
   !
   candidate-paths
    preference 200
     dynamic    --> Here that the primary path is configured as dynamic but it is the SR-TE metric defined above which helps Flex-Algo make it fixed or explicit
     !
     constraints
      segments
       sid-algorithm 128.  --> Primary SR-TE path is configured with constraint as Flex-Algo 128 with no explicit backup path since TI-LFA takes care of the backup path implicitly ensuring sub 50 msec of convergence
      !
     !

Comando show en el nodo PE1:

P/0/RP0/CPU0:PE1#show segment-routing traffic-eng policy 
Fri Feb  3 10:25:24.716 UTC

SR-TE policy database
---------------------
Color: 150, End-point: 33.33.33.33  --> Color and Endpoint Loopback IP address of PE3
  Name: srte_c_150_ep_33.33.33.33
  Status:
    Admin: up  Operational: up for 04:57:30 (since Feb  3 05:27:54.774)
  Candidate-paths:
    Preference: 200 (configuration) (active)   --> Preference of 200 as configured under SR-TE policy
      Name: er100_to_er102
      Requested BSID: dynamic
      Constraints:
        Prefix-SID Algorithm: 128    --> Attached to Flex-Algo 128 as configured under SR-TE policy
        Protection Type: protected-preferred   --> Protected Primary Path
        Maximum SID Depth: 12 
      Dynamic (valid)
        Metric Type: TE,   Path Accumulated Metric: 0   --> Metric Type is SR-TE metric
          133138 [Prefix-SID: 33.33.33.33, Algorithm: 128]. --> Node SID of destination node PE3 with index 33138
   Attributes:
    Binding SID: 24010
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes
    Invalidation drop enabled: no

OSPF Flex-Algo

Información general:

El algoritmo flexible de ruteo de segmentos permite a los operadores personalizar el cálculo de la trayectoria más corta de IGP según sus propias necesidades. Un operador puede asignar SID de prefijo SR personalizados para realizar el reenvío más allá del SPF basado en costos de link. Como resultado, el Algoritmo Flexible proporciona una trayectoria de ingeniería de tráfico calculada automáticamente por el IGP a cualquier destino alcanzable por el IGP.

Para proporcionar la máxima flexibilidad, el usuario puede definir la asignación entre el valor del algoritmo y su significado. Cuando todos los routers en el dominio tienen un entendimiento común de lo que representa el valor del algoritmo en particular, el cálculo para dicho algoritmo es consistente y el tráfico no está sujeto a loops. Aquí, dado que el significado del algoritmo no está definido por ningún estándar, sino que lo define el usuario, se denomina Algoritmo Flexible.

Bajo el paradigma de ruteo OSPF, se pueden utilizar muchas restricciones posibles para calcular una trayectoria sobre una red. Algunas redes se implementan con un único plano IGP y otras con varios planos IGP. Para cualquier red dada, bajo cada proceso OSPF, existe de forma predeterminada Flex-Algo 0 con una forma simple de restricción, por ejemplo, la métrica OSPF.

Sin embargo, teniendo en cuenta los requisitos específicos, aquí se utiliza una forma más sofisticada de restricción que incluye parámetros extendidos como TE-metric (los números de Flex-Algo múltiple varían de 128 a 255). En Cisco IOS® XR 7.3.2, esta métrica TE debe configurarse en la sección de ingeniería de tráfico SR-TE, pero OSPF Flex-Algo la utiliza para el cálculo de trayectoria explícita.

TI-LFA calcula la trayectoria de respaldo y mantiene el plano de datos listo en caso de falla de la trayectoria primaria y conmuta el tráfico con un tiempo de convergencia inferior a 50 mseg para una red de escala cero.

Configuración:

OSPF Flex-Algo se configura en el router OSPF y se anuncia a través de la red. La métrica OSPF flex-algo y TE conjuntamente se encargan de la trayectoria explícita y de la convergencia inferior a 50 mseg. La configuración de Flex-Algo en OSPF crea una topología OSPF virtual y ayuda a TI-LFA a calcular de antemano la ruta de respaldo de extremo a extremo para un par de terminales de origen y destino, lo que a su vez garantiza menos de 50 segundos de convergencia para los fallos de la ruta principal.

Configuración OSPF en PE1:

router ospf CORE
 nsr
 distribute link-state
 log adjacency changes
 router-id 11.11.11.11
 segment-routing mpls
 nsf cisco
 microloop avoidance segment-routing
 max-metric router-lsa on-startup 360
 area 0
  interface Bundle-Ether111
   cost 10000 
   authentication null
   network point-to-point
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa enable
   fast-reroute per-prefix tiebreaker node-protecting index 100
   fast-reroute per-prefix tiebreaker srlg-disjoint index 200
   prefix-suppression
  !
  interface Bundle-Ether211
   cost 10000
   authentication null
   network point-to-point
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa enable
   fast-reroute per-prefix tiebreaker node-protecting index 100
   fast-reroute per-prefix tiebreaker srlg-disjoint index 200
   prefix-suppression
  !
  interface Loopback80
   passive enable
   prefix-sid index 32130
   prefix-sid algorithm 128 index 33130     --> Assigning different Node SIDs to different Flex Algo to keep it unique
   prefix-sid algorithm 129 index 34130     --> Assigning different Node SIDs to different Flex Algo to keep it unique
  !
 !
flex-algo 128         --> Defining OSPF Flex Algo which creates a virtual topology and enables TI-LFA to take care of sub 50 msec of convergence
  metric-type te-metric
  advertise-definition
 !
flex-algo 129.       --> One or more than one Flex Algo can be defined based on the requirement
  metric-type delay
  advertise-definition
 !
!

Configuración OSPF en PE3:

router ospf CORE
 nsr
 distribute link-state
 log adjacency changes
 router-id 33.33.33.33
 segment-routing mpls
 nsf cisco
 microloop avoidance segment-routing
 max-metric router-lsa on-startup 360
 area 0
  interface Bundle-Ether111
   cost 10000
   authentication null
   network point-to-point
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa enable
   fast-reroute per-prefix tiebreaker node-protecting index 100
   fast-reroute per-prefix tiebreaker srlg-disjoint index 200
   prefix-suppression
  !
  interface Bundle-Ether211
   cost 10000
   authentication null
   network point-to-point
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa enable
   fast-reroute per-prefix tiebreaker node-protecting index 100
   fast-reroute per-prefix tiebreaker srlg-disjoint index 200
   prefix-suppression
  !
  interface Loopback80
   passive enable
   prefix-sid index 32138
   prefix-sid algorithm 128 index 33138   --> Node SID assigned for OSPF Flex-Algo 128 which is shown above by show command at PE1
   prefix-sid algorithm 129 index 34138   --> Assigning different Node SIDs to different Flex Algo to keep it unique
  !
 !
flex-algo 128.         --> Defining OSPF Flex Algo which creates a virtual topology and enables TI-LFA to take care of sub 50 msec of convergence
  metric-type te-metric --> Metric type te-metric
  advertise-definition  --> To enable the router to advertise the definition for the particular Flexible Algorithm, advertise-definition command is used
 !
flex-algo 129          --> Additional Flex Algo definition (if needed)    
  metric-type delay     --> Metric type delay
  advertise-definition
 !       
!

Resumen de soluciones

En resumen, las métricas de SR-TE ayudan a navegar el tráfico a través de la ruta explícita de SR-TE designada, ya que no se puede utilizar la métrica IGP. OSPF Flex-Algo, al agregar una capa del plano de control virtual, ayuda a TI-LFA a garantizar una convergencia inferior a 50 mseg del tráfico de ruta explícita principal a la ruta de respaldo TI-LFA calculada previamente. Esto sucede ya que solamente se anuncia el SID del nodo de destino para permitir que TI-LFA determine el nodo de destino real y, por lo tanto, proteja ambos nodos intermedios (P1 y P3) entre un par de nodos de origen-destino de la trayectoria primaria explícita PE1> P1 > P3> PE3. La ruta de respaldo protegida dinámicamente que adhiere menos de 50 mseg de convergencia con escala cero, en este caso, es PE1> P2 > P4> PE3.

Software utilizado

El software utilizado para probar y validar la solución es Cisco IOS® XR 7.3.2

Información Relacionada

• Parte 1. Convergencia de SR-TE Explicit-Path para la protección de enlaces
• Soporte técnico y descargas de Cisco