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

È con "viva e vibrante soddisfazione" che ReissBlog ospita questo post, 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. 

*************

PREMESSA

Lo standard MPLS a partire dal suo esordio ha avuto un successo indiscutibile che continua nel tempo. È stato inizialmente adottato da Carrier e Service Provider, ma il suo utilizzo ha interessato, e ad oggi interessa, anche le reti Enterprise. 

Come sappiamo, il BGP nelle reti MPLS ha un ruolo chiave per il funzionamento dei principali servizi, dato che uno dei suoi compiti è quello di annunciare delle Service Label MPLS, associate a particolari oggetti dipendenti dal servizio (es. prefissi VPN-IPv4/VPN-IPv6, siti L2VPN, ecc.). In alcuni casi, come quello analizzato in questo post, è possibile utilizzare il BGP anche per l’annuncio di Transport Label. 

Probabilmente molti di voi conoscono i principi di funzionamento dell’architettura Seamless MPLS … la “provocazione” (si fa per dire …) consisterà nel valutare l’utilizzo del Segment Routing con piano dati MPLS nei domini IGP, al posto del protocollo LDP. Questa scelta comporterà, come vedremo, un “correttivo” per far funzionare la rete nel suo complesso (inter-domain LSP). 

L’argomento verrà suddiviso in due post: nel primo discuteremo gli aspetti teorici, nel secondo vedremo gli aspetti importanti di configurazione (e non solo) di una rete Seamless MPLS di laboratorio, costituita da router che utilizzano l’IOS-XR (in particolare la versione 6.1.3).

Procediamo con ordine con una piccola premessa per focalizzare il contesto. Il progetto di una rete IP di medie/grandi dimensioni (cioè costituita anche da diverse migliaia di router) tipicamente contempla una partizione della rete per problemi di scalabilità del protocollo IGP (OSPF oppure IS-IS). Nel passato, indicativamente fino al 2010, la questione poteva essere affrontata con una suddivisione della rete (generalmente un unico Autonomous System) in aree di routing IGP. Nei casi più “disperati” (reti di dimensioni molto grandi) la rete poteva essere organizzata in più Autonomous System interconnessi sotto la stessa amministrazione, complicando però sia la gestione che il provisioning dei servizi di rete. Da alcuni anni a questa parte, progetti di rete di questa portata si possono affrontare con un’architettura Seamless MPLS. 

Per completezza, prima di passare oltre, teniamo presente che oggigiorno per un backbone fino a 1000 router, generalmente si realizza un’unica area di routing OSPF oppure una singola area IS-IS costituita da router L2-only. Evidentemente si sta parlando di router di fascia alta, dotati di piano di controllo ridondato con CPU multi-core. Nel caso di router “economici”, che generalmente possono essere collocati nelle reti di aggregazione di un grande backbone, oppure utilizzati per realizzare una piccola rete MPLS, è bene non superare i 150-200 router per area. In ogni caso, consultate il vendor per chiarimenti specifici e comunque vale sempre la regola che “più piccola è l’area maggiore è la garanzia sulla sua stabilità”.

Finita la premessa ... iniziamo!

INTRODUZIONE

L’architettura di routing BGP/MPLS ha una caratteristica “banale” ma molto importante e che a breve descriveremo, indipendentemente dal fatto che l’Autonomous System dal punto di vista IGP abbia una singola area/livello di routing oppure abbia una organizzazione multi-area/multi-livello. Tale caratteristica “banale” riguarda i servizi. Nello specifico, per allestire/modificare un servizio si interviene in sostanza solo sugli end-point. Pensiamo ad esempio ad uno pseudowire EoMPLS, ad una L3VPN con VRF su N PE, ad una VPLS con VSI su M PE, ecc. In tutti questi casi si interviene in configurazione, rispettivamente su 2 PE, su N PE, su M PE. 

Questa caratteristica non è presente quando, ad esempio, per i soliti motivi di bassa scalabilità del protocollo IGP, si concepiscono due AS connessi back-to-back in modalità “Option A” come nella figura seguente.

Per realizzare una L3VPN che connette una sede dell’AS 64530 ed una sede dell’AS 64531 è necessario intervenire in configurazione anche sulla frontiera dei due AS, configurando quanto necessario (subinterfaces, encapsulation dot1q, VRF, indirizzi IP …) per allestire poi una sessione eBGP su base VRF.

