Sommario

Introduzione

Problema

Requisiti

Motivi per cui il percorso di backup TI-LFA non è in grado di proteggere gli errori intermedi dei nodi

Soluzione

Come il percorso di backup TI-LFA protegge i guasti intermedi dei nodi con una convergenza inferiore a 50 msec

Suddivisione dei passaggi della soluzione

Informazioni sui diversi componenti della soluzione

Caratteristica percorso esplicito

OSPF Flex-Algo

Riepilogo della soluzione

Software utilizzato

Informazioni correlate

Introduzione

In questo documento viene descritta la protezione dei nodi per il percorso primario esplicito in base a Topology Independent (TI) - Loop-Free Alternative (LFA) e alla soluzione che utilizza Segment Routing (SR) - Traffic Engineering (TE) percorso con metrica SR-TE e algoritmo flessibile OSPF (Open Shortest Path First).

Problema

In questa sezione vengono illustrati i requisiti delle reti XYZ, i vincoli di progettazione e il motivo per cui il percorso di backup TI-LFA non è in grado di proteggere eventuali errori dei nodi intermedi per un percorso primario definito in modo esplicito.

Requisiti

Come per le reti XYZ, questi sono i requisiti per la progettazione di una rete "green field":

1. Il percorso del traffico primario deve essere definito e controllato esplicitamente dalla policy SR-TE (admin) ma non dalla metrica IGP.

2. In caso di errore del collegamento o del nodo, il traffico deve convergere in un percorso di backup in meno di 50 msec di tempo con una rete di scala zero.

Se si esamina la Figura 1., è stata configurata una regola SR-TE end-to-end nel nodo di origine PE1 con PE3 come nodo di destinazione.

Di seguito è riportata una sintesi delle configurazioni di SR-TE e OSPF.

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

!

!

Questa configurazione è un metodo di esempio per configurare un criterio SR-TE basato su percorso esplicito. Sono disponibili anche altri metodi. E sotto OSPF, si osserva che c'è TI-LFA abilitato.

Tuttavia, grazie alla combinazione di funzionalità SR-TE e OSPF, in laboratorio con SR-TE Explicit Path Policy è possibile riscontrare che OSPF TI-LFA non è in grado di curvare e installare un percorso di backup end-to-end (da PE1 a PE3) post-convergenza del percorso primario esplicito di SR-TE per scenari di guasto di nodi intermedi, come mostrato nella Figura 2. Di conseguenza, il tempo di convergenza della protezione del traffico supera ampiamente i 50 msec nel caso in cui il nodo P1 o P3 diventi inattivo.

È stato scelto un semplice esempio per spiegare il problema:

Figura 1: scenario di traffico normale

Come nella Figura 1., il nodo di origine del traffico è PE1 e il nodo di destinazione è PE3. Se si configura un criterio di percorso esplicito SR-TE in cui è necessario che l'amministratore invii il traffico tramite il percorso di traffico primario esplicito PE1> P1> P3> PE3.

In questa situazione, se si configura un percorso SR-TE esplicito tramite PE1> P1 > P3> PE3, in caso di errore del nodo, come mostrato nella Figura 2., TI-LFA non è in grado di proteggere lo scenario di errore del nodo, ma è in grado di proteggere solo lo scenario di errore del collegamento. Lo scenario di errore del collegamento è stato descritto in dettaglio nel documento di riferimento Convergence of SR-TE Explicit-Path for Link Protection.

Figura 2: Scenario di traffico di failover

Motivi per cui il percorso di backup TI-LFA non è in grado di proteggere gli errori intermedi dei nodi

TI-LFA una volta configurato in OSPF, per impostazione predefinita punta al SID del nodo di destinazione per calcolare e installare il percorso di backup nel piano dati.

In questo scenario e in questa configurazione del set di funzionalità, tuttavia, la copertura TI-LFA dal nodo di origine al nodo di destinazione non funziona. In altre parole, il percorso di backup TI-LFA non è in grado di proteggere eventuali errori del nodo intermedio inferiori a 50 msec per il percorso primario definito in modo esplicito.

L'analisi mostra che l'algoritmo di calcolo del percorso di backup TI-LFA considera il primo hop/nodo successivo nel percorso esplicito come endpoint di destinazione anziché come nodo di destinazione effettivo e calcola il percorso di backup cercando di proteggere solo il primo hop/nodo successivo, ad esempio il nodo P1 come illustrato nella Figura 2. Di conseguenza, TI-LFA non è in grado di calcolare e installare un percorso di backup per proteggere l'endpoint o il nodo di destinazione effettivo, ad esempio il nodo PE3.

Pertanto, non è in grado di fornire protezione end-to-end entro meno di 50 msec di convergenza per il nodo di destinazione effettivo PE3 per un errore del nodo intermedio in un percorso di traffico primario definito in modo esplicito.

Un altro modo per esaminarlo è nella Figura 1., se si configura il nodo P3 come hop successivo nel percorso esplicito, TI-LFA può fornire una protezione inferiore a 50 msec per l'errore del nodo P1 e viceversa. La protezione dei nodi non può tuttavia essere applicata a un nodo specifico definito come uno degli hop espliciti del percorso esplicito end-to-end.

Soluzione

In questa sezione vengono illustrati i punti da utilizzare negli scenari espliciti specifici del percorso principale:

Come il percorso di backup TI-LFA protegge i guasti intermedi dei nodi con una convergenza inferiore a 50 msec

