sabato 21 marzo 2020

Seamless MPLS e “piccole variazioni sul tema” – parte II

Questa è la seconda parte del post su Seamless MPLS scritto dal mio amico Marco SERRA, brillante e appassionato networker, con grande esperienza teorica e pratica su MPLS e dintorni, maturata su reti in produzione. La prima parte la trovate qui.

*************
Ben ritrovati su Reissblog.

Nel post precedente ho parlato di reti di grandi dimensioni e descritto una soluzione per progettare un’infrastruttura di rete a pacchetto molto scalabile, nota come Seamless MPLS. È l’ora di passare dalla teoria alla pratica.  Ogni tanto però mi dovete concedere qualche richiamo teorico, anche per giustificare le configurazioni di router che di seguito troverete.

Il post è suddiviso in quattro sezioni. Nelle prime due introdurrò due possibili tecniche di partizione della rete in domini IGP isolati, unico Autonomous System. Seguirà una terza sezione con la quale entrerò nei dettagli implementativi di una rete Seamless MPLS di laboratorio. Infine, nell’ultima sezione descriverò una terza tecnica anch’essa molto interessante.

Ciò premesso … si inizia!

Il protocollo di routing IGP che sarà considerato, per tutti i discorsi che seguiranno in questo post, è IS-IS. Per chi avesse bisogno di ripassarne i principi, di studiarlo oppure approfondirlo può utilizzare il libro scritto da Tiziano Tofoni, dal titolo “IS-IS: dalla teoria alla pratica”, che potete scaricare gratuitamente in questo blog a questo link.

Per descrivere le prime due tecniche di partizione utilizzerò una stessa topologia di rete, pensata ad hoc solo per fare delle considerazioni di natura IGP. 

Tecnica N.1 - partizione della rete e utilizzo di un singolo processo IS-IS nei Border Node 



La rete in figura è stata suddivisa in due aree IS-IS. Facendo un’attenta disamina dello schema noterete che i router SN-5, SN-6, SN-7, SN-8 sono Intermediate-System (IS) di tipo L1, i router BN-1, BN-2, BN-3, BN-4 sono IS di tipo L1/L2 e vi sarete anche accorti che per ogni interfaccia fisica dei BN è stato specificato il livello (circuit-type level-1 oppure circuit-type level-2-only) sul quale si può stabilire l’adiacenza topologica. L’interfaccia logica Loopback0 dei Border Node (BN) non stabilisce adiacenze e il circuit-type è lasciato di proposito al tipo di default (circuit-type level-1-2) per un motivo che sarà spiegato a breve. 

Di seguito la configurazione del processo IS-IS per i router SN-5, BN-1:

Router SN-5:
router isis 64530
 is-type level-1
 net 49.0111.0100.2003.0005.00
 address-family ipv4 unicast
  metric-style wide
  attached-bit receive ignore
 !
 interface Loopback0
  passive
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/0
  point-to-point
  address-family ipv4 unicast
   metric 100
 
Router BN-1:
route-policy DROP-L1-TO-L2
  drop
end-policy
!
router isis 64530
 net 49.0111.0100.2003.0001.00
 address-family ipv4 unicast
  metric-style wide
  propagate level 1 into level 2 route-policy DROP-L1-TO-L2
 !
 interface Loopback0
  passive
  address-family ipv4 unicast
  !
 !
 interface GigabitEthernet0/0/0/0
  circuit-type level-2-only
  point-to-point
  address-family ipv4 unicast
   metric 100
  !
 !
 interface GigabitEthernet0/0/0/1
  circuit-type level-1
  point-to-point
  address-family ipv4 unicast
   metric 100
  !
 !
 interface GigabitEthernet0/0/0/2
  circuit-type level-2-only
  point-to-point
  address-family ipv4 unicast
   metric 100
 
Le configurazioni dei router SN-6, SN-7, SN-8 hanno una struttura analoga a quella di SN-5, mentre quelle dei router BN-2, BN-3, BN-4 hanno una struttura analoga a quella del router BN-1 (cambiano solo gli aspetti numerici e le interfacce che partecipano al processo di routing).