NOTA: per chi non fosse familiare con i servizi L3VPN multi-provider, la modalità "Option A", anche detta VRF-to-VRF, consiste nell'attivare, tra ciascuna coppia di PE-ASBR (ossia i PE di frontiera degli AS), una VRF per ciascuna L3VPN da interconnettere e scambiare tra queste coppie di VRF, una su ciascun PE-ASBR, le informazioni di routing utilizzando un classico piano di controllo puramente IP. Questo fa si che ciascun PE-ASBR veda l’altro PE-ASBR come fosse un CE, permettendo lo scambio dei prefissi inter-sito utilizzando le regole classiche delle L3VPN BGP/MPLS.

In questo caso l’architettura in figura è non-Seamless, in quanto per configurare una L3VPN che interessa sedi di entrambi gli AS è necessario “ricucire” i due domini MPLS, operazione “sartoriale” da eseguire per ogni L3VPN.

L’unico aspetto interessante dell’esempio discusso è che abbiamo affrontato un grande problema suddividendolo in due problemi più piccoli, che sappiamo gestire in maniera semplice, anche se la soluzione non è per niente scalabile per quanto concerne la configurazione/gestione dei servizi.

L’approccio Divide et Impera è comunque il punto di partenza, come vedremo a breve. 

ARCHITETTURA SEAMLESS MPLS

Un’architettura Seamless MPLS presuppone che la rete sia partizionata nei classici tre domini: Access, Aggregation e Core. La topologia generale è a stella con il Core in posizione centrale, sul quale sono attestati separatamente i domini di aggregazione. Il generico dominio di accesso è connesso su un dominio di aggregazione. I domini di aggregazione non devono essere mai connessi direttamente.

Secondo il draft-ietf-mpls-seamless-mpls-07, l’accesso è un dominio costituito da apparati con funzioni di networking minimali, tali da indicare per questi l’utilizzo del routing statico per la connettività verso i nodi di aggregazione. Il motivo principale è che nel draft si ipotizza un elevato numero di nodi di accesso economici, che non supportano MPLS. Di conseguenza le valutazioni di scalabilità in quel documento tengono conto di questo fatto. A titolo informativo, i dati sulla consistenza della rete, riportati nel draft e riguardanti l’implementazione di un “Large European ISP”, sono i seguenti:

• Number of Aggregation Domains: 100
• Number of Backbone Nodes: 1.000
• Number of Aggregation Nodes: 10.000
• Number of Access Nodes: 100.000

La soluzione Seamless MPLS, come discuteremo tra breve, in realtà è comunque altamente scaIabile e stabile, anche se i nodi di accesso fossero veri e propri nodi MPLS.

Prima di vedere l'architettura Seamless MPLS è bene vedere quale è ad oggi la soluzione con cui i Service Provider consentono l'accesso alla Core Network. Lo schema è riportato nella figura seguente.

Nello schema, per portarci avanti con il lavoro, abbiamo volutamente utilizzato la nomenclatura dei nodi utilizzata nel draft IETF citato sopra. I nodi di accesso (AN, Access Node) sono i nodi dove sono attestate le CPE dei Clienti, siano essi residenziali o business, da rete fissa o mobile. I nodi di trasporto (TN, Transport Node) sono nodi dedicati al semplice trasporto del traffico. Infine, i nodi di servizio (SN, Service Node) sono i nodi dove sono configurati i servizi cliente (es. L2VPN, L2VPN, ecc.).

L'architettura attuale prevede che il traffico che la rete di aggregazione riceve dalla rete di accesso, venga portato al SN attraverso dei circuiti virtuali L2, che terminano su delle istanze dedicate (es, VRF, VSI, ecc.). La rete di aggregazione, che in passato era costituita da reti Switched Ethernet, è migrata negli anni a una rete IP/MPLS e la separazione del traffico cliente avviene attraverso degli pseudowire. Questo consente di eliminare dalla rete di aggregazione tutte le problematiche legate all'utilizzo del protocollo Spanning Tree (banda inutilizzata, instradamenti non ottimi, forwarding loop, ecc.). Il problema di questa architettura è essenzialmente la scalabilità. Infatti, tutti i servizi dei clienti vengono concentrati in pochi SN, che quindi devono essere macchine molto potenti (e quindi energivore). L'idea dell'architettura Seamless MPLS è quella di estendere i SN alla periferia, tipicamente nei nodi della rete di aggregazione dove terminano gli AN.

A titolo esemplificativo, uno scenario Seamless MPLS potrebbe essere il seguente:

dove i Border Node sono i router di frontiera tra i diversi domini IGP/MPLS. Qualora la dimensione della rete lo giustificasse, sarebbe anche possibile estendere i SN ulteriormente in periferia, facendoli coincidere con gli AN, ma questo difficilmente avrà un seguito pratico.

