Per parlare di gateway VXLAN, dobbiamo prima parlare di VXLAN stesso. Ricordiamo che le VLAN (Virtual Local Area Network) tradizionali utilizzano ID VLAN a 12 bit per suddividere le reti, supportando fino a 4096 reti logiche. Questo funziona bene per reti di piccole dimensioni, ma nei moderni data center, con le loro migliaia di macchine virtuali, container e ambienti multi-tenant, le VLAN risultano insufficienti. È così che è nato VXLAN, definito dall'Internet Engineering Task Force (IETF) nella RFC 7348. Il suo scopo è estendere il dominio broadcast del Livello 2 (Ethernet) sulle reti di Livello 3 (IP) utilizzando tunnel UDP.
In parole semplici, VXLAN incapsula i frame Ethernet all'interno di pacchetti UDP e aggiunge un identificatore di rete VXLAN (VNI) a 24 bit, supportando teoricamente 16 milioni di reti virtuali. È come dare a ogni rete virtuale una "carta d'identità", che permette loro di muoversi liberamente sulla rete fisica senza interferire l'una con l'altra. Il componente principale di VXLAN è il VXLAN Tunnel End Point (VTEP), responsabile dell'incapsulamento e della decapsulazione dei pacchetti. Il VTEP può essere software (come Open vSwitch) o hardware (come il chip ASIC sullo switch).
Perché VXLAN è così popolare? Perché si allinea perfettamente alle esigenze del cloud computing e dell'SDN (Software-Defined Networking). Nei cloud pubblici come AWS e Azure, VXLAN consente l'estensione senza soluzione di continuità delle reti virtuali dei tenant. Nei data center privati, supporta architetture di rete overlay come VMware NSX o Cisco ACI. Immaginate un data center con migliaia di server, ognuno dei quali esegue decine di macchine virtuali (VM). VXLAN permette a queste VM di percepirsi come parte della stessa rete di livello 2, garantendo una trasmissione fluida dei broadcast ARP e delle richieste DHCP.
Tuttavia, VXLAN non è una panacea. Operare su una rete di livello 3 richiede la conversione da livello 2 a livello 3, ed è qui che entra in gioco il gateway. Il gateway VXLAN collega la rete virtuale VXLAN con reti esterne (come le VLAN tradizionali o le reti di routing IP), garantendo il flusso di dati dal mondo virtuale al mondo reale. Il meccanismo di inoltro è il cuore pulsante del gateway, in quanto determina come i pacchetti vengono elaborati, instradati e distribuiti.
Il processo di inoltro VXLAN è come un delicato balletto, in cui ogni passaggio, dalla sorgente alla destinazione, è strettamente collegato. Analizziamolo passo dopo passo.
Innanzitutto, un pacchetto viene inviato dall'host di origine (ad esempio una macchina virtuale). Si tratta di un frame Ethernet standard contenente l'indirizzo MAC di origine, l'indirizzo MAC di destinazione, il tag VLAN (se presente) e il payload. Dopo aver ricevuto questo frame, il VTEP di origine controlla l'indirizzo MAC di destinazione. Se l'indirizzo MAC di destinazione è presente nella sua tabella MAC (ottenuta tramite apprendimento o flooding), sa a quale VTEP remoto inoltrare il pacchetto.
Il processo di incapsulamento è cruciale: il VTEP aggiunge un'intestazione VXLAN (inclusi VNI, flag e così via), quindi un'intestazione UDP esterna (con una porta sorgente basata su un hash del frame interno e una porta di destinazione fissa di 4789), un'intestazione IP (con l'indirizzo IP sorgente del VTEP locale e l'indirizzo IP di destinazione del VTEP remoto) e infine un'intestazione Ethernet esterna. L'intero pacchetto appare ora come un pacchetto UDP/IP, sembra traffico normale e può essere instradato sulla rete L3.
Sulla rete fisica, il pacchetto viene inoltrato da un router o uno switch fino a raggiungere il VTEP di destinazione. Il VTEP di destinazione rimuove l'intestazione esterna, controlla l'intestazione VXLAN per assicurarsi che il VNI corrisponda e quindi consegna il frame Ethernet interno all'host di destinazione. Se il pacchetto è traffico unicast, broadcast o multicast (BUM) sconosciuto, il VTEP replica il pacchetto a tutti i VTEP pertinenti tramite flooding, basandosi su gruppi multicast o sulla replica dell'intestazione unicast (HER).
Il principio fondamentale dell'inoltro risiede nella separazione tra piano di controllo e piano dati. Il piano di controllo utilizza Ethernet VPN (EVPN) o il meccanismo Flood and Learn per apprendere le mappature MAC e IP. EVPN si basa sul protocollo BGP e consente ai VTEP di scambiare informazioni di routing, come MAC-VRF (Virtual Routing and Forwarding) e IP-VRF. Il piano dati è responsabile dell'inoltro effettivo, utilizzando tunnel VXLAN per una trasmissione efficiente.
Tuttavia, nelle implementazioni reali, l'efficienza dell'inoltro ha un impatto diretto sulle prestazioni. Il flooding tradizionale può facilmente causare tempeste di broadcast, soprattutto nelle reti di grandi dimensioni. Ciò rende necessaria l'ottimizzazione del gateway: i gateway non solo connettono le reti interne ed esterne, ma fungono anche da agenti proxy ARP, gestiscono le perdite di instradamento e garantiscono i percorsi di inoltro più brevi.
Gateway VXLAN centralizzato
Un gateway VXLAN centralizzato, detto anche gateway centralizzato o gateway L3, viene in genere implementato al livello edge o core di un data center. Funge da hub centrale, attraverso il quale deve passare tutto il traffico tra VNI o tra sottoreti.
In linea di principio, un gateway centralizzato funge da gateway predefinito, fornendo servizi di routing di livello 3 per tutte le reti VXLAN. Consideriamo due VNI: VNI 10000 (sottorete 10.1.1.0/24) e VNI 20000 (sottorete 10.2.1.0/24). Se la VM A nella VNI 10000 desidera accedere alla VM B nella VNI 20000, il pacchetto raggiunge prima il VTEP locale. Il VTEP locale rileva che l'indirizzo IP di destinazione non si trova nella sottorete locale e lo inoltra al gateway centralizzato. Il gateway decapsula il pacchetto, prende una decisione di routing e quindi reincapsula il pacchetto in un tunnel verso la VNI di destinazione.
I vantaggi sono evidenti:
○ Gestione sempliceTutte le configurazioni di routing sono centralizzate su uno o due dispositivi, consentendo agli operatori di gestire solo pochi gateway per coprire l'intera rete. Questo approccio è adatto a data center di piccole e medie dimensioni o ad ambienti che implementano VXLAN per la prima volta.
○Efficienza delle risorseI gateway sono in genere hardware ad alte prestazioni (come Cisco Nexus 9000 o Arista 7050) in grado di gestire enormi quantità di traffico. Il piano di controllo è centralizzato, il che facilita l'integrazione con controller SDN come NSX Manager.
○Controllo di sicurezza rigorosoIl traffico deve passare attraverso il gateway, facilitando l'implementazione di ACL (Liste di Controllo degli Accessi), firewall e NAT. Immaginate uno scenario multi-tenant in cui un gateway centralizzato può isolare facilmente il traffico dei singoli tenant.
Ma le carenze non possono essere ignorate:
○ Punto singolo di guastoSe il gateway si guasta, la comunicazione di livello 3 sull'intera rete viene paralizzata. Sebbene sia possibile utilizzare il protocollo VRRP (Virtual Router Redundancy Protocol) per la ridondanza, esso comporta comunque dei rischi.
○Collo di bottiglia delle prestazioniTutto il traffico est-ovest (comunicazione tra server) deve bypassare il gateway, con conseguente percorso non ottimale. Ad esempio, in un cluster di 1000 nodi, se la larghezza di banda del gateway è di 100 Gbps, è probabile che si verifichi congestione durante le ore di punta.
○Scarsa scalabilitàCon l'aumentare delle dimensioni della rete, il carico sul gateway cresce esponenzialmente. Per fare un esempio concreto, ho visto un data center finanziario che utilizzava un gateway centralizzato. Inizialmente, tutto funzionava senza intoppi, ma dopo il raddoppio del numero di macchine virtuali, la latenza è schizzata da microsecondi a millisecondi.
Scenario applicativo: Adatto ad ambienti che richiedono un'elevata semplicità di gestione, come cloud privati aziendali o reti di test. L'architettura ACI di Cisco utilizza spesso un modello centralizzato, combinato con una topologia leaf-spine, per garantire un funzionamento efficiente dei gateway principali.
Gateway VXLAN distribuito
Un gateway VXLAN distribuito, noto anche come gateway distribuito o gateway anycast, delega la funzionalità di gateway a ciascuno switch leaf o VTEP dell'hypervisor. Ogni VTEP funge da gateway locale, gestendo l'inoltro di livello 3 per la sottorete locale.
Il principio è più flessibile: ogni VTEP è configurato con lo stesso indirizzo IP virtuale (VIP) del gateway predefinito, utilizzando il meccanismo Anycast. I pacchetti cross-subnet inviati dalle VM vengono instradati direttamente sul VTEP locale, senza dover passare attraverso un punto centrale. L'EVPN è particolarmente utile in questo caso: tramite BGP EVPN, il VTEP apprende le rotte degli host remoti e utilizza il binding MAC/IP per evitare il flooding ARP.
Ad esempio, la VM A (10.1.1.10) desidera accedere alla VM B (10.2.1.10). Il gateway predefinito della VM A è l'indirizzo IP virtuale (VIP) del VTEP locale (10.1.1.1). Il VTEP locale instrada il traffico verso la sottorete di destinazione, incapsula il pacchetto VXLAN e lo invia direttamente al VTEP della VM B. Questo processo minimizza il percorso e la latenza.
Vantaggi eccezionali:
○ Elevata scalabilitàDistribuire la funzionalità di gateway a ogni nodo aumenta le dimensioni della rete, il che è vantaggioso per le reti di grandi dimensioni. I grandi fornitori di servizi cloud come Google Cloud utilizzano un meccanismo simile per supportare milioni di macchine virtuali.
○Prestazioni superioriIl traffico est-ovest viene elaborato localmente per evitare colli di bottiglia. I dati dei test dimostrano che la velocità di trasmissione può aumentare del 30%-50% in modalità distribuita.
○Ripristino rapido dei guastiUn singolo guasto VTEP influisce solo sull'host locale, lasciando inalterati gli altri nodi. Grazie alla rapida convergenza di EVPN, il tempo di ripristino si riduce a pochi secondi.
○Buon utilizzo delle risorseSfruttate il chip ASIC dello switch Leaf esistente per l'accelerazione hardware, con velocità di inoltro che raggiungono livelli di Tbps.
Quali sono gli svantaggi?
○ Configurazione complessaOgni VTEP richiede la configurazione di routing, EVPN e altre funzionalità, il che rende la fase di implementazione iniziale piuttosto lunga. Il team operativo deve avere familiarità con BGP e SDN.
○Elevati requisiti hardwareGateway distribuito: non tutti gli switch supportano i gateway distribuiti; sono necessari chip Broadcom Trident o Tomahawk. Le implementazioni software (come OVS su KVM) non offrono prestazioni pari a quelle hardware.
○Sfide di coerenza"Distribuito" significa che la sincronizzazione dello stato si basa su EVPN. Se la sessione BGP subisce delle fluttuazioni, potrebbe verificarsi un buco nero nel routing.
Scenario applicativo: ideale per data center hyperscale o cloud pubblici. Il router distribuito di VMware NSX-T ne è un tipico esempio. In combinazione con Kubernetes, supporta in modo trasparente il networking dei container.
Gateway VxLAN centralizzato vs. gateway VxLAN distribuito
Ora veniamo al punto cruciale: qual è la soluzione migliore? La risposta è "dipende", ma per convincervi dovremo analizzare a fondo dati e casi di studio.
Dal punto di vista delle prestazioni, i sistemi distribuiti offrono risultati nettamente superiori. In un tipico benchmark per data center (basato su apparecchiature di test Spirent), la latenza media di un gateway centralizzato era di 150 μs, mentre quella di un sistema distribuito era di soli 50 μs. In termini di throughput, i sistemi distribuiti possono facilmente raggiungere la velocità di inoltro della linea grazie all'utilizzo del routing Spine-Leaf Equal Cost Multi-Path (ECMP).
La scalabilità è un altro terreno di scontro. Le reti centralizzate sono adatte a reti con 100-500 nodi; oltre questa scala, le reti distribuite diventano più vantaggiose. Prendiamo ad esempio Alibaba Cloud. Il loro VPC (Virtual Private Cloud) utilizza gateway VXLAN distribuiti per supportare milioni di utenti in tutto il mondo, con una latenza in singola regione inferiore a 1 ms. Un approccio centralizzato sarebbe crollato da tempo.
E per quanto riguarda i costi? Una soluzione centralizzata offre un investimento iniziale inferiore, richiedendo solo pochi gateway di fascia alta. Una soluzione distribuita richiede che tutti i nodi periferici supportino l'offload VXLAN, con conseguenti costi di aggiornamento hardware più elevati. Tuttavia, a lungo termine, una soluzione distribuita offre costi di gestione e manutenzione inferiori, poiché strumenti di automazione come Ansible consentono la configurazione in batch.
Sicurezza e affidabilità: i sistemi centralizzati facilitano la protezione centralizzata ma presentano un elevato rischio di punti di attacco singoli. I sistemi distribuiti sono più resilienti ma richiedono un piano di controllo robusto per prevenire gli attacchi DDoS.
Un caso di studio reale: un'azienda di e-commerce utilizzava una rete VXLAN centralizzata per la creazione del proprio sito. Durante i periodi di picco, l'utilizzo della CPU del gateway raggiungeva il 90%, causando lamentele da parte degli utenti a causa della latenza. Il passaggio a un modello distribuito ha risolto il problema, consentendo all'azienda di raddoppiare facilmente la propria scalabilità. Al contrario, una piccola banca ha insistito su un modello centralizzato perché dava priorità agli audit di conformità e trovava la gestione centralizzata più semplice.
In generale, se si cercano prestazioni e scalabilità di rete estreme, un approccio distribuito è la soluzione ideale. Se il budget è limitato e il team di gestione non ha sufficiente esperienza, un approccio centralizzato risulta più pratico. In futuro, con l'avvento del 5G e dell'edge computing, le reti distribuite diventeranno più diffuse, ma le reti centralizzate manterranno la loro validità in scenari specifici, come l'interconnessione delle filiali.
Broker di pacchetti di rete Mylinking™Supporto per VxLAN, VLAN, GRE e rimozione dell'intestazione MPLS.
Supportava l'intestazione VxLAN, VLAN, GRE, MPLS rimossa dal pacchetto dati originale e l'output inoltrato.
Data di pubblicazione: 9 ottobre 2025
