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

Introduzione

Questo documento descrive il concetto di convergenza con Topology Independent (TI) - LFA (Loop-Free Alternative) che è una funzione altamente mirata. Descrive in dettaglio il meccanismo di convergenza del percorso delle policy di Segment Routing (SR) - Traffic Engineering (TE) con protezione TI-LFA come base di un diagramma della topologia basato sui requisiti delle reti XYZ.

Rilevamento errori di collegamento

Si noti che la convergenza del percorso politico SR-TE e le funzionalità TI-LFA sono indipendenti l'una dall'altra e funzionano separatamente. Tuttavia, la funzione TI-LFA viene aggiunta per effettuare un rapido rilevamento dell'errore del percorso della policy SR-TE principale e di un traffico inferiore a 50 msec che passa al percorso di backup predefinito in condizioni di rete ideali. La politica SR-TE funzionerebbe perfettamente senza TI-LFA, tuttavia, in questo scenario il numero di convergenza dipenderebbe esclusivamente dal protocollo IGP (Interior Gateway Protocol) e sarebbe molto più alto di 50 msec.

Nello scenario di errore del collegamento, il nostro obiettivo è mantenere il più basso possibile il tempo di convergenza, in modo da ridurre al minimo la perdita di pacchetti durante l'evento di link down/flap.

Il rilevamento dell'evento di link down nel nodo dell'headend può essere eseguito principalmente dai seguenti metodi:

1. Rilevamento a livello fisico in caso di collegamenti adiacenti interrotti.

2. Rilevamento da parte del BFD su Bundle in caso di collegamenti remoti interrotti.

Nel primo caso, il rilevamento è più rapido e il tempo di convergenza è inferiore rispetto alla seconda opzione, in cui il rilevamento dipende dalla configurazione del timer di inattività/intervallo BFD e dal punto di rete esatto in cui il collegamento si è interrotto. Tuttavia, un rilevamento molto rapido non significa necessariamente una convergenza rapida, poiché XYZ Org Network è una struttura a più livelli con traffico di servizi end-to-end che copre più hop.

Poiché la rete aziendale XYZ è contenuta all'interno di un singolo dominio BGP AS e IGP, i percorsi di backup predefiniti TI-LFA trasportano immediatamente il traffico di failover dopo un errore di collegamento in tutti gli scenari e assicurano la minima perdita di pacchetti e la copertura completa del prefisso indipendentemente dallo stato della topologia. I percorsi primari e secondari definiti dalla policy SR-TE possono impiegare un po' di tempo per convergere a causa dell'IGP e alla fine assumere il controllo del traffico di servizi end-to-end attraverso il core che può o non può corrispondere ai percorsi predefiniti di TI-LFA.

Scenari dettagliati di convergenza

Per ulteriori dettagli, comprendiamo l'esempio qui riportato che spiega il percorso del traffico con le politiche SR-TE e TI-LFA come meccanismo di convergenza di XYZ Org Network.

Esempio di configurazione SR allineata ai diagrammi topologici:

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

In uno scenario normale, il traffico deve attraversare il percorso da PE1 a PE3 tramite uno dei due possibili percorsi candidati PE1 > P1 > P3 > PE3 e PE1 > P2 > P4 > PE3 del criterio SR-TE, il percorso esplicito primario configurato dall'amministratore con l'elenco adiacente (Adj) - identificatore segmento (SID) 10.1.11.0, 10.1.3.1, 10.3.13.1 o il percorso dinamico secondario determinato dall'IGP interessato. L'amministratore preferisce utilizzare il percorso del candidato primario e solo il fallback al percorso secondario quando il percorso primario è inattivo. Pertanto, al percorso candidato principale viene assegnato un valore di preferenza maggiore che indica un percorso preferito. Ad esempio, il percorso candidato principale può avere una preferenza di 200 e il percorso candidato secondario ha una preferenza di 100.

Figura 1: normale scenario di traffico SR-TE, percorso candidato principale

Qualsiasi percorso candidato viene utilizzato quando è valido e la raggiungibilità dei SID che lo costituiscono determina il criterio di validità.

Quando entrambi i percorsi candidati sono validi e utilizzabili, l'headend PE1 seleziona il percorso di preferenza superiore e installa l'elenco SID di questo percorso 10.1.11.0, 10.1.3.1, 10.3.13.1 nella relativa tabella di inoltro. In qualsiasi momento, il traffico di servizio indirizzato in questa policy SR viene inviato solo sul percorso selezionato, mentre gli altri percorsi candidati dinamici sono inattivi.

Un percorso candidato viene selezionato quando ha il valore di preferenza più alto tra tutti i percorsi candidati validi del criterio SR. Il percorso scelto è anche definito "percorso attivo" della politica della SR.

Convergenza errori di collegamento - Il percorso primario passa allo stato inattivo

A un certo punto, nella rete può verificarsi un errore di collegamento. Il collegamento non riuscito può essere un collegamento tra due nodi qualsiasi, ad esempio P1 e P3. Non appena il guasto viene rilevato con uno dei mezzi descritti all'inizio della sezione, la protezione TI-LFA deve garantire che i flussi di traffico vengano rapidamente reindirizzati al percorso di protezione TI-LFA, idealmente entro 50 msec.