Alcune osservazioni:
  1. Come noto le aree IS-IS sono assimilabili ad aree OSPF di tipo Totally-Not-So-Stubby con propagazione unidirezionale di informazioni di routing, dalla topologia L1 alla topologia L2. La route-policy DROP-L1-TO-L2, applicata nel processo IS-IS dei BN, scarta queste informazioni di routing. [NOTA: dal punto di vista pratico, nel Link State DataBase (LSDB) L1 dei router BN-1 BN-2 troviamo in particolare i prefissi originati dai router SN-5 e SN-6; l’applicazione della route-policy comporta che tali prefissi non possano essere diffusi e quindi comparire nel LSDB L2 dei router BN-3 e BN-4. Osservazioni analoghe si possono fare per i LSDB L1 dei router BN-3 BN-4 e LSDB L2 dei router BN-1 e BN-2]
  2. In una rete IS-IS multi-livello, i router di tipo L1 installano o meno la default-route, in funzione del valore binario “1” oppure “0” posto nel bit meno significativo nel campo ATT (campo di 4 bit), che è presente nei Link State Packet (LSP) L1 generati dai BN. I BN dell'area 49.0111 stabiliscono un’adiacenza L2 con altra area (cioè la 49.0222) e di conseguenza definiscono il campo ATT = 0001b (discorso analogo vale per i BN dell'area 49.0222 che stabiliscono un’adiacenza L2 con i BN dell'area 49.0111). Poiché in una architettura Seamless MPLS per raggiungere una destinazione al di fuori del dominio IGP utilizzeremo solo le informazioni di routing BGP-LU, possiamo istruire i router di tipo L1 a ignorare il campo ATT (comando attached-bit receive ignore), affinché non installino la default-route
  3. Il prefisso /32 dell’interfaccia di Loopback0 dei BN appartiene alla topologia L2 e alla topologia L1 (circuit-type level-1-2). Ciò è necessario affinché un qualunque router L1 del “dominio x” di aggregazione possa raggiungere via IGP la Loopback0 dei BN aventi interfacce fisiche attestate sul “dominio x” [NOTA: questa raggiungibilità esplicita poi ci servirà, almeno per allestire le sessioni iBGP tra un router di tipo L1 del “dominio x” di aggregazione e i relativi BN] 
  4. La raggiungibilità tra le Loopback0 dei router BN-1 e BN-2 e, separatamente, BN-3 e BN-4 avviene attraverso la topologia L1 della rispettiva area, invece che attraverso la topologia L2. Questo risultato è quello previsto dal processo decisionale del protocollo IS-IS (RFC 5302 - Domain-Wide Prefix Distribution with Two-Level IS-IS). È necessario invece che la raggiungibilità reciproca tra i BN avvenga tramite la topologia L2, quantomeno per motivi di maggiore banda dei link (in una rete reale) del dominio CORE. Per realizzare questo tipo di instradamento si può configurare, ad esempio, un inbound route filtering da applicare alle interfacce dei BN che “guardano” i domini di aggregazione, ma tale funzionalità è disponibile solo dalla versione 6.5.1 dell'IOS-XR. In ogni caso, è possibile ottenere il risultato desiderato con un’altra strategia di configurazione del protocollo IS-IS nei Border Node (che stiamo per introdurre).
Tecnica N.2 - partizione della rete e utilizzo di più processi IS-IS nei Border Node 

La tecnica N.2 è più flessibile della precedente e nasce dall’idea di utilizzare più processi di routing IS-IS nei BN. I domini IGP con questa tecnica sono isolati “by-design”, purché i processi IS-IS dei domini di aggregazione siano configurati come is-type level-1 e il processo del dominio CORE sia configurato come is-type level-2-only.

È necessario fare qualche doverosa precisazione. 

La Global Routing Table viene popolata in funzione dei risultati che di volta in volta si ottengono dalle applicazioni, su base processo IS-IS, dell’algoritmo Shortest Path First. In generale ogni processo ha i suoi LSDB dedicati di Livello 1 e/o di Livello 2. Le interfacce fisiche possono partecipare solo a un processo. Questo non è tuttavia un vincolo se si utilizzano istanze multiple IS-IS come da RFC 8202 - IS-IS Multi-Instance, supportate da IOS-XR, ma che non utilizzerò nelle configurazioni (il comando instance-id <numero istanza> è “nascosto” nella release 6.1.3). 

L’IOS-XR, a differenza dell’IOS-XE, consente la partecipazione dell’interfaccia di Loopback in più processi IS-IS (Loopback “ubiqua”). Se si utilizzasse la tecnica N.2 in un’architettura Seamless con Segment Routing MPLS (SR-MPLS) la configurazione di una Loopback “ubiqua” in un BN sarebbe una scelta obbligata. E' bene tenere sempre in mente che a livello IGP serve una raggiungibilità esplicita (non tramite default-route) tra la Loopback0 di un qualunque router L1 del “dominio x” di aggregazione e la Loopback0 dei BN che hanno alcune interfacce partecipanti nel processo is-type level-1 del “dominio x”. Invece, utilizzando il protocollo LDP al posto del SR-MPLS, si può, in alternativa alla Loopback “ubiqua”, inserire una Loopback0 nel processo IS-IS “CORE” (is-type level-2-only) ed eseguire una redistribuzione dell’interfaccia in questione, dal processo IS-IS “CORE” nel processo IS-IS del dominio di aggregazione (is-type level-1).

