Geneve in NSX

Indice

• Introduzione

• Tunneling overlay e incapsulamento Geneve

  • Flusso VM-VM attraverso l’overlay

  • Formato dell’header Geneve

• Tabelle di forwarding nei logical switch NSX

  • TEP Table

  • MAC Table

  • ARP Table e ARP suppression

• Gestione del traffico BUM (Broadcast, Unknown, Multicast)

• Conclusione

Introduzione

I logical switch di VMware NSX, chiamati segment, consentono di creare domini di broadcast di Livello 2 che si estendono attraverso più host (transport node). In altre parole, un segment NSX rappresenta una rete L2 virtuale (broadcast domain) che può collegare macchine virtuali (VM) su host diversi. Ad ogni segment è associato un identificatore di rete virtuale (VNI) a 24 bit, analogo ad una VLAN ID, che distingue univocamente il segmento logico.

Questa architettura di switching logico permette la segmentazione multitenant scalabile e la mobilità delle VM su qualsiasi host, evitando i limiti fisici delle VLAN tradizionali. NSX realizza infatti reti L2 virtuali sovrapposte all’infrastruttura L3 fisica esistente tramite tecniche di overlay. In pratica, il traffico L2 delle VM viene incapsulato in tunnel IP che attraversano la rete fisica L3 sottostante. Ciò consente connettività L2 “ovunque” senza dover estendere i segmenti VLAN nel data center fisico. I logical switch NSX di tipo overlay utilizzano il protocollo Geneve come meccanismo di tunneling per trasportare i frame L2 delle VM attraverso la rete IP fisica.a

Tunneling overlay e incapsulamento Geneve

Tunneling in NSX significa incapsulare i pacchetti della rete virtuale all’interno di pacchetti instradabili sulla rete fisica. VMware NSX adotta Geneve (Generic Network Virtualization Encapsulation) per incapsulare il traffico dati overlay. I tunnel vengono stabiliti tra speciali endpoint chiamati Tunnel Endpoint (TEP), uno per ciascun transport node (tipicamente un’interfaccia sull’host ESXi o KVM). Quando una VM invia un frame su un segmento logico, quell’host incapsula il frame con gli header Geneve necessari e lo inoltra attraverso il tunnel IP verso l’host di destinazione.

In sintesi, Geneve è un protocollo standard IETF di incapsulamento overlay che consente di trasportare traffico L2 su una rete L3. In NSX, Geneve funziona in questo modo: il TEP sorgente incapsula l’intero frame Ethernet originato dalla VM aggiungendo un header Geneve (trasportato su UDP) e lo invia, tramite la rete fisica, al TEP di destinazione. Il TEP di destinazione poi decapsula il pacchetto Geneve, rimuovendo gli header di incapsulamento, e consegna il frame originale alla VM di destinazione sull’altro host. Questo tunnel Geneve utilizza UDP come protocollo di trasporto (porta 6081 per default). Ciascun pacchetto Geneve incapsulato include al suo interno il VNI a 24 bit che identifica il segmento logico di appartenenza del frame.

Flusso VM-VM attraverso l’overlay

Per chiarire il processo, consideriamo due VM (VM1 e VM2) collegate allo stesso segment overlay (stesso VNI) ma posizionate su host diversi. Di seguito è illustrato il flusso dei pacchetti da VM1 a VM2 attraverso l’overlay Geneve:

Nell’overlay Geneve, il frame originale della VM viene racchiuso in una nuova busta di rete (header outer) con indirizzi IP dei TEP. Il frame viaggia attraverso la rete fisica L3 come un normale pacchetto UDP/IP, per poi essere decapsulato dall’host remoto e riconsegnato alla VM destinataria.

Il percorso passo-passo del traffico unicast tra VM1 e VM2 sullo stesso segmento overlay è il seguente:

