Contents

Introdução

Problema

Requisitos

Por que o caminho de backup TI-LFA não protege nenhuma falha de nó intermediário

Solução

Como o caminho de backup TI-LFA agora protege qualquer falha de nó intermediário sob convergência de 50 ms

Quebrando as etapas da solução

Compreendendo os diferentes componentes da solução

Característica de caminho explícito

OSPF Flex-Algo

Resumo da solução

Software usado

Informações Relacionadas

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

Por que o caminho de backup TI-LFA não protege nenhuma falha de nó intermediário

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:

Como o caminho de backup TI-LFA agora protege qualquer falha de nó intermediário sob convergência de 50 ms

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.

Quebrando as etapas da solução

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