Un’ultima rapida precisazione fondamentale. Ho fatto diversi test con IOS-XR 6.1.3 e sono giunto alle stesse conclusioni riportate nella seguente prescrizione Cisco, che ho trovato in un manuale non proprio recente dell’ASR9k: 

Because the Routing Information Base (RIB) treats each of the IS-IS instances as equal routing clients, you must be careful when redistributing routes between IS-IS instances. The RIB does not know to prefer Level 1 routes over Level 2 routes. For this reason, if you are running Level 1 and Level 2 instances, you must enforce the preference by configuring different administrative distances for the two instances. 

Di questo si terrà conto nelle configurazioni dei BN. Ricordiamo che la distanza amministrativa è l’indice di affidabilità delle informazioni di routing che un costruttore assegna a ogni protocollo. Cisco ha definito per il protocollo IS-IS un valore di default pari a 115, sia per livello di routing L1 che per il livello di routing L2.

Non riporto le configurazioni di questa tecnica perché sarà utilizzata nella rete Seamless MPLS di laboratorio (prossima sezione).

Rete Seamless MPLS di laboratorio con IOS-XR 6.1.3 

Consideriamo la rete BGP/MPLS in figura, rappresentativa di un piccolo ambiente Service Provider di laboratorio. Nel dominio CORE sono presenti due nodi di transito TN, due Route-Reflector (RR) e tre coppie di BN, su ognuna dei quali è attestato un dominio.



Ogni router ha un nome seguito da un numero “x”, quest’ultimo utilizzato convenzionalmente come di seguito:
  • Indirizzi di Loopback Lo0: 10.20.30.x/32
  • Node-SID: x
  • Cluster-ID (solo RR e BN/Inline RR): 0.0.0.x
Come avrete notato, la legenda sintetizza la partizione della rete in domini IGP secondo la tecnica N.2. C’è una novità in questo schema che non abbiamo visto nelle sezioni precedenti: sono stati introdotti dei link logici (un trunk dot1q) per ogni coppia di BN connessi back-to-back e sono stati associati ai processi IS-IS del rispettivo dominio di aggregazione. In sostanza è stata introdotta la continuità della topologia L1 sulle coppie <BN-31, BN-32>, <BN-33, BN-34>, <BN-35, BN-36> perché diversamente non si potrebbero avere dei percorsi alternativi di backup pre-calcolati per tutte le destinazioni (considerate che LFA oppure TI-LFA agiscono su base processo IS-IS). Ad esempio, avendo richiuso la topologia L1 tramite link logico <BN-31BN-32>, SN-2 per la destinazione BN-31 ha un link primario diretto e un percorso pre-calcolato alternativo di backup attraverso BN-32

C’è una soluzione alternativa all’utilizzo dei link logici ma è necessario invocare ed applicare la RFC 8202 citata sopra. In altri termini, anziché processi IS-IS tradizionali, è necessario utilizzare istanze IS-IS, ognuna delle quali è identificata da un instance-id. A questo punto l’interfaccia fisica può essere “ubiqua” ed è possibile richiudere la topologia L1 senza utilizzare link logici.

Tornando ai nostri discorsi … i router RR-99 e RR-100 sono RR fuori dal piano dati. I RR devono essere raggiungibili via IGP solo dai router del dominio CORE e non devono essere attraversati da LSP MPLS, quindi è buona norma non configurare MPLS su questi nodi.  

Iniziamo a parlare di configurazioni. Il seguente comando, a prima vista ridondante, è fondamentale per il funzionamento della rete:
 
router isis nome-processo
 segment-routing global-block 16000 23999

Deve essere introdotto in tutti i router dove è abilitato il SR-MPLS. Sembrerebbe non necessario perché la coppia [base, range] dichiarata esplicitamente coincide con il blocco SRGB di default nell’IOS-XR. In realtà, senza questo comando le istruzioni SR per allestire LSP MPLS intra-dominio risultano corrette nei router, mentre non lo sono quelle per allestire LSP MPLS inter-dominio.

Configurazione IGP + SR-MPLS del BN-32

router isis CORE
 is-type level-2-only
 net 49.0999.0100.2003.0032.00
 address-family ipv4 unicast
  metric-style wide
  distance 114
  segment-routing mpls
 !
 interface Loopback0
  passive
  address-family ipv4 unicast
   prefix-sid index 32
  !
 !
 interface GigabitEthernet0/0/0/0
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   metric 100
  !
 !
 interface GigabitEthernet0/0/0/1
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   metric 100
  !
 !
