Mecanismo de convergência de caminho explícito baseado em política SR-TE com proteção de nó TI-LFA

Introdução

Este documento descreve a proteção de nó para o caminho primário explícito pelo caminho Topology Independent (TI) - Loop-Free Alternative (LFA) e a solução usando o caminho Segment Routing (SR) - Traffic Engineering (TE) com métrica SR-TE e o algoritmo flexível Open Shortest Path First (OSPF) .

Problema

Esta seção explica os requisitos das redes XYZ, as restrições do projeto e o motivo pelo qual o caminho de backup TI-LFA falha em proteger qualquer falha de nó intermediário para um caminho primário explicitamente definido.

Requisitos

De acordo com a XYZ Networks, estes são os requisitos do projeto de rede inicial:

1. O caminho de tráfego primário deve ser explicitamente definido e controlado pela política SR-TE (admin), mas não pela métrica IGP.

2. Em caso de falha de link ou nó, o tráfego deve convergir para um caminho de backup em menos de 50 ms de tempo com uma rede de escala zero.

Se você observar a Figura 1, uma política de SR-TE foi configurada de ponta a ponta no nó de origem PE1 com PE3 sendo o nó de destino.

As sinopses das configurações de SR-TE e OSPF são:

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
  !
 !

Essa configuração é um método de exemplo para configurar uma política SR-TE orientada por caminho explícito, há outras maneiras também. E no OSPF, observa-se que há TI-LFA habilitado.

No entanto, com a combinação de recursos SR-TE e OSPF, descobriu-se no laboratório com a política de caminho explícito SR-TE que o OSPF TI-LFA não é capaz de fazer curvas e instalar um caminho de backup de ponta a ponta (PE1 a PE3) pós-convergência do caminho primário explícito SR-TE para cenários de falha de nó intermediário, como mostrado na Figura 2. Como resultado, o tempo de convergência da proteção de tráfego excede bem mais de 50 ms caso o nó P1 ou P3 fique inativo.

Um exemplo simples foi escolhido para explicar o problema:

Figura 1: Cenário de tráfego normal

Como na Figura 1, o nó de origem de tráfego é PE1 e o nó de destino é PE3. Aqui, se configurarmos uma política de caminho explícito de SR-TE onde há uma necessidade administrativa de enviar o tráfego através do caminho de tráfego primário explícito PE1> P1> P3> PE3.

Nessa situação, se configurarmos um caminho SR-TE explícito através de PE1> P1 > P3> PE3, em caso de falha de nó, como mostrado na Figura 2., o TI-LFA não pode proteger o cenário de falha de nó, mas pode proteger apenas o cenário de falha de link. O cenário de falha de link foi abordado em detalhes no documento de referência Convergence of SR-TE Explicit-Path for Link Protection.

Figura 2: Cenário de tráfego de failover

Uma vez configurado no OSPF, o TI-LFA, por padrão, aponta para o SID do nó de destino para computar e instalar o caminho de backup no plano de dados.

Mas, para esse cenário e configuração de conjunto de recursos, a cobertura TI-LFA do nó de origem para o nó de destino não funciona ou, em outras palavras, o caminho de backup TI-LFA não protege qualquer falha de nó intermediário abaixo de 50 ms para o caminho primário explicitamente definido.

A análise mostra que o algoritmo de computação do caminho de backup TI-LFA assume o primeiro nó/próximo salto no caminho explícito como o endpoint de destino em vez do nó de destino real e calcula o caminho de backup tentando proteger apenas o primeiro nó/próximo salto, por exemplo, o nó P1, como na Figura 2. Como resultado, o TI-LFA não é capaz de computar e instalar um caminho de backup para proteger o endpoint real ou o nó de destino, por exemplo, o nó PE3.

Portanto, ele não é capaz de fornecer proteção de ponta a ponta em menos de 50 ms de convergência para o nó de destino real PE3 para uma falha de nó intermediário em um caminho de tráfego primário explicitamente definido.

Outra maneira de examinar isso é na Figura 1., se você configurar o nó P3 como o próximo salto no caminho explícito, o TI-LFA poderá fornecer menos de 50 ms de proteção para a falha do nó P1 e vice-versa. Mas a proteção de nó não pode acontecer para esse nó específico que é definido como um dos saltos explícitos do caminho explícito fim-a-fim.

Solução

Esta seção se concentra em pontos para cenários específicos do caminho principal explícito:

Uma solução testada e comprovada é trazer alguns recursos/modificações adicionais ao cenário para permitir que o TI-LFA cuide de menos de 50 ms de convergência durante o cenário de falha de nó, bem como a falha de link. Essa solução foi escolhida com base nos requisitos da rede XYZ conforme mencionado na seção Problema.

1. O caminho explícito é necessário, mas a métrica IGP não pode ser usada de acordo com o requisito.