1. Invio del frame originale: VM1 genera un frame Ethernet destinato a VM2 (supponiamo che l’ARP sia già risolto, quindi VM1 conosce l'indirizzo MAC di VM2). Il frame è inviato sulla porta logica (vNIC) collegata al segmento X su Host A.

2. Encapsulamento Geneve sul host sorgente: Il virtual switch NSX sull’Host A intercetta il frame e lo incapsula. Viene aggiunto un header Geneve contenente il VNI del segmento X e questo header è inserito a sua volta dentro un pacchetto UDP/IP. L’IP sorgente del pacchetto sarà l’indirizzo IP del TEP di Host A, e l’IP di destinazione sarà l’indirizzo TEP di Host B. La porta UDP utilizzata è la 6081. In sostanza, l’intero frame originale diventa il payload del pacchetto Geneve.

3. Trasporto sulla rete fisica (overlay): Il pacchetto incapsulato viaggia attraverso la rete fisica IP (underlay). I dispositivi di rete fisici vedono solo un pacchetto UDP tra i due indirizzi IP dei TEP; non hanno visibilità del frame Ethernet interno né del VNI. La rete underlay instrada il pacchetto fino all’host di destinazione (Host B) usando l’IP di destinazione (TEP B).

4. Decapsulamento sul host di destinazione: Quando il pacchetto UDP/Geneve arriva all’Host B, il suo TEP riconosce la destinazione. L’host B decapsula il pacchetto Geneve, rimuovendo gli header esterni (UDP, IP, Ethernet esterno) e recuperando il frame Ethernet originale. Questo frame viene quindi consegnato alla porta logica del segmento X a cui è connessa VM2, come se fosse arrivato su un normale switch L2. VM2 infine riceve il frame da VM1, completando la comunicazione end-to-end.

Va notato che tutto questo avviene in maniera trasparente per le VM: dal punto di vista di VM1 e VM2, esse sono nella stessa rete L2 broadcast domain. Il lavoro di incapsulamento/decapsulamento è gestito dal datapath NSX su ciascun transport node (es. il modulo kernel nsx-vdl2 in ESXi) e coordinato dal control plane NSX.

Formato dell’header Geneve

Un elemento chiave dell’overlay NSX è il formato dell’header Geneve, che contiene le informazioni necessarie per instradare correttamente i pacchetti nel tunnel. Geneve è progettato per essere flessibile ed estensibile, con la possibilità di includere campi opzionali per metadata aggiuntivi (ad esempio, informazioni sul tenant, identificatori di servizio, etc., non trattati in dettaglio qui). Qui ci concentreremo sulle componenti principali dell’header Geneve standard utilizzato in NSX:

• Outer Ethernet Header: Header Ethernet esterno usato sulla rete fisica. Ha MAC di origine e destinazione appartenenti ai TEP degli host (ad esempio, MAC del NIC di Host A e MAC dell’endpoint di Host B). Questo livello serve solo a consegnare il pacchetto al router/switch fisico successivo sull’underlay.

• Outer IP Header: Header IP esterno (tipicamente IPv4 o IPv6) con IP sorgente = indirizzo del TEP dell’host mittente, e IP destinazione = indirizzo del TEP dell’host ricevente. Questo consente il routing L3 del pacchetto sulla rete underlay fino al transport node di destinazione.

• UDP Header: Geneve utilizza UDP come protocollo di trasporto. La porta destinazione standard è 6081 (la sorgente può essere scelta dall’host sorgente). L’header UDP è lungo 8 byte e trasporta come payload l’header Geneve + il frame originale.

• Geneve Header: Questo è l’header specifico del protocollo Geneve che segue l’UDP header. Include campi importanti tra cui:

  • Versione (Ver): 2 bit (la versione corrente è 0).

  • Opzione Lunghezza (Opt Len): 6 bit che indicano la lunghezza di eventuali campi opzionali aggiuntivi presenti (in multipli di 4 byte).

  • Flags (O, C): 2 bit di flag (O = OAM packet indicator, C = Critical option indicator).

  • Protocol Type: 16 bit che indicano il tipo di protocollo del payload interno (di solito 0x6558 per Ethernet).

  • Virtual Network Identifier (VNI): 24 bit che identificano l’ID della rete virtuale (segmento) a cui appartiene il frame incapsulato. Questo campo è fondamentale perché indica al TEP di destinazione a quale segmento logico consegnare il frame una volta decapsulato. Il VNI in NSX corrisponde al segment ID.

  • Reserved: 8 bit riservati (non usati, impostati a 0).

  • (Segue eventualmente una lista di TLV options opzionali se Opt Len > 0, che in NSX possono non essere utilizzate per il semplice forwarding dei frame standard).

• Inner Ethernet + Payload: Dopo l’header Geneve inizia il frame originale incapsulato, composto dall’header Ethernet originario della VM (dest MAC = MAC della VM2, src MAC = MAC di VM1, etc.), seguito a sua volta dal payload di livello superiore (ad esempio header IP della VM, TCP/UDP, dati applicativi, ecc.). Questo è il contenuto che verrà consegnato intatto alla VM di destinazione dopo la decapsulazione.

Possiamo rappresentare graficamente la struttura di un pacchetto Geneve incapsulato così:

Come mostrato, l’header Geneve si trova tra l’UDP di trasporto e il frame Ethernet interno. In totale, l’overhead aggiunto da Geneve consiste in: 14 byte (Ethernet esterno) + 20 byte (IP v4) + 8 byte (UDP) + 8 byte (Geneve base header) = 50 byte circa, più eventuali option. Questo overhead è simile a quello di altri protocolli tunneling L2overL3 come VXLAN. Una caratteristica vantaggiosa di Geneve è la flessibilità del control plane: i tunnel Geneve possono funzionare indipendentemente dallo specifico control plane NSX, poiché l’header può ospitare opzioni estendibili senza modificare il comportamento base del tunnel.

Tabelle di forwarding nei logical switch NSX

Per realizzare il forwarding dei pacchetti all’interno dei segment overlay, NSX utilizza una serie di tabelle di controllo mantenute dal control plane (NSX Controller/CCP) e replicate localmente su ogni transport node. Queste tabelle sono essenziali per mappare gli elementi della rete virtuale (VNI, MAC delle VM, IP delle VM) con gli endpoint fisici (indirizzi TEP degli host) e garantire che ogni host sappia dove inoltrare i pacchetti incapsulati. In particolare, il NSX Controller mantiene tre tabelle principali per lo switching logico:

• TEP Table: Mappa ogni VNI (segment ID) agli indirizzi IP dei TEP attivi per quel segmento. In altre parole, tiene traccia di quali host partecipano a un certo overlay identificato dal VNI, e con quali IP tunnel endpoint.

• MAC Table: Mappa ogni MAC di VM con l’IP del TEP dell’host dove quella VM è attiva. Di fatto, è l’equivalente di una tabella di forwarding L2 distribuita: consente di sapere, dato un MAC di destinazione, quale host (quale TEP) lo sta ospitando.

• ARP Table: Memorizza l’associazione tra l’IP di una VM e il suo MAC. Viene popolata osservando (snooping) il traffico ARP e DHCP delle VM. Questa tabella è usata principalmente per ottimizzare il comportamento di ARP nella rete virtuale (come vedremo con l’ARP suppression).

Ogni transport node (host) mantiene una copia locale di queste tabelle relativa ai segment a cui partecipa. Quando una VM viene collegata a un segmento e alimentata (powered on), il suo host apprende immediatamente alcuni di questi dati e li condivide con il controller NSX (control plane centrale, spesso chiamato Central Control Plane – CCP). Il flusso di aggiornamento tipico è:

• Aggiornamento TEP Table: Quando un host attiva un VNI (ad esempio perché ha una VM collegata a quel segmento), registra localmente l’associazione VNI -> IP TEP locale. Questo mapping viene segnalato al CCP, che lo aggiunge alla propria TEP Table globale. Il controller consolida tutte le associazioni VNI-TEP da ogni host e invia ad ogni transport node la lista aggiornata di tutti i TEP coinvolti per ciascun VNI. In questo modo, ogni host sa l’elenco di IP TEP remoti a cui indirizzare i tunnel Geneve per raggiungere le VM degli altri host nello stesso segmento.

• Aggiornamento MAC Table: Analogamente, quando su un host compare una nuova MAC address (es. la VM accesa annuncia il proprio MAC oppure invia traffico), l’host associa quel MAC al proprio TEP (poiché la VM è locale) nella sua tabella MAC locale. Questo indica “MAC X è raggiungibile via TEP IP = mio indirizzo”. Il mapping MAC-to-TEP locale viene notificato al CCP, che costruisce la vista globale di dove si trova ogni MAC (quale host/TEP). Il controller distribuisce poi ai transport node la tabella MAC aggiornata per quel VNI, in modo che ogni host possa instradare correttamente i pacchetti destinati a MAC remoti verso il TEP giusto. In pratica, la MAC table distribuita permette l’instruzione unicast ottimale nell’overlay senza necessità di flooding di unknown unicast: se una VM invia a un MAC di destinazione, l’host sorgente interroga la propria MAC table locale (popolata dal controller) per trovare il TEP corrispondente al MAC, e incapsula direttamente verso quell’IP.

• Aggiornamento ARP Table e ARP suppression: L’ARP table ha lo scopo di associare IP e MAC delle VM. Ogni transport node osserva il traffico ARP e DHCP generato dalle VM locali per apprendere le corrispondenze IP<->MAC e le registra in una tabella locale. Periodicamente o quando nuove associazioni sono imparate, l’host invia questi dati al CCP, che aggiorna la sua ARP table centrale. Il controller quindi ridistribuisce ai transport node le informazioni ARP aggiornate. Il beneficio di mantenere un’ARP table centrale sta nella possibilità di sopprimere l’ARP (ARP suppression): se una VM deve risolvere l’MAC di un’altra VM sullo stesso segmento, l’host può intercettare la richiesta ARP broadcast e rispondere direttamente (proxy ARP) utilizzando i dati di binding IP-MAC già noti, senza dover inoltrare il broadcast a tutti gli altri host. Ciò riduce drasticamente il flooding di pacchetti ARP all’interno del segmento overlay. In NSX, grazie all’ARP table mantenuta nel control plane, il traffico ARP broadcast all’interno di un segment può essere minimizzato: solo nel caso in cui l’IP richiesto non sia presente in tabella, il broadcast verrà propagato (e nel frattempo l’host di destinazione apprenderà l’associazione e la comunicherà al controller per future richieste). Questo meccanismo di ARP suppression migliora l’efficienza della rete virtuale evitando inutili broadcast su tutti i transport node.

Le tabelle di forwarding (TEP, MAC, ARP) risiedono dunque sia localmente su ciascun host (nel modulo di datapath NSX) sia nel controller NSX (CCP) a livello centrale. Il controller agisce da fonte autorevole e distributore: consolida le informazioni ricevute dagli host e le sincronizza di nuovo verso tutti gli host partecipanti al segmento, garantendo una convergenza rapida e coerente. In caso di cambiamenti (es. una VM migra o viene spenta), i mapping vengono aggiornati di conseguenza: l’host rimuove o aggiorna le voci locali e il CCP propaga le modifiche agli altri nodi.

Gestione del traffico BUM (Broadcast, Unknown, Multicast)

Nel contesto di uno switch L2, il traffico di tipo Broadcast, Unknown unicast, Multicast (BUM) richiede attenzioni particolari, poiché per sua natura deve raggiungere tutti i nodi appartenenti al dominio di broadcast. In un segmento logico NSX, se una VM emette un pacchetto broadcast (es. ARP request non soppressa) o multicast, oppure uniflussi destinati a MAC sconosciuti (unknown unicast), questo traffico deve essere replicato a tutte le VM appartenenti a quel segment, anche se risiedono su host remoti.

Su una rete fisica tradizionale, uno switch eseguirebbe un flooding di livello 2 su tutte le porte del VLAN. Nel caso di NSX, il flooding deve essere orchestrato a livello di overlay: il pacchetto BUM generato su un host deve essere incapsulato e inviato a tutti i transport node che ospitano quel segmento. Per realizzare ciò in modo efficiente, NSX supporta due modalità di replicazione del traffico BUM:

• Head Replication (replicazione dal sorgente): In questa modalità, il transport node sorgente che riceve il pacchetto BUM dalla VM provvede a replicarlo e inviarnelo separatamente a ciascun altro TEP remoto che partecipa a quel VNI. In pratica, l’host di origine funge da “hub” duplicando il pacchetto incapsulato Geneve verso ogni destinazione. Questo metodo è semplice ma può gravare sull’host sorgente e sulla banda se ci sono molti destinatari, poiché genera un pacchetto unicast overlay per ogni transport node remoto.

• Hierarchical Two-Tier Replication (replicazione gerarchica a due livelli): Questa modalità introduce un livello di ottimizzazione eleggendo dei proxy TEP (chiamati anche MTEP, multicast TEP o "TEP di messa a terra") per ciascun dominio L2 remoto. Il processo funziona così: l’host sorgente replica il pacchetto BUM solo all’interno del proprio dominio L2 locale (ad esempio, se più host condividono lo stesso switch fisico o lo stesso rack, costituiscono un dominio di replicazione locale). Poi, per ogni altro dominio L2 (ad esempio un altro rack o altro sito), l’host sorgente invia una sola copia del pacchetto ad un TEP delegato in quel dominio remoto. Questo proxy TEP quindi si occupa di replicare ulteriormente il pacchetto a tutti gli host del proprio dominio locale. In questo modo, il carico di replicazione è suddiviso: la sorgente non deve inviare N copie a tutti gli host remoti individualmente, ma solo una copia per dominio remoto, riducendo il traffico duplicato sull’underlay. I proxy TEP vengono eletti dinamicamente dal control plane e ogni host conosce quale TEP funge da proxy per gli altri domini.

Entrambi i metodi assicurano che il traffico BUM raggiunga tutti i membri del segment, ma Head Replication è tipicamente usata in ambienti di dimensioni ridotte o in assenza di multicast nell’underlay, mentre la Hierarchical Replication è preferita in ambienti più grandi o multisito per ottimizzare l’efficienza della distribuzione del traffico broadcast/multicast.

Indipendentemente dalla modalità, il control plane NSX fornisce agli host la lista di TEP necessari per la replicazione BUM su ogni VNI. Inoltre, NSX supporta l’uso opzionale di tecnologie multicast IP nell’underlay per realizzare la replicazione BUM in maniera più efficiente (sfruttando il routing multicast a livello fisico), ma il focus qui è sulle due modalità di replicazione unicast-based sopra descritte.

Conclusione

I logical switch di VMware NSX implementano una rete virtuale L2 distribuita, consentendo alle VM di comunicare su segment logici indipendentemente dalla loro posizione fisica. Il cuore di questa tecnologia è l’incapsulamento Geneve: incapsulando i frame Ethernet delle VM in tunnel UDP/IP, NSX realizza overlay che sovrappongono reti L2 sopra un’infrastruttura L3, sfruttando i Tunnel Endpoint (TEP) su ogni host per il trasporto. Abbiamo visto come un frame viaggia da VM a VM attraverso l’overlay, passando per l’incapsulamento Geneve (con VNI che identifica il segmento) e la successiva decapsulazione sul nodo di destinazione.

Abbiamo inoltre approfondito le tabelle di forwarding mantenute dal control plane NSX (TEP Table, MAC Table, ARP Table) che permettono a ciascun host di sapere esattamente dove inoltrare i pacchetti nel fabric virtuale. Queste tabelle distribuite, sincronizzate tramite il Central Control Plane, assicurano che il forwarding sia ottimizzato (unicast noto inviato direttamente al TEP corretto) e che funzioni avanzate come l’ARP suppression riducano il traffico di broadcast inutile. Allo stesso modo, la gestione intelligente del traffico BUM garantisce che broadcast, multicast e unknown unicast vengano recapitati ovunque necessario nel segmento, bilanciando l’efficienza con la semplicità a seconda della modalità scelta (head vs. hierarchical replication).

In conclusione, l’incapsulamento Geneve e il design distribuito di NSX permettono di superare le sfide delle reti tradizionali, offrendo isolamento multi-tenancy e L2 adjacency su larga scala. Grazie a tunnel overlay robusti e a un control plane centralizzato che mantiene lo stato della rete virtuale (mapping di TEP, MAC e IP), VMware NSX fornisce un’infrastruttura di switching logico flessibile e performante per i moderni data center virtualizzati. I professionisti IT possono così usufruire di segment virtuali che si comportano come switch L2 convenzionali, ma con tutti i vantaggi dell’astrazione software-defined: provisioning rapido, mobilità delle VM senza confini fisici, e controllo completo sul comportamento del traffico a livello di software.