Meccanismo di convergenza di SR-TE Policy-based Explicit-Path con TI-LFA Node Protection

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

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:

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.

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