Gli esperti di server e di sistemi parlano con grande entusiasmo di virtualizzazione mentre chi si occupa di networking di solito si scontra con le difficoltà connesse al trovare una soluzione ai problemi di VLAN e segmentazione.
La questione delle VLAN si può ridurre semplicemente a un punto: le VLAN disponibili non sono sufficienti per un ambiente fortemente virtualizzato. In particolare, la specifica IEEE 802.1Q VLAN fornisce solo 4.094 identificativi VLAN. Ma uno switch top-of-rack può essere collegato a più di 40 server, ognuno dei quali supporta più VM che, a loro volta, comunicano ciascuna su più VLAN. Un data center può contenere molti rack, arrivando così a superare il limite dei 4.094.
VMware (e numerosi altri, tra cui Cisco) hanno proposto lo standard VXLAN (Virtual Extensible VLAN), che raggruppa VLAN associate con un’applicazione in un segmento definito da un identificativo a 24 bit chiamato VXLAN Network Identifier (VNI). Ben 16 milioni di VNI possono essere definiti in un qualsiasi dominio amministrativo e ogni VNI può contenere fino a 4.094 VLAN.
Per non arrendersi nella sfida sulla virtualizzazione nei confronti di VMware, Microsoft ha subito proposto la sua soluzione ai problemi inerenti le VLAN con lo standard NVGRE (Network Virtualization using Generic Routing Encapsulation). NVGRE utilizza il Tenant Network Identifier (TNI), identificativo a 24 bit che identifica una sola rete virtuale di Layer 2 e che permette fino a 16 milioni di reti.
Le similitudini tra i due sono tante, ma entrambi hanno dei punti deboli.
La virtualizzazione delle reti che fa ricorso allo standard NVGRE sottoposta di recente all’approvazione dello IETF da Microsoft, Arista Networks, Intel, Dell, Hewlett-Packard, Broadcom e Emulex risolve le stesse problematiche dello standard VXLAN recentemente proposto da Cisco, VMware, Citrix, Red Hat, Arista e Broadcom: entrambe sfruttano strategie di incapsulamento per creare un numero più ampio di VLAN per sottoreti che si estendono attraverso data center dispersi e Layer 2 e 3. Entrambi gli standard mirano a consentire reti load-balanced multi-tenant che possono essere condivise in ambienti cloud e on-premises.
NVGRE affronta le reti multi-tenant con il Tenant Network Identifier
Un cloud di grandi dimensioni può supportare centinaia di tenant, su ognuno dei quali funzionano molte applicazioni simultaneamente, e il traffico da un tenant deve essere isolato da tutti gli altri.
Attualmente le VLAN vengono utilizzate per isolare il traffico ma questo approccio presenta diversi inconvenienti. Per esempio, spesso le VLAN sono troppo poche per gestire esigenze troppo grandi in termini di segmentazione della capacità. In un ambiente cloud virtuale di grandi dimensioni, ogni applicazione può essere costituita da componenti che vanno in esecuzione su più VM e il traffico tra le diverse VM per ogni applicazione deve essere in una VLAN separata, con il seguente risultato: il numero totale di VLAN necessarie può superare facilmente il limite dei 4.094 definito dalla specifica IEEE 802.1Q VLAN.
Il secondo problema sorge nella migrazione di una VM da un server fisico a un altro, che deve essere trasparente per l’esecuzione di un’applicazione, in modo tale che gli stessi indirizzi di Layer 2 debbano essere trattenuti. Perché ciò accada, la rete deve essere riconfigurata per estendere la VLAN a diversi server; questo è un processo irto di potenziali errori. NVGRE risolve questi problemi specificando un identificativo a 24 bit, il Tenant Network Identifier (TNI). Ogni TNI identifica una singola rete virtuale di Layer 2 che permette fino a 16 milioni di reti.
L’incapsulamento di routing generico crea una rete virtuale di Layer 2
Il GRE (Generico Routing Encapsulation), un protocollo di tunneling definito dalla specifica RFC 2784 ed esteso dalla RFC 2890, fornisce un metodo per l’incapsulamento e l’invio di pacchetti a una destinazione attraverso reti di Layer 2 o Layer 3. La proposta NVGRE utilizza GRE per creare una rete virtuale di Layer2 isolata che può essere confinata a una singola rete fisica di Layer 2 o estendersi attraverso i confini delle sottoreti.
Ogni TNI è associato ad un singolo tunnel GRE. I pacchetti inviati da un endpoint del tunnel sono inoltrati agli altri endpoint con lo stesso TNI attraverso IP multicast. La conseguenza dell’uso del multicast è che il tunnel può estendersi attraverso una rete di Layer 3, limitando quindi il traffico broadcast suddividendo un ampio dominio broadcast in molti domini più piccoli.
Un endpoint NVGRE riceve pacchetti Ethernet da una VM per poi incapsularli e inviarli attraverso il tunnel GRE. L’endpoint decapsula i pacchetti in arrivo, distribuendoli alle giuste VM. Gli endpoint possono essere ubicati su qualsiasi componente della rete ma tipicamente vengono implementati sull’hypervisor del server. Ad ogni endpoint NVGRE sarà assegnato almeno uno, e possibilmente due, indirizzi IP. Ogni indirizzo IP viene indicato come Provider Address (PA). Gli indirizzi IP delleVM sono Customer Addresses (CA). L’assegnazione di più PA a un endpoint permette il load balancing. Questa proposta non definisce come un PA viene assegnato a un traffico proveniente da un CA né l’algoritmo di load balancing.
Isolare i dati tenant con uno standard NVGRE
L’endpoint NVGRE isola i singoli TNI inserendo uno specifier TNI nell’header GRE. L’identificativo TNI è posto nel campo chiave specificato dalla RFC 2890. Il campo chiave è definito come un campo a 32 bit: il TNI occupa 24 bit e i restanti 8 bit rimangono prenotati. NVGRE non utilizza la sequenza di numeri definita dalla RFC.
L’endpoint NVGRE che incapsula un pacchetto deve specificare l’indirizzo di destinazione al quale il pacchetto deve essere inviato. L’attuale bozza della proposta NVGRE rimanda il problema ad una futura versione del documento, affermando che “innumerevoli tecniche possono essere utilizzate per configurare, gestire e distribuire le informazioni sulla policy”.
Far migrare al cloud intere sottoreti utilizzando NVGRE
La proposta non specifica un metodo per l’assegnazione di indirizzi CA e PA ma afferma che l’assegnazione dell’indirizzo può essere fatta in modo statico, dinamico o utilizzando l’autoconfigurazione di indirizzi stateless. Possono essere utilizzati sia IPv4 che IPv6. Ai CA possono essere assegnati indirizzi IPv4 mentre ai PA vengono assegnati indirizzi IPv6 o vice versa.
La specifica è concepita per permettere la migrazione di un’intera sottorete nel cloud, secondo la proposta NVGRE. Una parte di una sottorete può migrare, mentre il resto può rimanere sulla rete enterprise, nel qual caso una VPN collegherebbe il cloud alla rete enterprise.
Un uso efficiente della rete richiede di distribuire il traffico attraverso più percorsi di rete. La proposta afferma che tecniche come l’Equal Cost Multipath (ECMP) possono essere utilizzate con gli otto bit prenotati nel campo chiave dell’header GRE utilizzato per supportare l’impiego di più percorsi. La proposta non include dettagli su un algoritmo per raggiungere flussi equilibrati. Un approccio alternativo per permettere l’ECMP consiste nell’assegnare più PA in un server. Gli switch possono poi distribuire il traffico attraverso percorsi che passano dai PA.
Standard NVGRE e VXLAN a confronto
Chiaramente, entrambe le proposte risolvono lo stesso problema: 4094 VLAN non sono sufficienti per supportare più tenant e applicazioni cloud. E sempre entrambe contemplano l’introduzione di un nuovo identificativo a 24 bit, l’uso di tunnel per trasportare pacchetti attraverso la rete e i confini delle sottoreti e l’uso di multicast per collegare componenti di applicazioni in esecuzione sulle VM distribuite nella rete.
Le due proposte differiscono però nel modo in cui gli indirizzi di destinazione sono individuati. La proposta VXLAN descrive in dettaglio come i pacchetti vadano a riversarsi attraverso il tunnel per individuare gli endpoint di destinazione. La proposta NVGRE non affronta ancora la questione e rinvia il metodo per individuare le destinazioni a una ulteriore versione della specifica.
Entrambe sostengono la necessità del load balancing per un funzionamento efficiente. Mentre, però, la proposta VXLAN spiega come l’assegnazione random di numeri di porte possa essere utilizzata per distribuire il carico, la NVGRE suggerisce di utilizzare gli otto bit prenotati nel campo chiave GRE ma non fornisce dettagli su come possano essere utilizzati.
In generale, la VXLAN è più completa e dettagliata. Cisco e VMware hanno annunciato che sono ora disponibili prodotti che utilizzano la specifica mentre restano ancora necessari futuri aggiornamenti alla proposta prima del rilascio sul mercato di prodotti NVGRE.
