Per parlare dei gateway VXLAN, dobbiamo prima parlare di VXLAN stessa. 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 le reti di piccole dimensioni, ma nei data center moderni, con le loro migliaia di macchine virtuali, container e ambienti multi-tenant, le VLAN sono insufficienti. VXLAN è nata, definita dall'Internet Engineering Task Force (IETF) nella RFC 7348. Il suo scopo è estendere il dominio broadcast di Livello 2 (Ethernet) su reti di Livello 3 (IP) utilizzando tunnel UDP.
In parole povere, VXLAN incapsula 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 se si fornisse a ciascuna rete virtuale una "carta d'identità", consentendo loro di muoversi liberamente sulla rete fisica senza interferire tra loro. 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 un'estensione fluida 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 VM (Virtual Machine). VXLAN consente a queste VM di percepirsi come parte della stessa rete di Livello 2, garantendo una trasmissione fluida di broadcast ARP e richieste DHCP.
Tuttavia, VXLAN non è una panacea. Operare su una rete L3 richiede la conversione da L2 a L3, 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 a quello reale. Il meccanismo di inoltro è il cuore e l'anima del gateway e 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 interconnesso. Analizziamolo passo dopo passo.
Innanzitutto, un pacchetto viene inviato dall'host sorgente (ad esempio una VM). Si tratta di un frame Ethernet standard contenente l'indirizzo MAC sorgente, l'indirizzo MAC di destinazione, il tag VLAN (se presente) e il payload. Dopo aver ricevuto questo frame, il VTEP sorgente verifica 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 (che include 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 pari a 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, si presenta come 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 garantire la corrispondenza con la VNI 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 interessati tramite flooding, affidandosi a gruppi multicast o alla replica dell'intestazione unicast (HER).
Il fulcro del principio di forwarding è la separazione tra il piano di controllo e il piano dati. Il piano di controllo utilizza la VPN Ethernet (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 vero e proprio, utilizzando tunnel VXLAN per una trasmissione efficiente.
Tuttavia, nelle distribuzioni reali, l'efficienza dell'inoltro ha un impatto diretto sulle prestazioni. Il flooding tradizionale può facilmente causare tempeste di trasmissione, soprattutto nelle reti di grandi dimensioni. Ciò rende necessaria l'ottimizzazione dei gateway: i gateway non solo collegano reti interne ed esterne, ma fungono anche da agenti ARP proxy, gestiscono le perdite di percorso e garantiscono i percorsi di inoltro più brevi.
Gateway VXLAN centralizzato
Un gateway VXLAN centralizzato, chiamato anche gateway centralizzato o gateway L3, viene in genere installato a livello edge o core di un data center. Funge da hub centrale, attraverso il quale deve transitare tutto il traffico cross-VNI o cross-subnet.
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 (subnet 10.1.1.0/24) e VNI 20000 (subnet 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 sulla subnet locale e lo inoltra al gateway centralizzato. Il gateway decapsula il pacchetto, prende una decisione di routing e quindi lo reintegra 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.
○Efficiente in termini di 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, facilitando l'integrazione con controller SDN come NSX Manager.
○Forte controllo di sicurezzaIl traffico deve passare attraverso il gateway, facilitando l'implementazione di ACL (Access Control List), firewall e NAT. Immaginate uno scenario multi-tenant in cui un gateway centralizzato può facilmente isolare il traffico dei tenant.
Ma non si possono ignorare le carenze:
○ Singolo punto di erroreIn caso di guasto del gateway, la comunicazione L3 sull'intera rete viene paralizzata. Sebbene il protocollo VRRP (Virtual Router Redundancy Protocol) possa essere utilizzato per la ridondanza, 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 da 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 del gateway aumenta esponenzialmente. In un esempio concreto, ho visto un data center finanziario utilizzare un gateway centralizzato. Inizialmente, funzionava senza problemi, ma dopo che il numero di VM è raddoppiato, 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 il funzionamento efficiente dei gateway core.
Gateway VXLAN distribuito
Un gateway VXLAN distribuito, noto anche come gateway distribuito o gateway anycast, trasferisce le funzionalità del gateway a ciascun switch foglia o VTEP hypervisor. Ogni VTEP funge da gateway locale, gestendo l'inoltro L3 per la subnet locale.
Il principio è più flessibile: ogni VTEP è configurato con lo stesso 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. EVPN è particolarmente utile in questo caso: tramite BGP EVPN, il VTEP apprende i percorsi 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 è il VIP del VTEP locale (10.1.1.1). Il VTEP locale instrada verso la subnet di destinazione, incapsula il pacchetto VXLAN e lo invia direttamente al VTEP della VM B. Questo processo riduce al minimo il percorso e la latenza.
Vantaggi eccezionali:
○ Elevata scalabilitàDistribuire le funzionalità del gateway a ogni nodo aumenta le dimensioni della rete, il che è vantaggioso per le reti più grandi. I grandi provider cloud come Google Cloud utilizzano un meccanismo simile per supportare milioni di VM.
○Prestazioni superioriIl traffico est-ovest viene elaborato localmente per evitare colli di bottiglia. I dati dei test mostrano che la produttività può aumentare del 30-50% in modalità distribuita.
○Ripristino rapido dei guastiUn singolo guasto VTEP interessa solo l'host locale, lasciando inalterati gli altri nodi. Grazie alla rapida convergenza di EVPN, il tempo di ripristino è di pochi secondi.
○Buon uso delle risorseUtilizza il chip ASIC dello switch Leaf esistente per l'accelerazione hardware, con velocità di inoltro che raggiungono il livello di Tbps.
Quali sono gli svantaggi?
○ Configurazione complessaOgni VTEP richiede la configurazione del routing, dell'EVPN e di altre funzionalità, rendendo l'implementazione iniziale dispendiosa in termini di tempo. Il team operativo deve avere familiarità con BGP e SDN.
○Requisiti hardware elevatiGateway distribuito: non tutti gli switch supportano i gateway distribuiti; sono richiesti chip Broadcom Trident o Tomahawk. Le implementazioni software (come OVS su KVM) non offrono prestazioni paragonabili a quelle hardware.
○Sfide di coerenzaDistribuito significa che la sincronizzazione dello stato si basa su EVPN. Se la sessione BGP fluttua, potrebbe causare un buco nero nel routing.
Scenario applicativo: perfetto per data center iperscalabili o cloud pubblici. Il router distribuito di VMware NSX-T ne è un tipico esempio. In combinazione con Kubernetes, supporta perfettamente il networking dei container.
Gateway VxLAN centralizzato vs. Gateway VxLAN distribuito
Ora passiamo al punto cruciale: qual è la soluzione migliore? La risposta è "dipende", ma dobbiamo analizzare a fondo i dati e i casi di studio per convincervi.
Dal punto di vista delle prestazioni, i sistemi distribuiti sono nettamente superiori. In un tipico benchmark di un 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 l'inoltro a velocità di linea perché sfruttano il routing ECMP (Equal Cost Multi-Path) Spine-Leaf.
Un altro campo di battaglia è la scalabilità. Le reti centralizzate sono adatte a reti con 100-500 nodi; oltre questa scala, le reti distribuite prendono il sopravvento. Prendiamo Alibaba Cloud, ad esempio. La loro VPC (Virtual Private Cloud) utilizza gateway VXLAN distribuiti per supportare milioni di utenti in tutto il mondo, con una latenza a singola regione inferiore a 1 ms. Un approccio centralizzato sarebbe crollato da tempo.
E 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 foglia supportino l'offload VXLAN, con conseguenti costi di aggiornamento hardware più elevati. Tuttavia, a lungo termine, una soluzione distribuita offre costi di O&M inferiori, poiché strumenti di automazione come Ansible consentono la configurazione batch.
Sicurezza e affidabilità: i sistemi centralizzati facilitano la protezione centralizzata, ma presentano un rischio elevato di singoli punti di attacco. 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 ha utilizzato una VXLAN centralizzata per realizzare il proprio sito. Durante i periodi di picco, l'utilizzo della CPU del gateway è salito al 90%, causando lamentele da parte degli utenti in merito alla latenza. Il passaggio a un modello distribuito ha risolto il problema, consentendo all'azienda di raddoppiare facilmente le sue dimensioni. Al contrario, una piccola banca ha insistito su un modello centralizzato perché dava priorità agli audit di conformità e trovava più semplice la gestione centralizzata.
In generale, se si punta a prestazioni e scalabilità di rete estreme, un approccio distribuito è la soluzione ideale. Se il budget è limitato e il team di gestione non ha esperienza, un approccio centralizzato è più pratico. In futuro, con l'avvento del 5G e dell'edge computing, le reti distribuite diventeranno più diffuse, ma le reti centralizzate continueranno a essere preziose in scenari specifici, come l'interconnessione tra filiali.
Broker di pacchetti di rete Mylinking™supporta VxLAN, VLAN, GRE, MPLS Header Stripping
Supporta l'intestazione VxLAN, VLAN, GRE, MPLS rimossa nel pacchetto dati originale e inoltrata in output.
Data di pubblicazione: 09-10-2025