!
router isis DOMAIN-D1
 is-type level-1
 net 49.0001.0100.2003.0032.00
 address-family ipv4 unicast
  metric-style wide
  segment-routing mpls
 !
 interface Loopback0
  passive
  address-family ipv4 unicast
   prefix-sid index 32
  !
 !
 interface GigabitEthernet0/0/0/1.1
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   metric 1000
  !
 !
 interface GigabitEthernet0/0/0/2
  point-to-point
  address-family ipv4 unicast
   fast-reroute per-prefix
   fast-reroute per-prefix ti-lfa
   metric 1000
  !
 

Osservazioni:
  • Tra i comandi evidenziati si possono riconoscere quelli riguardanti il SR-MPLS.
  • La configurazione della distanza amministrativa del processo is-type level-2-only è pari a 114. Ciò implica che la raggiungibilità desiderata via topologia L2 tra i BN, attestati a uno stesso “dominio x” di aggregazione, avviene costringendo il BN a selezionare il percorso L2 disponibile.
  • Le interfacce del dominio CORE hanno un costo IGP pari a 100, mentre le interfacce dei domini di aggregazione hanno un costo IGP pari a 1000. L’utilizzo del TI-LFA consente di pre-calcolare (per dominio) i percorsi alternativi di backup per ogni destinazione (copertura 100% indipendentemente dalla topologia). La topologia dei domini di aggregazione della nostra rete in realtà banalmente soddisfa le condizioni metriche affinché il LFA sia sufficiente per una protezione a copertura 100%. Nel dominio CORE l’utilizzo del solo LFA classico ha la sua efficacia se si modificano le metriche di alcune interfacce. Per comprendere “dove mettere le mani”, basta notare in figura che la numerazione dei nodi nel dominio CORE è stata pensata per mettere in risalto la presenza di un “piano pari” e di un “piano dispari” (è un CORE Dual-Plane semplificato di laboratorio). Per rendere disponibili dei percorsi alternativi di backup è sufficiente “avvicinare” i due piani giusto il necessario. Architetture di questo tipo sono interessanti anche perché, senza grosse pretese e in modo semplice, si può pre-ingegnerizzare il traffico configurando i servizi su base piano, per sfruttare al meglio i link della rete.
Riportiamo la configurazione BGP di base per il BN-32:

route-policy BGP-PREFIX-SID($SID)
  set label-index $SID
end-policy
!
!
router bgp 64530
 bgp router-id 10.20.30.32
 bgp cluster-id 0.0.0.32
 ibgp policy out enforce-modifications
 address-family ipv4 unicast
  network 10.20.30.32/32 route-policy BGP-PREFIX-SID(32)
  allocate-label all
 !
 neighbor-group RR-CORE
  remote-as 64530
  update-source Loopback0
  address-family ipv4 labeled-unicast
   next-hop-self
  !
 !
 neighbor-group RR-CLIENT-AGG-ACC
  remote-as 64530
  update-source Loopback0
  address-family ipv4 labeled-unicast
   route-reflector-client
   next-hop-self
  !
 !
 neighbor 10.20.30.2
  use neighbor-group RR-CLIENT-AGG-ACC
 !
 neighbor 10.20.30.99
  use neighbor-group RR-CORE
 !
 neighbor 10.20.30.100
  use neighbor-group RR-CORE
 !
 
Tutti i BGP Speaker della rete, tranne i due RR del dominio CORE, devono necessariamente annunciare la loro presenza al di fuori del dominio di appartenenza, comunicando il prefisso /32 dell’interfaccia di Loopback + label MPLS. Come già detto nel primo post, la label MPLS da inserire nell’annuncio deve essere relativa a un’istruzione SR. La label è quella corretta se si utilizza la route-policy BGP-PREFIX-SID($SID). Nei messaggi BGP-UPDATE che si possono intercettare con uno sniffer nella nostra rete di laboratorio risulta che l’attributo BGP Prefix-SID (vedi RFC 8669 - Segment Routing Prefix Segment Identifier Extensions for BGP) contiene solo il modulo TLV Label-Index e non include l’Originator SRGB (è un modulo TLV opzionale). Di conseguenza un router con la ricezione di un BGP Prefix-SID crea l’istruzione SR “assoluta” in funzione della “base” configurata localmente. 

Per il resto, la configurazione è autoesplicativa e potete verificare la sua correttezza con ciò che abbiamo detto nel primo post. Osserviamo in particolare che nella configurazione di BN-32 c’è l’istruzione per la variazione dell’attributo NEXT_HOP in entrambi i neighbor-group (i BN sono InLine RR).

Le configurazioni dei restanti router sono semplici da ricavare e non le riporto per questioni di spazio.

… ecco un traceroute eseguito da SN-3 verso la destinazione SN-5


