PREMESSA: Questo post riflette le idee dell'autore e non vuole essere in alcun modo un veicolo di propaganda di quanto esposto. Per la scrittura di questo post, del precedente e dei successivi sull'argomento, né io personalmente, né la società di cui faccio parte, abbiamo ricevuto alcunché da Juniper Networks.
In un post precedente ho introdotto l'architettura di OpenContrail e le sue componenti fondamentali. Una delle applicazioni più importanti di soluzioni SDN come OpenContrail, è l’accesso da remoto a un Cloud privato. I Cloud Service Provider offrono una varietà di servizi di questo tipo: Infrastructure as a Service (IaaS), Platform as Service (PaaS), o Software as a Service (SaaS). O, mettendo tutto insieme, XaaS. Gli ISP tradizionali possono offrire l'accesso da remoto a questi servizi, ai loro Clienti che hanno servizi L3VPN/L2VPN sulla loro rete.
In un post precedente ho introdotto l'architettura di OpenContrail e le sue componenti fondamentali. Una delle applicazioni più importanti di soluzioni SDN come OpenContrail, è l’accesso da remoto a un Cloud privato. I Cloud Service Provider offrono una varietà di servizi di questo tipo: Infrastructure as a Service (IaaS), Platform as Service (PaaS), o Software as a Service (SaaS). O, mettendo tutto insieme, XaaS. Gli ISP tradizionali possono offrire l'accesso da remoto a questi servizi, ai loro Clienti che hanno servizi L3VPN/L2VPN sulla loro rete.
OpenContrail supporta due modalità di funzionamento, L3-only e L2-L3. La prima è la più semplice e così in questo post inizierò un Case Study per illustrare il funzionamento di questa modalità. In un post successivo, facendo un po' di violenza a me stesso, illustrerò la modalità ibrida L2-L3. Il Case Study è ispirato all'identico Case Study illustrato nel libro "MPLS in the SDN era", di Antonio Sánchez-Monge e Krzysztof Grzegorz Szarkowicz. Lo abbiamo riprodotto nel nostro laboratorio della Reiss Romoli, grazie alla pazienza e alla perizia del mio co-blogger Lorenzo Salvatore e del nostro tesista Alessandro Consalvi.
SCENARIO
Vediamo in dettaglio i componenti dello scenario, illustrato nella figura seguente, partendo da destra verso sinistra.
Le VM (o eventualmente, dei Linux Container) sono assimilabili a dei CE. Queste sono completamente ignare della OVN, e inviano e ricevono normalissime trame Ethernet, che sono tipicamente untagged.
I vRouter sono assimilabili a dei PE, che possono svolgere il ruolo di PE EVPN o di un classico PE L3VPN.
Il router DC-GW (abbreviazione per Data Center Gateway) è un ASBR (Autonomous System Boundary Router) per il Data Center, e implementa le funzioni di inter-AS ASBR (Opzione B) per il collegamento con la rete IP/MPLS dove sono realizzati i servizi L3VPN. Per chi non fosse familiare con il servizio L3VPN inter-AS (anche noto come VPN Multiprovider), a questo link potete scaricare un estratto della mia documentazione che utilizzo nei corsi avanzati su MPLS, che tratta le modalità di realizzazione e gli aspetti di configurazione del servizio.
Infine, a sinistra c’è una classica rete ISP che offre servizi BGP/MPLS. A questa rete sono attestati CE remoti che fanno parte della stessa OVN a cui appartengono le VM a destra. La rete dell'ISP (AS 65000) si interconnette al Data Center (AS65001), tramite il router ASBR.
OpenContrail fornisce gli strumenti per la comunicazione tra VM all’interno del Data Center e tra VM e Host attestati a CE della L3VPN BGP/MPLS. Questo consente a VM realizzate sullo stesso o su diversi Compute Node di comunicare tra loro, e a Clienti esterni al Data Center, di accedere ad applicazioni presenti nelle VM definite all’interno del Data Center.
La figura seguente illustra il piano di numerazione adottato nel Case Study.
Il piano di numerazione riguarda due OVN, denominate Red e Blue. Sono visibili due tipi di indirizzi:
- Indirizzi IPv4 infrastrutturali (10.0.10.x/31), che risiedono nella tabella di routing globale e forniscono la connettività L3 tra Compute Node, via rete underlay (IP Fabric).
- Indirizzi della OVN (10.1.1.0/24, 10.2.2.0/24). Questi corrispondono rispettivamente a Host attestati ai CE della L3VPN e alle VM. Si noti che i piani di numerazione delle OVN Red e Blue sono perfettamente identici (sovrapposti). Ma questo non è un problema, d’altra parte Red e Blue sono due OVN !
Uno degli aspetti più interessanti del piano di indirizzamento della figura è che l'indirizzo 10.2.2.1 è presente più volte nella stessa OVN sul vRouter. OpenContrail assegna i primi due indirizzi di ciascuna subnet IP rispettivamente al default gateway e al DNS delle VM. Ad esempio, nelle OVN Red e Blue, poiché la subnet IP associata è per entrambe 10.2.2.0/24, i due indirizzi in questione sono rispettivamente 10.2.2.1 e 10.2.2.2. Ad entrambi gli indirizzi, OpenContrail associa un identico indirizzo MAC, 00:00:5e:00:01:00.
REALIZZAZIONE DEL CLOUD PRIVATO
Vediamo ora, passo per passo, il processo che consente di realizzare un Cloud privato. Sebbene siano possibili altre opzioni, assumeremo che il sistema di orchestrazione sia basato su OpenStack.
Il primo passo amministrativo è la creazione di un progetto con il modulo Horizon di OpenStack: Admin → Identity → Projects (NOTA: per chi non fosse familiare con la suite OpenStack, Horizon è il modulo che fornisce l’interfaccia utente via web per amministratori e utenti finali; comunque tranquilli, a breve il mio co-blogger Lorenzo Salvatore pubblicherà un post su OpenStack). L’esempio utilizza un progetto il cui nome è reisslab-test-contrail. Un progetto è tipicamente associato a un tenant (= cliente), e supporta una o più OVN.
Nel contesto del nuovo progetto, si definiscono, tramite la OpenContrail GUI, le due OVN Red e Blue: Configure → Networking → Networks. Una OVN può essere pensata come un insieme di subnet IP, con alcune proprietà aggiuntive: zero o più Route Target (RT), un VXLAN VNI, e altro. Ciascuna di queste subnet può essere divisa (micro-segmentata !) in indirizzi /32, che sono assegnati ai collegamenti VM↔vRouter (= CE↔PE). (NOTA: la definizione delle due OVN potrebbe anche essere realizzata via OpenStack, con la sequenza di voci: Project → Other → Networking → Networks).
A partire dal modulo Horizon di OpenStack , utilizzando il modulo Nova, si definiscono e si istanziano le VM: Project → Instances → Launch Instance. Le figure seguenti mostrano la procedura (solo parziale per motivi di spazio) su OpenStack per attivare la VM Red_1A (NOTA: il flavor "m1.tiny" è una delle configurazioni di default delle VM presenti nella versione Mitaka di OpenStack. In particolare il flavor "m1.tiny" ha i seguenti parametri: numero di vCPU = 1, Disco = 1 GB, RAM = 512 MB. Nella nuova versione Newton di OpenStack, non esistono flavor di default.)
Ciascuna VM ha una interfaccia (vNIC), connessa a una tap interface (una interfaccia software !) del vRouter. La vNIC e la tap interface sono i due estremi del collegamento VM↔vRouter. Entrambe queste interfacce sono collegate tra loro virtualmente via software e il link viene realizzato non appena la VM viene istanziata. Ciascuna tap interface in un vRouter appartiene a una sola OVN, ed è connessa a una singola VM.
Come nelle VRF dei PE classici, una OVN può avere route locali e remote. Inoltre, un CE classico può avere più uplink, ciascuno connesso alla stessa VRF o a VRF diverse nello stesso PE. Allo stesso modo una VM può avere più vNIC, ciascuna connessa a diverse OVN (VRF) del vRouter. Nel nostro semplice Case Study, ogni VM ha una sola vNIC.
ASSEGNAZIONE DEGLI INDIRIZZI IP E MAC ALLE VM
Le vNIC ottengono gli indirizzi IP (v4/v6) e gli indirizzi MAC dal Control Node di OpenContrail. Il Case Study prevede l'attivazione di 5 VM, ciascuna con la sua vNIC, di cui tre appartengono alla OVN Red (Red_1A, Red_1B e Red_2A) e due appartengono alla OVN Blue (Blue_1A e Blue_2A).
Come ci si aspetta da una OVN, le tre VM nella OVN Red devono poter comunicare tra loro, ma non con le VM nella OVN Blue (almeno di default !). Quando viene creata una nuova VM, l'orchestratore, che nel nostro Case Study è OpenStack, comunica la mappa vNIC-to-OVN al Control Node di OpenContrail, e sulla base di tali informazioni, quest'ultimo assegna a ciascuna vNIC sia l'indirizzo IP (v4/v6) che l'indirizzo MAC.
Come visto nel post precedente sugli aspetti architetturali di OpenContrail, la comunicazione tra il vRouter e il Control Node di OpenContrail avviene attraverso il protocollo XMPP. Una delle funzioni principali di XMPP in OpenContrail è l’assegnazione degli indirizzi di rete (MAC e IP) a ciascuna VM (o vNIC, è equivalente), inclusa la OVN a cui appartiene, ed eventuali policy di sicurezza e sul traffico. Questa informazione consente al vRouter di agire come DHCP server nei confronti della VM, come mostrato nella figura seguente.
In particolare lo scambio contempla due messaggi:
<?xml version="1.0"?>
<iq type="set" from="vrouter_1"
to="network-control@contrailsystems.com/config">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscribe node="virtual-machine: 71d68b44-625e-4aca-81e0-fa02c80da6b3"/>
</pubsub>
</iq>
Come ci si aspetta da una OVN, le tre VM nella OVN Red devono poter comunicare tra loro, ma non con le VM nella OVN Blue (almeno di default !). Quando viene creata una nuova VM, l'orchestratore, che nel nostro Case Study è OpenStack, comunica la mappa vNIC-to-OVN al Control Node di OpenContrail, e sulla base di tali informazioni, quest'ultimo assegna a ciascuna vNIC sia l'indirizzo IP (v4/v6) che l'indirizzo MAC.
Come visto nel post precedente sugli aspetti architetturali di OpenContrail, la comunicazione tra il vRouter e il Control Node di OpenContrail avviene attraverso il protocollo XMPP. Una delle funzioni principali di XMPP in OpenContrail è l’assegnazione degli indirizzi di rete (MAC e IP) a ciascuna VM (o vNIC, è equivalente), inclusa la OVN a cui appartiene, ed eventuali policy di sicurezza e sul traffico. Questa informazione consente al vRouter di agire come DHCP server nei confronti della VM, come mostrato nella figura seguente.
In particolare lo scambio contempla due messaggi:
- XMPP Subscribe Request: questo messaggio è generato dal Control Agent in vRouter_1, ed è diretto al Control Node di OpenContrail (vedi linee 2 e 3 nel listato che segue). Il suo invio avviene a valle della creazione della VM Red_1A nel contesto del modulo Nova di OpenStack. Si noti che l’identificativo della VM utilizzato in OpenStack non è molto user-friendly, e viene generato automaticamente (linea 5 del listato).
- XMPP Configuration Update: questo messaggio è generato dal Control Node di OpenContrail ed è diretto al Control Agent in vRouter_1. Contiene come informazioni gli indirizzi MAC e IP da assegnare alla VM, la OVN di appartenenza, ed eventualmente anche altro. Non appena ricevute queste informazioni, il vRouter è in grado di svolgere le funzioni di DHCP server e quindi in grado di rispondere ai messaggi DHCP Discover inviati al vRouter dalla VM.
<?xml version="1.0"?>
<iq type="set" from="vrouter_1"
to="network-control@contrailsystems.com/config">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscribe node="virtual-machine: 71d68b44-625e-4aca-81e0-fa02c80da6b3"/>
</pubsub>
</iq>
A questo punto, ogni VM creata ha un suo indirizzo IP e un suo indirizzo MAC, e il vRouter conosce a quale OVN appartiene la VM attivata. Il prossimo passo è vedere come le VM di una stessa OVN possono comunicare tra loro. Ma prima è necessario illustrare un trucco diabolico ...
CONNETTIVITA' VM-VM
Per primo illustrerò il caso della connettività tra VM della stessa OVN, per ipotesi attivate su Compute Node diversi, e quindi collegate a vRouter diversi.
Dalla prospettiva della VM Red_1A, vRouter_1 svolge il ruolo di server DHCP, di default gateway, e di server DNS. Ora che la VM Red_1A ha una interfaccia con un indirizzo IPv4, può comunicare con il mondo esterno. Si può dire la stessa cosa di vRouter_1 ? Vediamo quindi come un vRouter comunica con altri vRouter e nella prossima sezione, come comunica con il DC-GW.
Nel contesto SDN, probabilmente la funzione più importante di XMPP è la sua capacità di comportarsi ed eseguire le stesse funzioni del Multiprotocol BGP (MP-BGP) nelle L3VPN. XMPP è potente e scalabile come il BGP e ha la stessa estendibilità di XML. A differenza del BGP, che è principalmente un protocollo Est-Ovest (ossia utilizzato per il colloquio con le macchine fisiche), XMPP trova applicazione come protocollo "lato sud" (southbound), ossia nel colloquio tra Control Node e vRouter. Questa applicazione di XMPP come protocollo BGP-like è definita nel draft IETF "draft-ietfl3vpn-end-system - BGP-signaled end-system IP/VPNs". Come illustrerò in un prossimo post, è facile estendere XMPP anche alla segnalazione delle EVPN.
La figura seguente illustra come vRouter_1 e vRouter_2 dapprima richiedono al Control Node, attraverso un messaggio XMPP Subscribe Request, la necessità di realizzare la routing instance Red:Red, e quindi si scambiano le VM Host Route attraverso il Control Node, utilizzando messaggi XMPP Publish Request e XMPP Update Notification.
Non appena istanzia la prima VM con un link nella OVN Red, vRouter_1 mostra interesse a ricevere le Host Route della OVN Red, inviando un messaggio XMPP Subscribe Request al Control Node. In soldoni, questo è quanto comunica vRouter_1 al Control Node: "ora che devo fornire connettività alle VM con vNIC nella OVN Red, ho bisogno di conoscere tutte le host route della OVN, quindi per favore inviamele".
vRouter_1 ha una tap interface connessa alla VM Red_1A. Il vRouter_1 agent assegna una service label MPLS a questa tap interface, seguendo un modello di allocazione per-CE. Dopo l'assegnazione della service label MPLS alla tap interface a cui è (virtualmente) collegata la VM Red_1A, il vRouter_1 agent annuncia al Control Node la host route 10.2.2.101/32, con associati BGP Next-Hop (= 10.0.10.11), service label MPLS (= 54) e tipo di incapsulamento da utilizzare sul piano dati (MPLS-over-GRE oppure MPLS-over-UDP, default MPLS-over-UDP), utilizzando un messaggio XMPP Publish Request (vedi figura), diretto al Control Node. Questo messaggio può essere visto come un equivalente di un classico messaggio BGP Update.
Il Control Node agisce a questo punto come un Route Reflector: centralizza la segnalazione BGP, ma non è sul forwarding path del traffico. Il risultato è che il Control Node riflette a vRouter_2 il messaggio XMPP Publish Request, sotto forma di messaggio XMPP Update Notification, senza cambiare alcunché (come farebbe un classico Route Reflector !). I messaggi XMPP Publish Request e XMPP Update Notification, assomigliano entrambi a classici messaggi BGP Update, e hanno il nome che dipende dalla direzione in cui vanno. I messaggi XMPP Publish Request vanno verso "Nord" (vRouter → Control Node), mentre i messaggi XMPP Update Notification vanno verso "Sud" (Control Node → vRouter).
A questo punto, entrambi i vRouter hanno le informazioni necessarie per il forwarding del traffico. Per concludere, illustrerò passo-passo cosa avviene quando la VM Red_2A, connessa al vRouter_2, invia un pacchetto IP alla VM Red_1A, connessa al vRouter_1.
LA FUNZIONE ARP PROXY
Le tap interface, oltre ad avere tutte lo stesso indirizzo IP (che corrisponde all’indirizzo IP del default gateway), hanno tutte un identico indirizzo MAC (assegnato da OpenContrail), coincidente con quello assegnato al default gateway visto sopra, 00:00:5e:00:01:00.
Avere un unico indirizzo IP e un unico indirizzo MAC per il default gateway, fornisce le condizioni ideali per una mobilità seamless delle VM tra Compute Node. Uno scenario simile è quello dell'inter-VXLAN routing, che come già visto in questo post, viene facilitato dall'avere un unico indirizzo IP e un unico indirizzo MAC per il default gateway (distributed anycast IP default gateway).
Un altro aspetto intrigante (e intelligente) dell’assegnare lo stesso indirizzo MAC a tutte le tap interface, nella modalità OpenContrail L3-only, è la gestione dei messaggi ARP.
Supponiamo che la VM Red_1A invii al vRouter_1 un messaggio ARP Request, per risolvere l'indirizzo IP 10.2.2.102 (di Red_2A). Nell'ipotesi che vRouter_1 abbia appreso in qualche modo la host route 10.2.2.102/32 (illustrerò nel seguito come questo avviene), vRouter_1 risponde con un ARP Reply alla VM Red_1A, fornendo l'indirizzo MAC comune assegnato a tutte le tap interface (= 00:00:5e:00:01:00). Il vRouter_1 svolge quindi una funzione di ARP proxy.
Così facendo, l’instradamento del traffico avviene completamente a Livello 3. Infatti, un eventuale pacchetto IP generato dalla VM Red_1A, viene incapsulato in una trama Ethernet con MAC destinazione l’indirizzo MAC comune a tutte le tap interface (= 00:00:5e:00:01:00), e MAC sorgente l'indirizzo MAC assegnato alla propria vNIC. Alla ricezione della trama Ethernet, il vRouter decapsula immediatamente la trama Ethernet, e quindi effettua un lookup (di Livello 3) sulla tabella di routing IP, da dove evince tutte le informazioni per il forwarding. Rimane aperto il problema di come il vRouter ottiene queste informazioni, e questo è l'argomento della prossima sezione.
CONNETTIVITA' VM-VM
Per primo illustrerò il caso della connettività tra VM della stessa OVN, per ipotesi attivate su Compute Node diversi, e quindi collegate a vRouter diversi.
Dalla prospettiva della VM Red_1A, vRouter_1 svolge il ruolo di server DHCP, di default gateway, e di server DNS. Ora che la VM Red_1A ha una interfaccia con un indirizzo IPv4, può comunicare con il mondo esterno. Si può dire la stessa cosa di vRouter_1 ? Vediamo quindi come un vRouter comunica con altri vRouter e nella prossima sezione, come comunica con il DC-GW.
Nel contesto SDN, probabilmente la funzione più importante di XMPP è la sua capacità di comportarsi ed eseguire le stesse funzioni del Multiprotocol BGP (MP-BGP) nelle L3VPN. XMPP è potente e scalabile come il BGP e ha la stessa estendibilità di XML. A differenza del BGP, che è principalmente un protocollo Est-Ovest (ossia utilizzato per il colloquio con le macchine fisiche), XMPP trova applicazione come protocollo "lato sud" (southbound), ossia nel colloquio tra Control Node e vRouter. Questa applicazione di XMPP come protocollo BGP-like è definita nel draft IETF "draft-ietfl3vpn-end-system - BGP-signaled end-system IP/VPNs". Come illustrerò in un prossimo post, è facile estendere XMPP anche alla segnalazione delle EVPN.
La figura seguente illustra come vRouter_1 e vRouter_2 dapprima richiedono al Control Node, attraverso un messaggio XMPP Subscribe Request, la necessità di realizzare la routing instance Red:Red, e quindi si scambiano le VM Host Route attraverso il Control Node, utilizzando messaggi XMPP Publish Request e XMPP Update Notification.
Non appena istanzia la prima VM con un link nella OVN Red, vRouter_1 mostra interesse a ricevere le Host Route della OVN Red, inviando un messaggio XMPP Subscribe Request al Control Node. In soldoni, questo è quanto comunica vRouter_1 al Control Node: "ora che devo fornire connettività alle VM con vNIC nella OVN Red, ho bisogno di conoscere tutte le host route della OVN, quindi per favore inviamele".
vRouter_1 ha una tap interface connessa alla VM Red_1A. Il vRouter_1 agent assegna una service label MPLS a questa tap interface, seguendo un modello di allocazione per-CE. Dopo l'assegnazione della service label MPLS alla tap interface a cui è (virtualmente) collegata la VM Red_1A, il vRouter_1 agent annuncia al Control Node la host route 10.2.2.101/32, con associati BGP Next-Hop (= 10.0.10.11), service label MPLS (= 54) e tipo di incapsulamento da utilizzare sul piano dati (MPLS-over-GRE oppure MPLS-over-UDP, default MPLS-over-UDP), utilizzando un messaggio XMPP Publish Request (vedi figura), diretto al Control Node. Questo messaggio può essere visto come un equivalente di un classico messaggio BGP Update.
Il Control Node agisce a questo punto come un Route Reflector: centralizza la segnalazione BGP, ma non è sul forwarding path del traffico. Il risultato è che il Control Node riflette a vRouter_2 il messaggio XMPP Publish Request, sotto forma di messaggio XMPP Update Notification, senza cambiare alcunché (come farebbe un classico Route Reflector !). I messaggi XMPP Publish Request e XMPP Update Notification, assomigliano entrambi a classici messaggi BGP Update, e hanno il nome che dipende dalla direzione in cui vanno. I messaggi XMPP Publish Request vanno verso "Nord" (vRouter → Control Node), mentre i messaggi XMPP Update Notification vanno verso "Sud" (Control Node → vRouter).
A questo punto, entrambi i vRouter hanno le informazioni necessarie per il forwarding del traffico. Per concludere, illustrerò passo-passo cosa avviene quando la VM Red_2A, connessa al vRouter_2, invia un pacchetto IP alla VM Red_1A, connessa al vRouter_1.
- La VM Red_2A invia un messaggio ARP Request al vRouter_2, per ottenere l'indirizzo MAC della VM Red_1A. L'indirizzo IP target è quindi 10.2.2.101.
- Il vRouter_2 risponde direttamente, senza propagare il messaggio ARP request (funzione di ARP proxy), con l'indirizzo MAC (fittizio) comune assegnato a tutte le tap interface (= 00:00:5e:00:01:00).
- La VM Red_2A invia quindi un pacchetto IP, con IP sorgente l'indirizzo della propria vNIC (=10.2.2.102) e indirizzo IP destinazione l'indirizzo della vNIC di Red_1A. Il pacchetto IP viene quindi incapsulato in una trama Ethernet (untagged), con MAC sorgente l'indirizzo MAC della propria vNIC e indirizzo MAC destinazione 00:00:5e:00:01:00.
- Il vRouter_2 decapsula il pacchetto IP ed esegue un lookup sulla tabella di routing IP (perché il MAC destinazione è quello del default gateway), dove trova tutte le informazioni per il forwarding: service label MPLS = 54, Next-Hop = 10.0.10.11 e tipo di incapsulamento da adottare (che supporrò essere quello di default, MPLS-over-UDP, ma il tipo di incapsulamento è assolutamente ininfluente).
- Il vRouter_2 aggiunge al pacchetto IP la service label MPLS (= 54), un header UDP con porta destinazione well-known 6635 (vedi RFC 7510), e porta sorgente random, ma nell'intervallo [49.152, 65.535]. La porta sorgente è tipicamente determinata con una funzione di hash, per aumentare l'entropia per il load balancing del traffico (in modo simile, ma non uguale, a quanto avviene per l'incapsulamento VXLAN). Infine aggiunge una intestazione IP, con IP sorgente il proprio indirizzo (= 10.0.10.22, vedi figura sopra) e indirizzo IP destinazione l'indirizzo del campo Next-Hop contenuto nel messaggio XMPP Update Notification ricevuto dal Control Node (= 10.0.10.11).
- Il pacchetto IP risultante viene inviato alla IP Fabric, che lo instrada al vRouter_1, secondo le regole canoniche del forwarding IP.
- Il vRouter_1, sulla base del valore della porta UDP destinazione (= 6635), decapsula la componente IP+UDP, verifica l'etichetta MPLS (= 54), e poiché questa è associata alla tap interface verso la VM Red_1A, toglie l'etichetta MPLS e invia il pacchetto IP risultante verso la VM Red_1A. In realtà, il vRouter_1 esegue un'ultima operazione di incapsulamento, secondo me completamente inutile, ma necessaria (purtroppo), che vi lascio immaginare come esercizio.
Le VM di una stessa OVN, anche se attivate su Compute Node diversi, sono così connesse a Livello 3. Per concludere il Case Study, farò vedere infine come si realizza la connettività di Livello 3 tra un Host attestato a un CE della L3VPN Red, 3 una VM del Cloud privato, sempre appartenente alla OVN Red.
CONNETTIVITA' TRA HOST L3VPN E VM
L'aspetto "magico" di questa soluzione di interconnessione tra L3VPN tradizionale e Cloud è che non appena viene attivata una nuova VM in un Data Center, o un nuovo sito della L3VPN si connette alla rete di un ISP, questi hanno raggiungibilità L3 end-to-end. Nessun dispositivo di rete ha bisogno di configurazioni aggiuntive: tutto ciò che serve è l'Overlay Virtual Networking, combinato con un uso nel complesso "classico" del BGP.
Il router ASBR è parte della rete dell'ISP e ha sessioni MP-iBGP con i Route Reflector presenti all'interno della rete dell'ISP (address-family = L3VPN), e una sessione MP-eBGP con il DC-GW. Il resto della segnalazione è mostrato nella figura seguente. Il Control Node di OpenContrail si comporta come un Route Reflector di tipo Multi Protocol, e colloquia via XMPP con i vRouter Agent e via iBGP classico con il Data Center Gateway (DC-GW), convertendo il formato degli annunci in modo appropriato. Vi faccio notare che il fatto che il DC-GW annunci una etichetta MPLS (service label) diversa da quella ricevuta dall'ASBR, e viceversa, rientra nel funzionamento del servizio VPN multiprovider, Opzione B.
NOTA: i prefissi BGP originati da OpenContrail hanno un RD (Route Distinguisher) generato automaticamente nel formato <ROUTER_ID>:<VPN_ID>, in modo da supportare il Load Balancing del traffico inbound tra diversi vRouter. La spiegazione di questa affermazione è lasciata come esercizio !
OpenContrail annuncia i prefissi L3 consentendo i due tipi di incapsulamento: MPLS-over-GRE e MPLS-over-UDP. Questa informazione è codificata utilizzando delle BGP Encapsulation Extended Community (vedi RFC 5512). Per contro, il router DC-GW non include alcuna BGP Encapsulation Extended Community e OpenContrail assume che il DC-GW supporta solo MPLS-over-GRE. Questa è una decisione basata su una sorta di logica da "minimo comune multiplo": viene utilizzato MPLS-over-GRE semplicemente perché è l'unico tipo di incapsulamento che è supportato sia dal DC-GW che da OpenContrail (in modalità L3-only).
Solo per curiosità, riportiamo di seguito la configurazione JunOS di un tunnel dinamico MPLS-over-GRE.
routing-options {
dynamic-tunnels {
OVERLAY-TUNNELS {
source-address 192.168.1.1; # indirizzo IP interfaccia «lo0.0» di DC-GW
gre;
destination-networks 10.0.10.0/24; # indirizzi IP verso IP Fabric
}}}
Con questa configurazione, il router DC-GW crea dinamicamente un'interfaccia virtuale GRE, per ciascun indirizzo remoto <IP-R> che soddisfa le due seguenti condizioni:
- Viene ricevuto un annuncio MP-iBGP VPN-IPv4 che ha come BGP Next-Hop remoto l'indirizzo <IP-R>.
- L'indirizzo <IP.R> appartiene all'insieme di indirizzi specificato nel comando "destination-networks ...".
Solo per i più curiosi, questa è l'interfaccia tunnel (= gr-0/0/0.32769) creata dinamicamente verso il vRouter_1 (che ha indirizzo IP 10.0.10.11):
tt@DC-GW> show interfaces gr-0/0/0.32769
Logical interface gr-0/0/0.32769 (Index 376) (SNMP ifIndex 579)
Flags: Up Point-To-Point SNMP-Traps 0x0
IP-Header 10.0.10.11:192.168.1.1:47:df:64:0000080000000000
Encapsulation: GRE-NULL
Protocol inet, MTU: 1576
Protocol mpls, MTU: 1564, Maximum labels: 3
E questo è invece come viene inoltrato un pacchetto della OVN Red, diretto alla VM Red_1A (IP = 10.2.2.101), che il DC-GW invia utilizzando il tunnel MPLS-over-GRE.
tt@DC-GW> show route table RED.inet.0
10.2.2.101/32 *[BGP/170] 11:35:44, localpref 100, from 10.0.10.3
AS path: ?, validation-state: unverified
> via gr-0/0/0.32769, Push 54
Per completare, illustrerò il "viaggio" di un pacchetto generato da un Host della L3VPN Red che ha indirizzo IP 10.1.1.1, e destinato alla VM Red_1A presente all'interno del Cloud privato.
CONCLUSIONI
In questo secondo post su OpenContrail ho illustrato un Case Study, basato sulla modalità L3-only, la mia modalità preferita poiché dimostra in maniera chiara ed inequivocabile che il traffico di una OVN può essere tranquillamente instradato senza ausilio alcuno di indirizzi MAC (a parte il dettaglio insignificante degli indirizzi MAC utilizzati per incapsulare i pacchetti IP nella tratta (virtuale) VM<->vRouter). E questo, come i miei lettori ormai sanno, è il mio sogno nel cassetto. Poiché però io, per indole, sono "democratico" e non "integralista", nel prossimo post illustrerò lo stesso Case Study, nella modalità di funzionamento ibrida L2-L3.
tt@DC-GW> show interfaces gr-0/0/0.32769
Logical interface gr-0/0/0.32769 (Index 376) (SNMP ifIndex 579)
Flags: Up Point-To-Point SNMP-Traps 0x0
IP-Header 10.0.10.11:192.168.1.1:47:df:64:0000080000000000
Encapsulation: GRE-NULL
Protocol inet, MTU: 1576
Protocol mpls, MTU: 1564, Maximum labels: 3
E questo è invece come viene inoltrato un pacchetto della OVN Red, diretto alla VM Red_1A (IP = 10.2.2.101), che il DC-GW invia utilizzando il tunnel MPLS-over-GRE.
tt@DC-GW> show route table RED.inet.0
10.2.2.101/32 *[BGP/170] 11:35:44, localpref 100, from 10.0.10.3
AS path: ?, validation-state: unverified
> via gr-0/0/0.32769, Push 54
Per completare, illustrerò il "viaggio" di un pacchetto generato da un Host della L3VPN Red che ha indirizzo IP 10.1.1.1, e destinato alla VM Red_1A presente all'interno del Cloud privato.
- L'Host L3VPN genera un pacchetto IP con IP sorgente 10.1.1.1 e IP destinazione 10.2.2.101, che viene inviato al PE di attestazione della rete IP/MPLS. Su questo PE è configurata una VRF RED, dove sono memorizzate le informazioni per l'inoltro dei pacchetti della OVN Red, tra cui quello in questione.
- Le informazioni per l'inoltro del pacchetto IP sono inviate al PE dall'ASBR, via MP-iBGP (AS 65000). Le informazioni chiave sono costituite dal BGP Next-Hop (es. l'indirizzo dell'interfaccia "lo0.0" dell'ASBR), e da una service label MPLS. Al pacchetto IP originale viene quindi aggiunta la service label MPLS, e il pacchetto MPLS risultante viene inviato al BGP Next-Hop (ossia, all'ASBR), di norma utilizzando un LSP MPLS di tipo Hop-by-Hop (ma in teoria si potrebbero tranquillamente utilizzare incapsulamenti alternativi come MPLS-over-GRE, MPLS-over-UDP, o addirittura MPLS-over-IP, se supportati).
- L'ASBR, sulla base del valore della service label e sulla base del criterio di scelta di questa service label, effettua un lookup sulla VRF RED configurata, oppure inoltra direttamente il pacchetto sull'interfaccia verso il DC-GW. Nel fare questo, esegue anche una operazione di label swapping, cambiando la service label nel valore 18, annunciato dal DC-GW via MP-eBGP (vedi figura sopra).
- Il DC-GW esegue una operazione di label swapping, cambiando la service label dal valore 18, al valore 54 ricevuto dal Control Node di OpenContrail. Il pacchetto MPLS risultante viene quindi trasportato verso il BGP Next-Hop, che è il vRouter_1 (IP = 10.0.10.11), utilizzando un incapsulamento MPLS-over-GRE e utilizzando la IP Fabric.
- A questo punto il gioco è fatto, poiché il pacchetto MPLS con etichetta 54 viene consegnato al vRouter_1, e tutto procede come nel punto 7 illustrato sopra nella sezione "Connettività VM-VM".
CONCLUSIONI
In questo secondo post su OpenContrail ho illustrato un Case Study, basato sulla modalità L3-only, la mia modalità preferita poiché dimostra in maniera chiara ed inequivocabile che il traffico di una OVN può essere tranquillamente instradato senza ausilio alcuno di indirizzi MAC (a parte il dettaglio insignificante degli indirizzi MAC utilizzati per incapsulare i pacchetti IP nella tratta (virtuale) VM<->vRouter). E questo, come i miei lettori ormai sanno, è il mio sogno nel cassetto. Poiché però io, per indole, sono "democratico" e non "integralista", nel prossimo post illustrerò lo stesso Case Study, nella modalità di funzionamento ibrida L2-L3.
I want to thank you for writing this article.This is great Article for me. It also more very informative & awesome. I expect more articles from you in future.
RispondiEliminaAwesome information. Great Contribution to blog. I
expect more articles from you in future. Keep it up!
XMPP
Taki, thanks a lot for your comment. I'll try to do my best to keep the blog interesting to a wide audience. It is written in Italian since it is aimed at Italian networkers, but there is a good Google translator and I think you have used it to read the OpenContrail post.
RispondiElimina