VXLAN + EVPN: lab test in ambiente Cisco Nexus - Parte III - Interconnessione DC-L3VPN

Questo post è il seguito dei due precedenti "VXLAN + EVPN: lab test in ambiente Cisco Nexus - Parte I e Parte II" che potete trovare a questo link (Parte I) e a questo link (Parte II).

In questo post illustrerò come interconnettere un tenant di un Data Center con una L3VPN esterna, sempre dello stesso tenant. Poiché il post è molto lungo sarà diviso in due parti.

ARCHITETTURE DI INTERCONNESSIONE

L’interconnessione di un Data Center con le reti esterne avviene attraverso dei nodi specifici detti Border Node (BN). I BN vengono tipicamente utilizzati per l’interconnessione di Livello 3 ma ne è anche possibile l’utilizzo per l’interconnessione a Livello 2. 

Il BN in se è un normale nodo di edge che ha anche la funzione VTEP, che consente l’incapsulamento VXLAN del traffico L2/L3 proveniente dalle reti esterne per il trasporto all’interno della IP Fabric, e viceversa il decapsulamento del traffico diretto verso le reti esterne. 

Rispetto ai nodi della IP Fabric ha solo un diverso focus, e di solito non ha Host connessi, anche se nulla vieta che vi siano. Il generico nodo di edge di una IP Fabric (Leaf) fornisce connettività agli Host e svolge per questi il ruolo di first-hop router, un BN d’altro canto è invece un nodo di transito che svolge funzioni di interconnessione. 

Da un punto di vista squisitamente progettuale è buona regola che queste diverse funzioni di edge siano svolte da nodi separati. Separare i ruoli semplifica le operazioni di esercizio, e non sovraccarica gli altri nodi di ulteriori funzioni complesse. 

Mentre i classici nodi Leaf sono responsabili del traffico interno al Data Center, di solito chiamato traffico server-to-server o anche Est-Ovest, i BN sono responsabili invece del traffico da/verso l’esterno, di solito chiamato traffico Nord-Sud.

Vi sono due opzioni per la collocazione dei BN all’interno di una IP Fabric. La prima è quella di integrare la funzione di BN in qualche switch Spine (almeno due per ridondanza), e in questo caso di parla di Border Spine, la seconda è invece quella di utilizzare dei nodi Leaf specializzati, che vengono chiamati Border Leaf. 

La scelta di utilizzare Border Leaf o in alternativa Border Spine, o una soluzione ibrida, è un aspetto critico di progettazione. Nel seguito illustrerò i pro e contro delle due soluzioni. 

BORDER NODE NEGLI SWITCH SPINE

Integrare la funzione BN in uno switch Spine è efficiente per quanto riguarda il traffico nord-sud, poiché questo tipo di traffico transita su un solo nodo prima di uscire verso l’esterno, e questo comporta ovviamente minore ritardo end-to-end. Quindi integrare la funzione di BN in uno Spine è vantaggioso quando il traffico Nord-Sud è preponderante rispetto al traffico Est-Ovest.

Il prezzo da pagare è che anche gli Spine, oltre alle funzioni che normalmente gli vengono assegnate, come ad esempio la funzione di Route Reflection e quella di Rendezvous-Point per il traffico multicast, devono avere la funzione VTEP. 

Inoltre, ogni switch Spine deve avere almeno un paio di interfacce aggiuntive per l’interconnessione verso l’esterno, e in funzione del traffico anche di più, per poter avere banda sufficiente a gestire il traffico esterno. E questi sono aspetti da valutare accuratamente in fase di progetto, per poter dimensionare correttamente gli switch Spine.

BORDER NODE NEGLI SWITCH LEAF

L’opzione alternativa all’integrazione della funzione di BN in uno switch Spine, è quella di assegnare la funzione a Leaf specializzati (Border Leaf). 

In teoria, la funzione può essere anche integrata negli switch Leaf "normali" (ossia, dove sono attestati i server), ma non è consigliabile per vari motivi, tra cui il fatto che alcune porte andrebbero sottratte ai server per il transito del traffico Nord-Sud, e per evitare su uno stesso Leaf un mix di traffico Est-Ovest e Nord-Sud.

Utilizzare Border Leaf separati comporta vantaggi in termini di scalabilità e quindi di banda disponibile, e poi porta ad una separazione chiara tra traffico Est-Ovest e Nord-Sud.

Lo svantaggio di utilizzare Border Leaf rispetto all’utilizzo di Border Spine, è che il traffico Nord-Sud soffre di maggiore ritardo, poiché deve transitare su un nodo in più (Leaf → Spine → Border Leaf). Ma se il traffico Nord-Sud è una modesta porzione del traffico totale dei Data Center, come di norma avviene in quelli più moderni, questo non causa grossi problemi.

MODELLO DI INTERCONNESSIONE VRF-LITE (INTER-AS OPTION A)

Un primo modello di interconnessione, che consente di estendere la multi-tenancy su una rete esterna IP/MPLS, è quello di utilizzare un modalità simile a quella nota come "Option A" utilizzata nel servizio L3VPN inter-AS 