RP/0/0/CPU0:SN-3# traceroute 10.20.30.5 source 10.20.30.3
. . .
Type escape sequence to abort.
Tracing the route to 10.20.30.5
 1  10.0.0.26 [MPLS: Label 16005 Exp 0] 9 msec  9 msec  9 msec
 2  10.0.0.50 [MPLS: Labels 16035/16005 Exp 0] 9 msec  9 msec  9 msec
 3  10.0.0.86 [MPLS: Label 16005 Exp 0] 9 msec  9 msec  9 msec
 4  10.0.0.114 9 msec  *  9 msec

Le configurazioni di una rete Seamless MPLS tradizionale (cioè senza SR-MPLS) sono altrettanto semplici. Rispetto a quanto già visto, è necessario abilitare LDP al posto del SR-MPLS, il piano di controllo BGP è identico con ovvia rimozione della route-policy BGP-PREFIX-SID. Infine, occorre eliminare in tutti i router la riga di configurazione riguardante il TI-LFA.

Una osservazione finale. Una rete Seamless MPLS con una configurazione BGP minimale come quella riportata in questo post se ci pensiamo un attimo andrebbe migliorata per una questione molto importante: la non ottimalità dei percorsi inter-dominio. Utilizzando l’attributo AIGP (vedi questo post in questo blog) possiamo tener memoria delle metriche IGP quando gli annunci MP-iBGP vengono propagati all’interno dell’AS, affinché poi un SN di un dominio X per raggiungere un SN di un dominio Y abbia “visibilità”,  nell’ambito del processo di selezione del best-path, del costo IGP complessivo end-to-end.  

Tecnica N.3 – Inter-AS Seamless MPLS

La tecnica che sto per descrivere costituisce un’ulteriore possibilità per partizionare e organizzare il funzionamento Seamless di una rete MPLS. E' possibile introdurre questa tecnica da un’altra prospettiva. Ad esempio, supponiamo che due Service Provider “X” e “Y” dispongano di una rete Seamless MPLS rispettivamente con numeri di AS 64530 e 64531. “X” acquisisce la proprietà di “Y” e quindi nasce l’esigenza di gestire in maniera semplice l’intera grande rete. È possibile realizzare un’unica rete Seamless MPLS? La risposta è affermativa e la soluzione è molto semplice.
Consideriamo il seguente schema: 



Come avrete già notato ho modificato opportunamente lo schema di laboratorio della sezione precedente, ma solo la parte destra. I BN-35 e BN-36 hanno cambiato nome, rispettivamente in ASBR-35 e ASBR-36; il piano di controllo BGP dell’AS 64530 è identico a quanto già discusso finora (per non appesantire il disegno ho riportato con delle frecce solo le sessioni BGP-LU sulla destra di RR-99 e RR-100). La novità sostanziale è data dalle due sessioni eBGP-LU verso il nuovo AS 64531, quest’ultimo raffigurato semplicemente con tre router BGP/MPLS appartenenti ad un’unica area OSPF, ma che potrebbe essere strutturato e organizzato in un contesto di laboratorio come l’AS 64530.

Riportiamo la configurazione base BGP dell’ASBR-38:

route-policy ALL
  pass
end-policy
!
router bgp 64531
  bgp router-id 10.20.30.38
  bgp cluster-id 0.0.0.38
  ibgp policy out enforce-modifications
  address-family ipv4 unicast
    network 10.20.30.38/32 route-policy BGP-PREFIX-SID(38)
    allocate-label all
!
  neighbor-group EXT-ASBR
    remote-as 64530
    address-family ipv4 labeled-unicast
      route-policy ALL in
      route-policy ALL out
!
  neighbor-group INT-ASBR
    remote-as 64531
    update-source Loopback0
    address-family ipv4 labeled-unicast
      next-hop-self
!
  neighbor-group RR-CLIENT-AGG-ACC
    remote-as 64531
    update-source Loopback0
    address-family ipv4 labeled-unicast
    route-reflector-client
      next-hop-self
!
  neighbor 10.0.0.109
    use neighbor-group EXT-ASBR
!
  neighbor 10.20.30.5
    use neighbor-group RR-CLIENT-AGG-ACC
!
  neighbor 10.20.30.37
    use neighbor-group INT-ASBR

Osservazioni:
  • ASBR-38 varia l’attributo NEXT_HOP di default sulle sessioni eBGP-LU, mentre sulle sessioni iBGP-LU è necessaria una configurazione esplicita next-hop-self  [vedi configurazione dei tre neighbor-group]
  • La sessione eBGP-LU è allestita utilizzando l’interfaccia fisica avente indirizzo IP 10.0.0.109/30 
  • È necessario che l’interfaccia fisica dell’ASBR-38 connessa back-to-back con quella dell’ASBR-36 possa inoltrare/ricevere traffico MPLS. L’IOS-XR per il protocollo BGP contempla il comando mpls activate interface <interfaccia> ma secondo la Routing Command Reference di Cisco risulta necessario solo quando i due AS sono in realtà due sub-AS di un AS che li contiene (confederazione BGP), ma non è il nostro caso … con la sola configurazione base BGP indicata finora il piano di controllo BGP-LU complessivamente funziona ma c’è qualcosa che non va, come si evince dal seguente comando:

RP/0/0/CPU0:ASBR-38# show cef unresolved
Fri Mar  6 04:09:34.478 UTC

Prefix              Next Hop            Interface
------------------- ------------------- ------------------
10.20.30.2/32       10.0.0.109/32 (?)   <recursive>
10.20.30.3/32       10.0.0.109/32 (?)   <recursive>
10.20.30.31/32      10.0.0.109/32 (?)   <recursive>
10.20.30.32/32      10.0.0.109/32 (?)   <recursive>
10.20.30.33/32      10.0.0.109/32 (?)   <recursive>
10.20.30.34/32      10.0.0.109/32 (?)   <recursive>
10.20.30.35/32      10.0.0.109/32 (?)   <recursive>
10.20.30.36/32      10.0.0.109/32 (?)   <recursive>

Per risolvere il problema è sufficiente introdurre il seguente instradamento statico:

router static
 address-family ipv4 unicast
  10.0.0.109/32 GigabitEthernet0/0/0/2

… ecco un traceroute eseguito da SN-2 verso la destinazione SN-5 …

RP/0/0/CPU0:SN-2# traceroute 10.20.30.5 source 10.20.30.2
...
Type escape sequence to abort.
Tracing the route to 10.20.30.5

 1  10.0.0.14 [MPLS: Label 16005 Exp 0] 29 msec  19 msec  9 msec
 2  10.0.0.42 [MPLS: Labels 16035/16005 Exp 0] 9 msec  9 msec  9 msec
 3  10.0.0.86 [MPLS: Label 16005 Exp 0] 9 msec  9 msec  9 msec
 4  10.0.0.114 [MPLS: Label 16005 Exp 0] 9 msec  9 msec  9 msec
 5  10.0.0.118 9 msec  *  9 msec


Conclusioni: Abbiamo presentato gli aspetti pratici di base dell’architettura Seamless MPLS, introducendo le tecniche di partizione e le relative configurazioni di base, evidenziando anche i comandi specifici del SR-MPLS qualora lo si volesse utilizzare … ma serve davvero SR-MPLS? Mi sono fatto questa domanda anche in funzione delle tre motivazioni oggettive scritte nel primo post. È vero che con SR-MPLS abbiamo un protocollo in meno (generalmente LDP), ma è pur vero che il funzionamento di una rete MPLS tradizionale è “pura sinfonia” se la rete è ben progettata e ben configurata. Abbiamo già detto che il SR-TE senza un controllore centralizzato serve a ben poco. Il TI-LFA può far la differenza in certe situazioni … ma non aggiungo altro. Si sente molto parlare di SRv6 … Finché non si individua uno use-case di reale necessità, che non possiamo fare se non con il SRv6 … il SRv6 in fin dei conti a cosa serve? … staremo a vedere. 
    
Ringraziamenti: Un grazie ai lettori di questo blog. Grazie infinite al mio amico Tiziano Tofoni, lungimirante ed esperto di riferimento del settore, nonché una persona squisita anche sotto il profilo umano.