Una soluzione collaudata e collaudata consiste nell'apportare alcune funzionalità/modifiche aggiuntive allo scenario in modo da consentire a TI-LFA di occuparsi della convergenza inferiore a 50 msec durante lo scenario di guasto del nodo e il guasto del collegamento. Questa soluzione è stata scelta in base ai requisiti di rete XYZ indicati nella sezione Problema.

Suddivisione dei passaggi della soluzione

1. Explicit-Path è necessario, ma la metrica IGP non può essere utilizzata come da requisito.

2. Pertanto, viene utilizzata una metrica alternativa (metrica SR-TE) per indirizzare il traffico su un determinato percorso senza specificare gli hop espliciti.

3. OSPF Flex-Algo viene utilizzato per inviare il traffico al nodo di destinazione (utilizzando un SID del nodo Flex-Algo separato raggiungibile tramite l'algo flessibile) tramite la topologia che utilizza la metrica SR-TE.

3. Dopo l'aggiunta di OSPF Flex-Algo, TI-LFA è in grado di funzionare normalmente in quanto ora può proteggere il SID del nodo di destinazione effettivo.

Informazioni Diversi componenti della soluzione

Caratteristica percorso esplicito

Poiché in base a uno dei requisiti la metrica IGP non può essere utilizzata per il controllo esplicito del percorso principale, la caratteristica semplificata esplicita del percorso SR-TE principale viene controllata tramite la metrica TE configurata in modo aggiuntivo nelle interfacce SR-TE (sotto il routing dei segmenti) per tutti i nodi, compreso il nodo PE dell'headend, fino alla destinazione remota PE. Le relative metriche SR-TE vengono a loro volta utilizzate da OSPF Flex Algo per creare un percorso esplicito nel paradigma flex-algo.

Metrica SR-TE in Routing segmento in 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

!

!

Mostra comando nel 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

Panoramica:

Segment Routing Flexible Algorithm consente agli operatori di personalizzare il calcolo IGP del percorso più breve in base alle proprie esigenze. L'operatore può assegnare SID di prefissi SR personalizzati per realizzare l'inoltro oltre l'SPF basato sui costi di collegamento. Di conseguenza, Flexible Algorithm fornisce un percorso progettato per il traffico calcolato automaticamente dall'IGP verso qualsiasi destinazione raggiungibile dall'IGP.

Per garantire la massima flessibilità, il mapping tra il valore dell'algoritmo e il relativo significato può essere definito dall'utente. Quando tutti i router del dominio hanno una concezione comune di ciò che rappresenta il particolare valore dell'algoritmo, il calcolo di tale algoritmo è coerente e il traffico non è soggetto a loop. In questo caso, poiché il significato dell'algoritmo non è definito da alcuno standard, ma è definito dall'utente, viene definito algoritmo flessibile.

Con il paradigma di routing OSPF, è possibile utilizzare molti vincoli possibili per calcolare un percorso su una rete. Alcune reti sono distribuite con un singolo piano IGP e altre con più piani IGP. Per impostazione predefinita, in ogni processo OSPF di una determinata rete è presente Flex-Algo 0 con una forma semplice di vincolo, ad esempio la metrica OSPF.

Tuttavia, tenendo presenti i requisiti specifici, viene utilizzata una forma di vincolo più sofisticata che include parametri estesi come TE-metric (i numeri di Flex-Algo multipli vanno da 128 a 255). In Cisco IOS® XR 7.3.2, questa metrica TE deve essere configurata nella sezione ingegneria del traffico SR-TE ma viene utilizzata da OSPF Flex-Algo per il calcolo a percorso esplicito.

TI-LFA calcola il percorso di backup e tiene il piano dati pronto in caso di errore del percorso primario e commuta il traffico con un tempo di convergenza inferiore a 50 msec per una rete a scalabilità zero.

Configurazione:

OSPF Flex-Algo è configurato nel router OSPF e annunciato attraverso la rete. Il flex-algo OSPF e le metriche TE insieme gestiscono il percorso esplicito e i valori al di sotto dei 50 msec di convergenza. La configurazione di Flex-Algo in OSPF crea una topologia OSPF virtuale e consente a TI-LFA di calcolare in anticipo il percorso di backup end-to-end per una coppia di endpoint origine-destinazione, garantendo a sua volta meno di 50 secondi di convergenza per il guasto del percorso primario.

Configurazione OSPF in 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

!

!

Configurazione OSPF in 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

!

!

Riepilogo della soluzione

Per riepilogare, le metriche SR-TE facilitano la navigazione del traffico attraverso il percorso esplicito SR-TE designato, poiché non è possibile utilizzare la metrica IGP. Grazie all'aggiunta di un layer del control plane virtuale, OSPF Flex-Algo consente a TI-LFA di garantire una convergenza inferiore a 50 msec del traffico primario a percorso esplicito con il percorso di backup TI-LFA precalcolato. Questo avviene perché solo il SID del nodo di destinazione viene annunciato per consentire a TI-LFA di determinare il nodo di destinazione effettivo e quindi proteggere entrambi i nodi intermedi (P1 e P3) tra una coppia di nodi di origine e destinazione del percorso primario esplicito PE1> P1 > P3> PE3. Il percorso di backup protetto in modo dinamico che rispetta meno di 50 msec di convergenza con scala zero, in questo caso, è PE1> P2 > P4> PE3.

Software utilizzato

Il software utilizzato per testare e convalidare la soluzione è Cisco IOS® XR 7.3.2

Informazioni correlate

- Parte 1. Convergenza di SR-TE Explicit-Path per la protezione del collegamento

- Supporto tecnico Cisco e download