Segment Routing: Parte II - Lab Test

Nel post precedente sul Segment Routing, ho trattato la "teoria", ossia i principi di funzionamento. In questo post voglio illustrare, nell'ottica del "learning by doing", un test di laboratorio, e utilizzando i risultati, dare qualche informazione in più sulla teoria.

Il test è stato realizzato utilizzando piattaforme Cisco basate su IOS XR. In realtà ho utilizzato, come già altre volte in questo blog, l'ambiente virtuale VIRL. Mi sarebbe piaciuto metter su una rete mista Cisco-Juniper, ma con gli strumenti che ho al momento a disposizione non è stato possibile.  

TOPOLOGIA DELLA RETE E PIANO DI NUMERAZIONE

La topologia che utilizzerò è riassunta nella figura seguente.

I router P e PE utilizzano l'IOS XR, versione 6.0.0, e i due router CE utilizzano un semplice IOS versione 15.6(2)T. Il dominio di routing SR è costituito dai soli router P e PE, i router CE li utilizzerò solo per mostrare un servizio L3VPN. Gli indirizzi IP delle interfacce Loopback0 dei vari router sono i seguenti:

• Router Px (x = 1, 2, ...,4): 192.168.1.x/32;
• Router PEx (x = 5, 6): 192.168.0.x/32;
• Router CEx (x = 5, 6) : 10.1.99.xx/32.

I collegamenti punto-punto hanno il seguente piano di indirizzamento:

• Collegamenti P/PE(x) - P/PE(y) : 10.1.xy.0/24;
• Collegamento P1-P4 tra Gi0/0//0/4-Gi0/0//0/4 : 10.2.14.0/24.
• Collegamenti PEx-CEx : 10.1.xx.0/24

Tutte le interfacce dei router P/PEx terminano con ".x", mentre le interfacce dei router CEx terminano con ".xx".

Come protocollo di routing ho utilizzato IS-IS (potevo fare altrimenti ?), senza partizione in aree, ma solo con un unico Livello 2. I valori di NET utilizzati hanno il formato 49.0001.SyS-ID.00. I SyS-ID sono stati derivati a partire dagli indirizzi IP delle interfacce Loopback0, con un trucchetto che chi ha letto il mio libro su IS-IS conosce bene (è tutto scritto nel Capitolo 3, sez. 3.7.3). Tutte le metriche delle interfacce sono lasciate al loro valore di default pari a 10.

Il test utilizza il blocco SRGB di default dell'IOS XR Cisco, che ha base 16.000 e ampiezza 8.000. Questo blocco, anche se non è buona pratica, può essere in realtà variato con il comando:

router isis NOME-ISTANZA IS-IS
  segment-routing global-block base base+range

Ad esempio, qualora si volesse utilizzare per un determinato router, dove è attiva l'istanza IS-IS TT, il SRGB [base, range] = [22.000, 2.000], la configurazione da eseguire è la seguente (NOTA: questo comando non è al momento supportato dalla versione VIRL a mia disposizione; come ho già detto è comunque meglio evitarlo):

router isis TT
  segment-routing global-block 22000 23999

La verifica del blocco effettivamente utilizzato può essere fatta con il comando "show mpls label table detail":

CONFIGURAZIONI BASE
Un aspetto importante della configurazione di IS-IS per l'utilizzo con il Segment Routing, è che è necessario abilitare le metriche estese (wide style). Inoltre, come passo preliminare, è necessario pianificare con cura i vari Node-SID. Ricordo che non è necessario pianificare alcunché per le adiacenze, essendo queste segmenti locali. La regola utilizzata per i Node-SID è la seguente:

• Node-SID router Px = xx
• Node-SID router PEx = x.

Ad esempio, il router PE6 avrà Node-SID = 6, per cui la sua etichetta globale sarà 16.000 (base del SRGB) + 6 = 16.006.

Riporto per brevità la sola configurazione base di IS-IS per il router PE5, le altre sono analoghe: 