2. Portanto, uma métrica alternativa (métrica SR-TE) é usada para orientar o tráfego em um determinado caminho sem especificar os saltos explícitos.

3. O Flex-Algo do OSPF é usado para enviar tráfego ao nó de destino (usando um SID de nó do Flex-Algo separado acessível por meio do flex algo) por meio da topologia que usa a métrica SR-TE.

3. Depois que o OSPF Flex-Algo é adicionado, o TI-LFA pode funcionar normalmente, pois agora ele pode proteger o SID do nó de destino real.

Entendendo Diferentes componentes da solução

Característica de caminho explícito

Como de acordo com um dos requisitos a métrica IGP não pode ser usada para controle explícito do caminho principal, a característica dinamizada explícita do caminho SR-TE principal é controlada através da métrica TE configurada adicionalmente sob as interfaces SR-TE (em roteamento de segmento) para todos os nós, incluindo o nó PE do ponto inicial até o PE do destino remoto. Suas métricas de SR-TE são, por sua vez, usadas pelo OSPF Flex Algo para criar um caminho explícito no paradigma flex-algo.

Métrica SR-TE em Roteamento de Segmento em 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 no nó 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

Overview:

O Algoritmo flexível de roteamento de segmento permite que os operadores personalizem a computação de caminho mais curto IGP de acordo com suas próprias necessidades. Um operador pode atribuir SIDs de prefixo SR personalizados para realizar o encaminhamento além do SPF baseado em custo de link. Como resultado, o Algoritmo flexível fornece um caminho de engenharia de tráfego automaticamente computado pelo IGP para qualquer destino alcançável pelo IGP.

Para fornecer flexibilidade máxima, o mapeamento entre o valor do algoritmo e seu significado pode ser definido pelo usuário. Quando todos os roteadores no domínio têm um entendimento comum do que o valor de algoritmo específico representa, a computação para tal algoritmo é consistente e o tráfego não está sujeito a looping. Aqui, como o significado do algoritmo não é definido por nenhum padrão, mas é definido pelo usuário, ele é chamado de Algoritmo flexível.

No paradigma de roteamento OSPF, muitas restrições possíveis podem ser usadas para computar um caminho em uma rede. Algumas redes são implantadas com um único plano IGP e outras com vários planos IGP. Para qualquer rede, sob cada processo OSPF, por padrão, existe o Flex-Algo 0 com uma forma simples de restrição, por exemplo, métrica OSPF.

No entanto, tendo em mente os requisitos específicos, uma forma mais sofisticada de restrição é usada aqui, que inclui parâmetros estendidos como a métrica TE (os números do Multiple Flex-Algo variam de 128 a 255). No Cisco IOS® XR 7.3.2, essa métrica TE deve ser configurada na seção de engenharia de tráfego SR-TE, mas é usada pelo OSPF Flex-Algo para computação de caminho explícito.

O TI-LFA calcula o caminho de backup e mantém o plano de dados pronto em caso de falha do caminho principal e comuta o tráfego com um tempo de convergência inferior a 50 ms para uma rede de escala zero.

Configuração:

O Flex-Algo do OSPF é configurado no OSPF do roteador e anunciado na rede. O flex-algo do OSPF e a métrica TE juntos cuidam do caminho explícito e de convergência abaixo de 50 ms. A configuração do Flex-Algo no OSPF cria uma topologia virtual do OSPF e ajuda o TI-LFA a calcular antecipadamente o caminho de backup de ponta a ponta para um par de endpoints de origem e destino, que, por sua vez, garante menos de 50 segundos de convergência para a falha do caminho principal.

Configuração do OSPF em 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
 !
!

Configuração do OSPF em 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
 !       
!

Resumo da solução

Para resumir, as métricas de SR-TE ajudam a navegar o tráfego pelo caminho explícito designado de SR-TE, já que a métrica IGP não pode ser usada. O Flex-Algo do OSPF, ao adicionar uma camada do plano de controle virtual, ajuda o TI-LFA a garantir uma convergência inferior a 50 ms do tráfego de caminho explícito primário para o caminho de backup pré-calculado do TI-LFA. Isso acontece porque apenas o SID do nó de destino está sendo anunciado para permitir que o TI-LFA determine o nó de destino real e, assim, proteja ambos os nós intermediários (P1 e P3) entre um par de nós de origem-destino do caminho primário explícito PE1> P1 > P3> PE3. O caminho de backup protegido dinamicamente que adere menos de 50 ms de convergência com escala zero, nesse caso, é PE1> P2 > P4> PE3.

Software usado

O software usado para testar e validar a solução é o Cisco IOS® XR 7.3.2

Informações Relacionadas

• Parte 1. Convergência de caminho explícito SR-TE para proteção de link
• Suporte técnico e downloads da Cisco