NOTA: in alcuni documenti questo modello è anche chiamato un po’ impropriamente modello VRF-Lite. Impropriamente poiché le VRF utilizzate non sono VRF-Lite, ma le classiche VRF utilizzate nel servizio L3VPN sulle reti IP/MPLS.

L’idea di fondo è molto semplice, sui nodi di interconnessione, BN lato Data Center, e PE-ASBR lato rete IP/MPLS va configurata una VRF per singolo tenant. Le interfacce del link tra BN e PE-ASBR vanno quindi associate a queste VRF, e questo consente al BN di vedere il PE-ASBR come fosse un CE, e viceversa, consente al PE-ASBR di vedere il BN come fosse un CE. Sul link BN↔PE-ASBR fluirà quindi traffico IP convenzionale, e l’eventuale adiacenza di routing o sessione eBGP configurata trasporteranno informazioni di routing IP base.

Il problema di questo modello di interconnessione è che è poco scalabile poiché su ciascun PE-ASBR bisogna in ogni caso attivare una VRF del tenant, anche se il tenant non ha sul PE-ASBR alcun CE connesso. E poi la complessità di configurazione, in Data Center di grandi dimensioni potrebbe essere proibitiva. Discorso diverso è per i Data Center di piccole dimensioni, dove questo metodo ha il vantaggio della semplicità di applicazione.

La figura seguente mostra i principi di funzionamento del piano di controllo nel caso (molto comune, anzi consigliato) di utilizzo del BGP come protocollo di routing di interconnessione. Gli annunci eBGP IPv4/IPv4 provenienti dalla rete IP/MPLS (dal PE1 nella figura), verranno trasformati dal BN in annunci BGP EVPN di tipo 5, e quindi inviati a tutti i nodi Leaf. Viceversa, gli annunci BGP EVPN sia di tipo 2 (solo per quanto riguarda la parte IP !) che tipo 5, verranno trasformati in normali annunci eBGP e quindi inviati al PE-ASBR (PE1 nella figura), che a sua volta li trasforma in annunci MP-iBGP di tipo VPN-IPv4/v6 e li inoltra, secondo le regole classiche, agli altri PE della rete IP/MPLS. 

Si noti un aspetto importante. Di default il BN invia al PE-ASBR tutti gli annunci /32 (Host Route) dei singoli Host del Data Center, che potrebbero essere dell’ordine delle migliaia o molti di più. È buona regola quindi, per evitare di sovraccaricare le tabelle di routing associate alle VRF lato rete IP/MPLS, eseguire sui BN una operazione di aggregazione con soppressione delle Host Route, in modo da inviare alla rete IP/MPLS le sole subnet IP e non le singole Host Route. In un piano di numerazione ben fatto, al limite sarebbe sufficiente un solo annuncio aggregato (la prova è lasciata come esercizio al lettore).

Sul piano dati, all’interno della IP Fabric del Data Center il traffico verrà incapsulato utilizzando VXLAN, mentre nella rete IP/MPLS seguirà il classico incapsulamento MPLS over MPLS (ossia con una service label e una transport label). Si noti che nella rete IP/MPLS è direttamente il pacchetto IP ad essere incapsulato, mentre nel Data Center è l’intera trama Ethernet che viaggia incapsulata in VXLAN.

MODELLO DI INTERCONNESSIONE L3VPN HAND-OFF

Questo modello di interconnessione è per certi versi simile al modello Inter-AS "Option A" visto nella sezione precedente. La differenza è che in questo modello le funzioni di BN e PE-ASBR collassano in una singola macchina, che viene chiamata Border PE. 

Le informazioni di routing che il Border PE riceve dalla rete IP/MPLS sono in questo caso direttamente annunci MP-iBGP di tipo VPN-IPv4/v6. Il Border PE trasforma questi annunci in annunci BGP EVPN di tipo 5 e li invia ai nodi Leaf (eventualmente tramite dei Route Reflector).

Viceversa, gli annunci di tipo 2 (solo per la parte IP) e tipo 5 ricevuti dal Border PE dall’interno del Data Center, vengono trasformati da questo in annunci MP-eBGP (e non MP-iBGP !) VPNv4/v6 e quindi inviati secondo le tecniche usuali, agli altri PE della rete IP/MPLS. 

Si noti l’aspetto importante che il Border PE in questo modello di funzionamento appartiene all’AS del Data Center, e vede gli altri PE della rete IP/MPLS come MP-eBGP peers. Ma questo non crea alcun problema (la prova è lasciata come esercizio).

Un aspetto importante da tener presente è la gestione dei Route Target, che comunque segue le regole usuali. Nel prossimo post vedremo un Case Study dove metteremo in luce questo problema.

DALLA POESIA ALLA PROSA (OSSIA, DALLA TEORIA ALLA PRATICA)

A questo punto non rimane che passare all'azione, ossia implementare l'interconnessione DC-L3VPN sul nostro laboratorio costituito da Cisco Nexus della serie 9k. Ma poiché come disse Forrest Gump, "sono un po' stanchino", rimando la prosa al prossimo post.