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 e 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 e 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-31, BN-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.