router isis TT
  is-type level-2-only
  net 49.0001.1921.6800.0005.00
  address-family ipv4 unicast
    metric-style wide
    segment-routing mpls
  !
  interface Loopback0
    passive 
    address-family ipv4 unicast
      prefix-sid index 5
    !
  !
  interface Gi0/0/0/0
    point-to-point
    address-family ipv4 unicast
      fast-reroute per-prefix
    !
  !
  interface Gi0/0/0/1
    point-to-point
    address-family ipv4 unicast
      fast-reroute per-prefix
    !
  !
! 

Le configurazioni indispensabili per attivare il SR sono quelle sottolineate, tutto il resto è "ordinaria amministrazione" (NOTA: il comando "fast-reroute per-prefix" abilita il per-prefix LFA; non è indispensabile per il SR, ma visto che già era presente in una configurazione precedente, l'ho lasciato. Se volete saperne di più sul LFA (Loop free Alternate), leggetevi il Capitolo 10 del libro su IS-IS, dove è trattato ampiamente). 

Su questo dominio SR, ho quindi creato una L3VPN tra i due router CE5 e CE6, utilizzando configurazioni "ordinarie" sui router PE5 e PE6. Vorrei far notare che su questa rete non ho configurato né LDP né RSVP-TE. I LSP di collegamento tra i due PE sono realizzati automaticamente dalle configurazioni del SR. 

Non ci resta ora che verificare il funzionamento.

VERIFICA DEL FUNZIONAMENTO

NOTA: tutti i risultati dei vari comandi di verifica mostrati nel seguito, e anche quello mostrato sopra, sono il risultato di snapshot eseguiti direttamente sui risultati del VIRL.

Se quanto descritto nel post precedente sulla "teoria" fosse corretto, un semplice traceroute dal router PE5 all'interfaccia Loopback0 del router PE6 (= 192.168.0.6), dovrebbe mostrare un percorso con la sola etichetta 16.006 (perché ?), a parte l'ultimo tratto, dove è attivo il Penultimate Hop Popping (PHP): 

E in effetti è così. Il percorso seguito è uno dei percorsi IGP a costo minimo disponibili (ve ne sono 4, come potete facilmente verificare). In particolare è stato scelto il percorso IGP PE5 --> P1 --> P4 --> PE6. Tra i router P1 e P4, dei due link disponibili è stato scelto quello che ha interfaccia uscente (da P1) Gi0/0/0/3.  

Vediamo ora invece il traceroute CE-CE, dove come estremi ho utilizzato gli indirizzi IP delle due interfacce Loopback0:

Come si può notare, oltre all'etichetta esterna 16.006 (che qui gioca il ruolo di transport label), compare anche la service label 24.000. Questa, come noto, è l'etichetta associata da PE6 al prefisso VPN 10.1.99.66/32, e comunicata via MP-BGP da PE6 a PE5, come risulta dal seguente comando "show ...": 

La tabella di forwarding MPLS di P1, che si trova sul percorso ottimo IGP verso il BGP Next-Hop (= Loopback 0 di PE6 = 192.168.0.6) mostra l'operazione di label swapping eseguita da P1: Come si può notare, in corrispondenza all'etichetta 16.006 (etichetta entrante), P1 utilizza in uscita lo stesso valore dell'etichetta entrante, come c'era da aspettarsi, considerato che l'etichetta 16.006 è globale.

Il perché della presenza di tre righe (con tre diversi Next-Hop) in corrispondenza dell'etichetta entrante 16.006 è semplice, e vi lascio per esercizio la spiegazione. Si noti che sotto la colonna "Prefix or ID" è riportato che l'etichetta MPLS è associata a un segmento SR di tipo Prefix (SR Pfx), ed è anche riportato il Node-SID (idx 6).

Tutto sembra funzionare regolarmente. Si noti che sulla rete test non ho configurato LDP in nessun router e né RSVP-TE, quindi ho risparmiato un protocollo (con tutto ciò che ne consegue in termini di semplicità di configurazione, funzionamento e troubleshooting). Tutto il resto è ordinario. 

Per concludere manca però un aspetto importante, vedere come IS-IS annuncia le etichette MPLS. Questo è un aspetto trattato nel draft IETF "draft-ietf-isis-segment-routing-extensions", che merita una sezione a parte.

VERIFICA DEL LSDB IS-IS
Le etichette MPLS, sia locali che globali, vengono annunciate dai vari router mediante una estensione dei protocolli IGP (IS-IS e OSPF). Nel caso di IS-IS le estensioni sono definite nel draft IETF citato sopra. 

Come noto a chi è familiare con IS-IS (se non lo siete, avete due alternative, o saltare questa sezione, oppure studiarvi il libro che vi ho propinato a puntate in questo blog, in particolare il Capitolo 6), aggiungere nuove funzionalità a IS-IS equivale a definire nuovi moduli di tipo TLV (Type-Length-Value) o sub-TLV, ossia sotto-moduli da aggiungere ai moduli TLV.  

Prima di dare un cenno a questi nuovi moduli, vi riporto di seguito il dettaglio del LSP IS-IS generato dal router P2 (NOTA: ho scelto questo LSP per brevità, non per una particolare ragione. Gli altri hanno una struttura molto simile, a parte ovviamente il numero di adiacenze riportato). Il dettaglio è visualizzato sul router PE5, ma questo è un dettaglio assolutamente ininfluente, la visualizzazione poteva essere effettuata su un qualsiasi altro router, ottenendo lo stesso identico risultato (il perché lo sapete benissimo !).  

Le informazioni aggiuntive relative al funzionamento del SR sono quelle evidenziate nei riquadri tratteggiati. Partendo dall'alto, nel primo riquadro sono evidenziati i parametri del SRGB: base = 16.000, range = 8.000. Sono inoltre evidenziate due flag:

• flag I (MPLS IPv4 flag): I = 1 indica che il router (in questo caso P2) è in grado di elaborare su tutte le sue interfacce, pacchetti MPLS che trasportano pacchetti IPv4.
• flag V (MPLS IPv6 flag): V = 1 indica che il router (in questo caso P2) è in grado di elaborare su tutte le sue interfacce, pacchetti MPLS che trasportano pacchetti IPv6.

Il secondo riquadro riguarda gli annunci di segmenti di tipi IGP-adjacency. Per ciascuna adiacenza IS-IS (in particolare il router P2 ne ha tre), l'IOS XR annuncia due diversi segmenti di tipo IGP-Adjacency, che differiscono per il valore dell'etichetta e per il valore della flag B. Ciascun annuncio di questo tipo è costituito da 5 flag (F, B, V, L, S), un peso (weight) e l'etichetta MPLS (Adjacency-sid). Le flag hanno il seguente significato:

• flag F (Address-Family flag): indica che il valore dell'etichetta è associato a un'adiacenza IS-IS per IPv4 se F = 0, a un'adiacenza per IPv6 se F = 1.
• flag B (Backup flag): B = 1 indica che l'adiacenza IS-IS può essere utilizzata per la protezione del traffico (ad esempio attraverso meccanismi come LFA o MPLS-TE FRR; per i dettagli vedi questo draft IETF).  
• flag V (Value flag): V = 1 indica che l'annuncio contiene un valore di etichetta. Di default è sempre V = 1.
• flag L (Local flag): L = 1 indica che il valore di etichetta associato ha significato locale. Di default, per gli annunci di segmenti di tipo IGP-Adjacency, è sempre L = 1.
• flag S (Set flag): S = 1 indica che il valore di etichetta è associato a un insieme di adiacenze (e quindi è possibile per il router assegnarlo anche ad alte adiacenze).

Il valore weight, di lunghezza 1 byte, viene utilizzato nel caso di adiacenze parallele che hanno associato lo stesso valore di etichetta, per ottimizzare il load balancing del traffico tra le adiacenze. I valori weight, uno per ciascuna adiacenza, definiscono la frazione di traffico totale che il router invia sulle singole adiacenze. Ad esempio, supponiamo il caso dei router P1 e P4 della rete test, e supponiamo che alle due adiacenze parallele tra loro, il router P1 associ lo stesso valore di etichetta 24.000, e che i valori di weight siano rispettivamente 1 e 2. Il router P1 annuncerà quindi due segmenti di tipo IGP-Adjacency, entrambi con etichetta associata 24.000 e con weight rispettivamente 1 e 2. I router di ingresso al dominio SR, o un eventuale controller SDN, verranno così a conoscenza del fatto che, utilizzando il valore di etichetta 24.000, P1 bilancerà il traffico sui due link dove si formano le due adiacenze, nel rapporto 1:2. 

Solo per curiosità e completezza, vi riporto il formato della sub-TLV "Adjacency Segment Identifier (Adj-SID)", che IS-IS aggiunge a svariati moduli TLV che non sto qui ad elencare (le figure sono tratte dal draft IETF citato sopra "draft-ietf-isis-segment-routing-extensions").

 con il campo Flags che ha il formato seguente:

L'ultimo riquadro tratteggiato riguarda l'annuncio del segmento di tipo IGP-node. Ciascun annuncio di questo tipo è costituito dal valore di Node-SID (Prefix-SID Index:), un valore sul cui significato glisso perché non importante (Algorithm:) e 6 flag (R, N, P, E, V, L). Vi riporto solo l'utilizzo delle flag più significative:

• flag N (Node-SID flag): se N = 1, il valore di SID si riferisce a un nodo (che ricordo è un caso particolare . Tipicamente la flag N viene posta a 1 nell'annuncio degli indirizzi IP /32 (o /128 nel caso IPv6) associati a interfacce di Loopback. 
• flag P (no-PHP flag): va letta un po' al contrario, se P = 0 il penultimo nodo del percorso esegue l'operazione di Penultimate Hop Popping, altrimenti no. E' possibile anche far eseguire l'operazione di Explicit-null label, ponendo a 1 sia la flag P che la flag E. 
• flag V (Value flag): stesso identico utilizzo visto sopra per gli annunci di segmenti di tipo IGP-Adjacency.
• flag L (Local flag): stesso identico utilizzo visto sopra per gli annunci di segmenti di tipo IGP-Adjacency, con la differenza che in questo caso il default è L = 0 poiché i segmenti di tipo Node-SID sono globali.

Anche qui, solo per curiosità e completezza, vi riporto il formato della sub-TLV "Prefix-SID" (di cui i segmenti di tipo Node-SID sono un caso particolare), che IS-IS aggiunge a svariati moduli TLV che non sto qui ad elencare (le figure sono tratte dal draft IETF citato sopra "draft-ietf-isis-segment-routing-extensions").

con il campo Flags che ha il formato seguente:

CONCLUSIONI

Dopo il primo post sulla teoria, in questo ho illustrato un esempio pratico di applicazione del Segment Routing, utilizzando un test di Laboratorio con apparati basati sull'IOS XR Cisco. Tornerò in seguito su questo interessante nuovo paradigma di routing. Nel prossimo post sull'argomento cercherò di illustrare come il Segment Routing si integra con il protocollo PCEP trattato in questo post.

Se volete saperne di più su MPLS, da zero all'infinito, oppure avete bisogno di ulteriori approfondimenti, seguite i nostri molti corsi sull'argomento, tra cui vi segnalo: 

• IPN272: MPLS: dalla teoria alla Pratica
• IPN273: MPLS: aspetti avanzati
• IPN276: MPLS nell’IOS XR Cisco
• IPN258: MPLS nel JunOS Juniper

E se volete un qualcosa di molto più completo, seguite l'intero percorso per la certificazione Cisco CCNP - SP (CCNP - Service Provider).