Notare che in questo scenario, il percorso di backup determinato da TI-LFA, come mostrato nella Figura 2., è diverso dal percorso dei criteri di backup infine convergente determinato da IGP nella Figura 3. Questo è abbastanza normale in quanto il percorso di backup Ti-LFA è determinato localmente dal nodo del punto di riparazione locale (PLR) in cui si è verificato il guasto. Tuttavia, il percorso di backup ottimizzato della regola SR-TE è determinato dalla convergenza IGP del nodo headend che detiene le decisioni della policy SR-TE.

Figura 2: Scenario di traffico di failover tramite percorso di backup TI-LFA

Il traffico continua a scorrere attraverso il percorso di protezione TI-LFA fino a quando, alla fine, l'headend PE1 viene a sapere tramite flooding IGP che il SID 10.1.3.1 del collegamento non riuscito non è più valido. PE1 valuta quindi la validità dell'elenco di SID del percorso  10.1.11.0, 10.1.3.1, 10.3.13.1 e la invalida a causa della presenza del SID non valido 10.1.3.1. Contemporaneamente invalida il percorso candidato e riesegue il processo di selezione del percorso della policy SR-TE. PE1, successivamente, seleziona un altro percorso candidato valido con il valore di preferenza più alto successivo e installa l'elenco SID  10.2.11.0, 10.2.4.1, 10.4.13.1 del nuovo percorso candidato secondario nella tabella di inoltro. Tuttavia, questo percorso candidato secondario è di natura dinamica, determinato da IGP Open Shortest Path First (OSPF), e non ha alcun controllo amministrativo. Fino a questo punto, il traffico passa attraverso il percorso protetto TI-LFA, ma dopo questo, viene indirizzato sul nuovo percorso secondario preferito della policy SR-TE.

Figura 3: Scenario di traffico di failover tramite percorso candidato secondario SR-TE

Passi di riepilogo:

1. In caso di guasto:

• Layer1/BFD segnala il percorso primario verso il basso a FIB
• FIB esegue il push a HW del percorso di backup stabilito con TI-LFA
• Interruzione del traffico prevista:
  • Collegamento non attivo: circa 50 ms
  • Perdita peer BFD: tempo morto BFD + ~50 ms
• Peering OSPF su collegamento perso non più disponibile

2. Tutti i router OSPF del dominio vengono a conoscenza della perdita di SID tramite flooding LSA (Link State Advertisement)

3. Headend PE1 SR-TE:

• Convergenze OSPF
• Criterio SR-TE L'elenco dei SID del percorso primario viene invalidato
• Il percorso del candidato principale è inattivo
• L'elenco SID del percorso secondario del candidato viene convalidato e diventa attivo
• Il traffico viene inviato tramite un percorso secondario senza alcuna perdita di traffico del servizio

Riconvergenza errori collegamento - Ripristino stato attivo percorso primario

Nel frattempo, una volta ripristinato il collegamento primario non riuscito, il percorso primario originale con preferenza (200) diventa nuovamente valido e quindi l'headend PE1 esegue la procedura di selezione del percorso dei criteri SR-TE, seleziona il percorso candidato esplicito valido con la preferenza più alta e aggiorna la relativa tabella di inoltro con l'elenco SID del percorso primario originale. Il traffico di servizio indirizzato in questo criterio SR viene nuovamente inviato sul percorso originalePE1 > P1 > P3 > PE3.

Figura 4: Scenario di riconversione del traffico

Passi di riepilogo:

1. Il layer 1/BFD segnala il backup del percorso primario e l'OSPF riceve la notifica.

2. Il traffico viene comunque inoltrato attraverso il percorso candidato per il backup delle policy SR-TE.

3. Dopo qualche tempo, l'elenco SID del percorso candidato principale dei criteri SR-TE diventa valido tramite flooding LSA OSPF.

4. Il traffico viene commutato dal percorso del candidato per il backup delle policy SR-TE al percorso del candidato principale delle policy SR-TE con nessuna perdita di traffico.

In conclusione, questi scenari forniscono una spiegazione teorica del processo di convergenza e dei numeri di convergenza ideali; tuttavia, è necessario testare i numeri di convergenza effettivi in laboratorio che imitano il più possibile la rete di produzione e la configurazione e attivano diversi punti di errore nella rete che si possono prevedere.

Attenzione: in questo documento vengono illustrati solo gli scenari di Protezione collegamento, poiché Protezione nodo non funziona con i percorsi espliciti SR-TE se il percorso esplicito definito tocca nodi intermedi. Questo perché TI-LFA considera ogni hop intermedio configurato come nodo di destinazione e, in caso di errore di uno di questi hop, non è in grado di risolvere la destinazione finale. Si tratta di una limitazione della tecnologia e non è limitata a nessuna versione di piattaforme o immagini. La soluzione per questa limitazione è stata discussa nella parte 2 del presente documento come indicato nella sezione Informazioni correlate.

Software utilizzato

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

Informazioni correlate

• Parte 2. Meccanismo di convergenza di SR-TE Policy-based Explicit-Path con TI-LFA Node Protection
• Supporto tecnico Cisco e download