4 commenti:

  1. Prendo spunto dai dubbi espressi da Marco Serra per esprimere anche i miei. Ne ho di forti su SR/SR-TE + Controller SDN ed in particolare su TI-LFA.
    Da quel che leggo su varie fonti TI-LFA ha due importanti limitazioni di cui però nessuno parla (sarei felice se qualcuno mi smentisse):

    1)Può ovviamente solo essere innescato dall'ASIC essendo pre-programmato in ASIC e quindi un cambiamento di una caratteristica IGP-TE del link come costo o misure attive di ritardo, jitter, drops ... whatever.. non lo innesca

    2)soffre fisiologicamente di microloops cosa che RSVP-TE non ha ma sarei felice anche qui che qualcuno possa smentirmi.

    Detto questo, qualcuno potrebbe obiettare che se fai scorrete TUTTO (!) il tuo traffico in SR-TE con SOLO ADJ-SID allora di fatto sei indipendente in rete da cambiamenti di caratteristiche del link e puoi anche permetterti che questi cambiamenti siano inviati con un protocollo al Controllore SDN con tutta la lentezza del caso (se usi BGP-LS una vita ..se usi IGP peering molto meno..) che a sua volta in maniera arbitrariamente lenta ricalcola i percorsi e sposta il traffico. Durante tutto questo tempo il traffico non si è spostato dal tunnel e quindi subisce un forwarding non ottimale ma se avesse reagito al cambio di caratteristica del link senza l’apporto di TI-LFA sarebbe incorso in loops (loops che a 400Gbps in carrier networks riescono facilmente a saturare links ed impattare quindi TUTTO il traffico di un link…not good) e quindi diciamo che si è scelto il migliore dei due mali…..ma….hang on …. abbiamo detto che tutto questo (non proprio già brillantissimo) risultato lo ottieni solo se fai scorrete TUTTO il tuo traffico in SR-TE con SOLO ADJ-SID. Beh ..ma qui abbiamo per Carrier Network e quindi per grandi networks un ulteriore problema che è quello del limite superiore al depth dello stack MPLS supportato dai vari (si spera proprietari altrimenti la partita finisce qui) ASIC o sbaglio ? Insomma, indipendentemente da quale angolo la si osserva non se ne esci fuori poi cosi bene e questo è inquietante.

    Insomma, dopo l'hyper iniziale della novità, e’ cosi (“GENH= Good Enough Networking …Hopefully”) che ci si muove verso lo use-case principe per il SR che è lo slicing del 5G ? parliamone ….c’e’ ancora un po di tempo per ‘aggiustare’ il tiro.

    RispondiElimina
  2. Andrea,
    grazie per aver commentato il post.

    Rispondo alle due questioni che sollevi sul TI-LFA ed infine al problema Maximum SID Depth.

    Riguardo la prima “limitazione” che intravedi nel TI-LFA, non mi risulta (potrei non essere informato su alcune novità) che il funzionamento possa essere condizionato da caratteristiche TE e quindi anche da relative variazioni di quest’ultime.

    Per quanto concerne i microloop, è vero che possono manifestarsi a seguito di un evento up-->down di un link (oppure down-->up) o cambio di metrica IGP. Tuttavia è stata studiata una soluzione di microloop avoidance che risolve la questione attraverso la convergenza in due fasi. In altri termini, la fase 2 (quella di regime, cioè quella che si avrebbe direttamente se la funzione microloop avoidance non fosse attiva), viene temporalmente “ritardata” perché preceduta da una fase transitoria che entra in gioco velocemente, praticamente subito dopo l’evento di guasto (up/down link o cambio metrica). Durante questa fase transitoria il forwarding del traffico avviene via tunnel SR-TE, che è pre-segnalato se la funzione di microloop avoidance è configurata.

    Per poter offrire il ventaglio di servizi SR-TE proposto da chi opera nel technical-marketing è necessario un controllore (o più controllori, dipende dall’architettura). Il controllore è certamente necessario in una rete SR-TE multi-dominio per diversi motivi, tra i quali il problema del Maximum SID Depth (MSD), anche da te indicato nel tuo intervento. La questione MSD riguarda al momento tutti i vendor di router. Con router MPLS di “piccola fascia” ad oggi si può effettuare in hardware un’operazione di Label Imposition fino da un max di 4-5 etichette MPLS, mentre con i router moderni di “fascia alta” il valore MSD è al più 12 (questi sono i dati a me noti). Il problema di instradare traffico su un percorso SR-TE “strict” in una rete che ha un “diametro” maggiore del MSD oggi viene risolto da un controllore. Ad esempio, in una rete multi-dominio SR-MPLS, attraverso le sessioni BGP-LS allestite tipicamente tra ogni Border Node ed il PCE server centralizzato, quest’ultimo apprende il MSD dei router. Il PCE Server, una volta appresa “la limitazione” dei router, su base richiesta calcola il percorso vincolato e comunica al router client PCC via PCEP lo stack MPLS necessario (le istruzioni SR) per raggiungere un “anchor node” (è stato definito appositamente un SID chiamato Binding-SID). Supponendo che l’intero percorso calcolato dal PCE server sia costituito da due sotto-percorsi, al pacchetto MPLS instradato che ha raggiunto l’anchor node viene eseguita un’ulteriore operazione di stack imposition per “guidare” a destinazione il pacchetto MPLS.

    Un saluto,
    Marco Serra.

    RispondiElimina
  3. Ciao Marco e scusa il ritardo siderale nel risponderti - spezzo il post in due che altrimenti il messaggio supera i 4096 caratteri. Ottimo Marco che confermi che caratteristiche del link (cioè metriche TE quali #hops, drop, delay, jitter, e via discorrendo che possono anche provenire dallo strato trasmissivo sottostante) non innescano TI-LFA. Questo è un primo bel grosso problema. Ricordiamo infatti che questo tipo di eventi genera sia loops (cioè locali al cambio di metrica TE) in quanto non innesca TI-LFA, sia ‘naturalmente’ anche microloops (ovvero loops in punti remoti rispetto al TE metric change). In realtà dovrebbero chiamarsi microloops entrambi con l’unica differenza che TI-LFA copre (quando copre…) solo quelli locali al cambio di metrica TE e non anche quelli remoti. Per semplicità chiamerò quindi tutti i loops con il termine microloops distinguendoli in locali (appannaggio di TI-LFA) e remoti. Un ‘cambio di metrica TE’ è da considerarsi una ‘control-plane/management-plane action’; Esempi di uso in campo comprendono ad esempio le feature ‘cost-fallback’ ed ‘IGP overloading’ che avvelenano la metrica IGP sia in reazione a cadute di piu link di un LAG che per scopi di messa offline/online di un link o di un intero router. Cambi di metrica TE emergeranno in IP in futuro dallo strato ottico sottostante che ha visibilità del degrado di un link, del ritardo, del jitter, e via discorrendo. Non è pensabile che ogni qualvolta lo strato IP/Ethernet o lo strato trasmissivo sottostante segnala alla rete IP un cambio di stato ci sia del traffico looped sia localmente che remotamente al punto IP in cui c’e’ il cambio di stato.
    Gia che ci siamo ricontestualizziamo la cosa e ricordiamo anche che il problema dei microloops a 400Gbps ed oltre non è un vezzo da puristi del networking ma una cosa seria in quanto mette facilmente in ginocchio la rete se subiscono loop flussi quali ad esempio il (multi-hop) BGP (ed in soluzioni overlay modaiole del momento di BGP Multi-Hop se ne vede parecchio …) o l’SCTP della segnalazione del mobile, 5G compreso, se non c’e’ la path diversity a protezione per citarne solo due tra i molti. Ricordiamo che un microloop aumenta il traffico di un link fino a 128 volte (leggi TTL..). I microloops poi, in quanto saturano il link, inducono paradossalmente drops di pacchetti di traffici le cui destinazioni non sono affette dal cambio di stato/metrica_TE ed in questo senso la QoS è una FONDAMENTALE protezione per la segnalazione. Non c’è invece qos che tenga per i flussi stessi le cui destinazioni sono looped se non riconoscere che questi pacchetti sono looped e scartare il traffico per evitare quantomeno di portare il link in saturazione…non proprio il massimo se consideriamo l’elasticità della reazione TCP al drop soprattutto di alcuni stack TCP aggressivi (vedi BBR usato da QUIC/Google ma non voglio aprire un'altra ‘can of worms’ ora – magari un altro post ? ).
    La cosa ancora piu paradossale che sottolinea RFC 5715 è che i microloop remoti non consentono al traffico di raggiungere il PLR e quindi di usufruire della protezione TI-LFA contro i microloops locali. Queso ci dice che non serve a nulla implementare TI-LFA per risolvere i microloop locali se non si coprono anche i microloop remoti.
    E chiudiamo con il fatto che i microloop remoti possono manifestarsi ovunque e se ne può manifestare piu di uno in sequenza/progressione temporale il che aumenta la durata complessiva del danno al traffico che subisce in sequenza ravvicinata loop su link diversi.

    ************** seconda parte del post segue *********************

    RispondiElimina
  4. ************* seconda parte del post *****************

    L'algoritmo di microloop avoidance che citi Marco è se non erro la soluzione proprietaria Cisco descritta da Filsfils nel suo libro di cui però non ci svela i dettagli. A questo proposito credo che sulla base dell’RFC 5715 questa soluzione propietaria debba classificarsi come ‘Micro-loop prevention’ ed in particolare il metodo debba classificarsi come ‘Distributed tunnels’. Il draft ‘draft-hegde-rtgwg-microloop-avoidance-using-spring-03’ la chiama “per destination non micro-looping path computation” e ne sottolinea l’estrema intensità computazionale che è il mio stesso forte dubbio sulla reale implementabilità di questo metodo su grosse reti di trasporto. Da libro/lab all’implementazione su grandi reti di trasporto la strada è lunga. Vedremo. In ogni caso la capacità computazionale a bordo router non credo sia sufficiente – sarei sorpeso del contrario. Anche questo, nel caso fosse implementato, sarebbe quindi appannaggio computazionale esclusivo del Controller SDN. ☹ Quindi, se ancora ce ne fosse bisogno è necessario sottolineare come una soluzione di microloops avoidance come quella prospettata da Filsfils e di cui parla Marco necessita di una enorme capacità elaborativa possibile solo a bordo di un controllore SDN e pertanto è impensabile pensare di usare BGP-LS come SBI (SouthBound Interface) ma piuttosto l’IGP direttamente, cosa che pochi fanno purtroppo. Ogni secondo di ritardo aggiuntivo nella detection del network change introdotto dal BGP-LS è infatti un secondo in piu di traffico looped…
    Un plauso Marco per non aver citato SRv6 come panacea di tutti i mali. Neanche inizio il discorso su SRv6, non ne vale la pena. :)

    Ciao
    Keep smiling
    Andrea

    RispondiElimina