NOTA: nell'architettura Seamless MPLS i domini IGP sono completamente separati, nel senso che tutti i prefissi interni a un dominio, ad esempio le interfacce di Loopback dei router, non sono visibili ai router appartenenti a domini differenti. Questo significa che i domini di routing sono totalmente isolati tra loro, a vantaggio della scalabilità e stabilità complessiva della rete. Allo stesso modo, i domini MPLS sono completamente separati, ossia i LSP MPLS originano e terminano nello stesso dominio. Questo significa che è possibile utilizzare protocolli diversi da dominio a dominio per la realizzazione dei LSP MPLS. Ad esempio, con riferimento alla figura sopra, il dominio MPLS #1 potrebbe utilizzare LDP, il dominio MPLS #2 RSVP-TE, il il dominio MPLS #3 sia LDP che RSVP-TE, e così via.

L’architettura di routing viene concepita fondamentalmente con due “mattoni” fondamentali:

• Partizione dell’intera rete in domini MPLS Access/Aggregation/Core, ognuno dei quali è un dominio IGP isolato. La dimensione del dominio IGP deve essere non troppo piccola (per evitare di avere inutilmente troppi domini IGP) e non deve essere troppo grande perché uno degli obbiettivi è anche la stabilità della soluzione. La dimensione del dominio IGP dipende in parte anche da fattori tecnologici del piano di controllo dei router, come già detto nella premessa di questo post. Osserviamo che il dominio IGP isolato comporta anche la stabilità complessiva della soluzione: se ci dovesse essere una instabilità in un dominio IGP, l’instabilità IGP verrebbe confinata in quel dominio (curiosità: per errori di configurazione di un router che avevano impatti a livello IGP, si sono verificati in passato down di backbone interi …). Abilitando il protocollo LDP si possono costruire LSP MPLS intra-dominio. L’utilizzo eventuale del protocollo RSVP-TE è possibile, anche se all’atto pratico sappiamo che vi è una certa preferenza da parte dei Service Provider ad utilizzare LDP.
• Utilizzo di BGP Labelled Unicast (BGP-LU, vedi RFC 3107 o la sua evoluzione RFC 8277). Questo ci consente di effettuare, per ogni router MPLS, l’annuncio di un prefisso IP + etichetta MPLS. Nel Seamless MPLS, il BGP-LU è utilizzato per annunciare una Host route /32, oppure /128 se la rete è IPv6 (tipicamente l'indirizzo IP di una interfaccia di Loopback) + etichetta MPLS associata. Questo è necessario per costruire LSP MPLS inter-dominio. 

Volendo introdurre una “piccola variazione sul tema” rispetto al draft, potremmo eliminare il protocollo LDP e attivare il Segment Routing con piano dati MPLS in ogni singolo dominio. Inoltre, per dar luogo correttamente a LSP MPLS inter-dominio, è necessario che le etichette MPLS presenti negli annunci BGP-LU siano un’istruzione SR BGP-Prefix-SID (vedi RFC 8669). Questo aspetto chiave molto semplice, verrà chiarito meglio nel prossimo post con la rete di laboratorio virtuale. 

NOTA: per chi non fosse familiare con i concetti base del Segment Routing, vedi i due post in questo blog: post 1 e post 2.

Perché il SR-MPLS? Alcune motivazioni:

• Il piano di controllo in ogni dominio IGP isolato è più semplice, perché c’è un protocollo in meno (LDP o RSVP-TE, utilizzati per la creazione di LSP MPLS). 
• La modalità di protezione TI-LFA (Topology Independent - Loop Free Alternate). Con un solo meccanismo e in maniera automatica, tramite il protocollo IGP vengono pre-calcolati i percorsi di backup per tutte le destinazioni (copertura 100%), indipendentemente dalla topologia di rete. Non utilizzando il Segment Routing, cioè in reti MPLS che utilizzano il protocollo LDP, in alcuni topologie di rete è sufficiente LFA (eventualmente intervenendo con aggiustamenti delle metriche di interfaccia), in altre (ad esempio per topologie ad anello innestate su un backbone) è necessario utilizzare anche il Remote-LFA. In alcune topologie davvero singolari il Remote-LFA non è sufficiente ed è necessario studiare dei percorsi espliciti (Tunnel RSVP-TE all’interno del quale si fa passare la segnalazione LDP) … 
• Traffic Engineering con il Segment Routing (SR-TE): Il SR-TE in una architettura Seamless MPLS come quella di cui stiamo discutendo è implementabile con forti limitazioni, quindi serve a ben poco. Il motivo risiede nel fatto che i router MPLS di qualunque vendor eseguono in hardware un’operazione di label push con una bassa/bassissima profondità dello stack MPLS. Ad esempio, apparati “economici” collocati tipicamente nell’accesso MPLS possono fare un label push di max 5 etichette, una delle quali in genere è una Service Label! quindi con un massimo di 4 etichette disponibili, la lunghezza dei percorsi costruiti con il SR-TE potrebbe non essere sufficiente in reti di grandi dimensioni. Per consentire l’utilizzo del SR-TE ci sono delle soluzioni (SID stack compression, SID stack expansion), ma presuppongono l’utilizzo di un controllore centralizzato. Per non uscire fuori tema, sulle osservazioni in merito al SR-TE ci fermiamo qui.

Tornando ai nostri discorsi … Per quanto esposto finora, per realizzare un LSP MPLS intra-dominio sappiamo già tutto. Ad esempio, se volessimo allestire uno pseudowire all’interno del dominio di accesso MPLS, verrebbe utilizzato uno stack di due etichette MPLS: quella più interna è la Service Label annunciata (tipicamente) tramite una sessione LDP Targeted, quella più esterna è la Transport Label che viene sostituita (operazione di label swap) hop-by-hop lungo il percorso del pacchetto MPLS in base alla LFIB di ogni router MPLS.

Vediamo ora l'aspetto chiave dell'architettura Seamless MPLS, la realizzazione di LSP MPLS inter-dominio. Facciamo un nuovo schema di principio per mettere in evidenza come viene organizzato il funzionamento del BGP per il trasporto end-to-end dei servizi, dimenticandoci per il momento che il BGP è anche utilizzato, nel contesto dei servizi e per la maggior parte dei casi, per segnalare Service Label. Per fissare le idee consideriamo il seguente schema:

Supponiamo di voler mettere in comunicazione due Loopback/32, appartenenti alla Global Routing Table rispettivamente dei router PE1 e PE2. Teniamo presente che quando vogliamo realizzare un servizio, ci interessiamo in prima battuta alla raggiungibilità reciproca delle Loopback dei nodi PE interessati. 

Descriviamo il ruolo dei router:

• RR: è un router del dominio Core dedicato alla funzione di Route Reflection; anche se non rappresentato in figura, generalmente è presente, per motivi di ridondanza, almeno un secondo RR.
• Inline-RR: è un Border Node BGP/MPLS (talvolta anche detto PE-ASBR) che si occupa anche di BGP Route Reflection ed è client del Route Reflector RR (Route Reflection gerarchico).
• PE1 e PE2 sono due SN BGP/MPLS, client degli Inline-RR, sui quali poi configureremo in un secondo momento dei servizi (L2VPN, L3VPN ecc.).

Supponiamo di stabilire delle sessioni MP-iBGP "IPv4 + Label" (AFI/SAFI = 1/4) come in figura, con la particolarità che gli Inline-RR devono variare l’attributo BGP NEXT_HOP, in quanto è proprio la variazione dell’attributo BGP NEXT_HOP che fa da trigger a una nuova allocazione di etichetta MPLS. Un determinato InLine-RR costituirà poi effettivamente un transito MPLS per una certa destinazione, se appartiene al best-path per quella destinazione. 

Una volta configurata questa quota-parte di piano di controllo BGP, il router PE1 annuncerà via iBGP la propria "Loopback /32 + label MPLS" e riceverà via iBGP gli annunci relativi al prefisso "Loopback /32 di PE2 + label MPLS" associata e ne selezionerà il best-path; anche PE2 annuncerà via iBGP la propria "Loopback /32 + label MPLS" e riceverà via iBGP gli annunci relativi al prefisso "Loopback /32 di PE1 + label MPLS" associata e ne selezionerà il best-path.

Detto ciò, le due Loopback di PE1 e PE2 diventano connesse tra loro a Livello 3 e inoltre PE1 può stabilire con PE2 un LSP MPLS inter-dominio, che è il risultato dell'unione di tre sub-LSP, rispettivamente nei tre diversi domini MPLS, e i punti di unione sono i BN. Per vedere come questo avviene, facciamo un esempio che visualizza gli annunci sul piano di controllo e il label stack MPLS piano dati, con trasporto di un servizio (SL = Service Label, TLx = Transport Label x annunciata attraverso messaggi LDP Label Mapping, Lx = Label annunciata via MP-iBGP e associata a BNx).

Lasciamo al lettore l'analisi dei dettagli.

Qui termina la prima parte del post. Arrivederci al prossimo, dove passeremo dalla poesia (la teoria), alla prosa (aspetti pratici di configurazione con l’IOS-XR Cisco in una rete di laboratorio).