NSX Logical Routing Architecture — Parte 1

Indice

1. Introduzione

2. Fondamenti del Logical Routing

3. Use Case del Logical Routing

4. Prerequisiti per abilitare il routing logico

5. Architettura Tier-0 / Tier-1

6. Traffico East-West vs North-South

7. Componenti Distributed Router (DR) e Service Router (SR)

8. Tipologie di interfacce dei gateway

9. Conclusione

Introduzione

VMware NSX introduce il concetto di routing logico (Logical Routing) per ottimizzare e scalare il traffico di rete di livello 3 (L3) in ambienti virtualizzati. In NSX, il routing logico permette di gestire in modo efficiente il traffico east-west (tra carichi di lavoro interni al data center) e north-south (verso/da l'esterno) evitando colli di bottiglia e semplificando l'architettura. Grazie a una combinazione di routing distribuito in kernel e servizi centralizzati su nodi Edge, NSX realizza un'infrastruttura di rete virtuale sicura e ad alte prestazioni, in grado di supportare ambienti multi-tenant e carichi variabili.

Questo blog (Parte 1) esplora l'architettura del logical routing in NSX, descrivendone i componenti chiave e il funzionamento. Verranno trattati i fondamenti (ottimizzazione del traffico east-west/north-south, scalabilità, multi-tenancy, sicurezza L3), i possibili scenari d’uso, i prerequisiti necessari e la struttura a due livelli (Tier-0/Tier-1) con i rispettivi ruoli. Inoltre, esamineremo la differenza tra traffico east-west e north-south e i componenti interni Distributed Router e Service Router, insieme alle diverse tipologie di interfacce dei gateway logici. Queste conoscenze di base sono fondamentali per comprendere come costruire reti virtuali efficienti e prepareranno il terreno per argomenti avanzati (come il routing dinamico, l'alta disponibilità ed ECMP) che saranno affrontati nella Parte 2.

Fondamenti del Logical Routing

I principali fondamenti e caratteristiche del logical routing in NSX possono essere riassunti nei seguenti punti:

• Ottimizzazione East-West e North-South: NSX implementa un instradamento distribuito in kernel per il traffico east-west interno al data center e un instradamento centralizzato efficiente per il traffico north-south verso l'esterno. Ciò significa che il traffico tra VM su host diversi viene instradato localmente (evitando “hairpinning” tramite router fisici), mentre il traffico destinato a reti esterne viene gestito in modo aggregato tramite appositi gateway su nodi Edge. Questa architettura riduce la latenza e migliora le prestazioni, ottimizzando i percorsi di routing nel cloud privato.

• Scalabilità: Il router logico NSX è distribuito sul kernel di ogni host ESXi, consentendo di scalare orizzontalmente la capacità di routing al crescere del numero di host e workload. Non essendoci un singolo appliance di routing attraverso cui passa tutto il traffico east-west, si eliminano colli di bottiglia centralizzati. Ogni host effettua il routing locale per i propri VM, mantenendo prestazioni costanti anche all’aumentare del traffico.

• Multi-tenancy nativo: L’architettura di NSX supporta nativamente ambienti multi-tenant, grazie a una struttura di routing a più livelli. È possibile definire router logici Tier-1 separati per differenti tenant (ad esempio per linee di business o clienti diversi), tutti collegati a un Tier-0 comune che funge da router provider. Questa separazione logica consente di isolare il traffico e le politiche di rete di ciascun tenant, mantenendo al contempo un controllo centralizzato sul Tier-0 da parte dell’amministratore della piattaforma. Il risultato è una suddivisione dei domini di controllo: i tenant possono gestire routing e sicurezza delle proprie reti, mentre l’admin del provider mantiene il controllo del routing a monte e della connettività esterna.

• Sicurezza L3 integrata: NSX integra la sicurezza a livello 3 direttamente nell’infrastruttura di routing. I gateway logici supportano servizi di sicurezza centralizzati come il Gateway Firewall (firewall sul router logico), i servizi NAT e VPN. In combinazione con il Distributed Firewall (micro-segmentazione) di NSX, questo permette di applicare policy di sicurezza granulari sia east-west (tra workload interni) che north-south (sul perimetro verso reti esterne) direttamente nei punti di instradamento del traffico. Ne consegue un ambiente più sicuro, in cui il traffico può essere filtrato e controllato a livello IP su ogni hop logico senza dipendere interamente da appliance fisici esterni.

In sintesi, il logical routing di NSX fornisce un’infrastruttura virtual router distribuita, altamente scalabile e multi-tenant, capace di ottimizzare i percorsi di rete interni ed esterni e di fornire servizi L3 avanzati (come firewall, NAT, VPN) integrati nell’ambiente software-defined. Queste caratteristiche rendono possibile la costruzione di data center virtuali agili, in cui rete e sicurezza sono definite via software e adatte a scenari cloud moderni.

Use Case del Logical Routing

Il routing logico in NSX trova applicazione in diversi scenari tipici. Di seguito alcuni use case rilevanti e il valore apportato in ciascuno:

• Supporto agli ambienti multi-tenant: NSX consente implementazioni sia single-tenant che multi-tenant, offrendo isolamento tra le reti di tenant differenti e la separazione delle relative politiche di rete e sicurezza. Ogni tenant può disporre dei propri segmenti logici e router Tier-1 dedicati, garantendo indipendenza operativa e protezione del traffico da altri tenant. Questo è ideale per cloud provider o grandi aziende multi-divisione che necessitano di suddividere l'infrastruttura di rete per cliente, reparto o applicazione, mantenendo al contempo un controllo centrale sul Tier-0 (router provider).

• Workload cloud-native e containerizzati: L’architettura NSX si adatta perfettamente a ambienti cloud e di container (Kubernetes, Cloud Foundry, ecc.), dove la velocità e dinamicità del provisioning di rete sono cruciali. Tramite logical routing è possibile collegare container e VM su overlay network virtuali indipendentemente dalla topologia fisica sottostante, fornendo connettività L3 automatica per micro-servizi e applicazioni containerizzate. Ad esempio, i pod Kubernetes su nodi diversi possono comunicare tramite segmenti logici NSX, con routing distribuito che garantisce bassa latenza tra microservizi. Il risultato è un networking self-service per ambienti DevOps, integrato con le piattaforme container senza dover riconfigurare gli apparati fisici.

• Percorsi di routing ottimizzati: In reti tradizionali, il traffico tra due VM su host diversi spesso deve “uscire” dalla rete per rientrare (hairpinning) passando da un router fisico centrale. Con NSX questo non è più necessario: il percorso di routing è semplificato e ottimizzato poiché avviene interamente a livello logico dentro l’hypervisor. Il traffico east-west tra VM (anche appartenenti a subnet diverse) viene instradato localmente dall’Distributed Router sull’host sorgente e inviato direttamente all’host di destinazione tramite l’overlay NSX, dove il Distributed Router locale consegna il pacchetto alla VM di destinazione. Ciò elimina hop inutili, riducendo latenza e utilizzo di bandwidth sui router fisici. Anche il traffico north-south beneficia di percorsi efficienti: le VM inviano il traffico destinato all’esterno al Service Router sul nodo Edge più vicino, evitando percorsi tortuosi attraverso la rete fisica interna. In definitiva, il logical routing produce routing path più corti e diretti all’interno del data center, migliorando prestazioni e prevedibilità della rete.

• Connettività verso l’infrastruttura fisica: NSX offre la capacità di estendere le reti logiche virtuali oltre i confini del mondo virtuale, fornendo connettività trasparente con la rete fisica esistente. Tramite i Tier-0 Gateway (router logici Tier-0), i segmenti overlay possono collegarsi a VLAN fisiche e ai router tradizionali a monte. Ad esempio, un Tier-0 può avere interfacce uplink verso un router core del data center, annunciando le subnet delle VM al resto della rete. Questo consente alle VM su reti logiche di comunicare con server fisici, internet o altri data center. La possibilità di estendere o collegare reti L2/L3 virtuali all’infrastruttura fisica facilita scenari come migrazioni live (VM mobility tra cloud privato e pubblico), integrazione con apparati fisici (es. firewall hardware o load balancer esistenti) e interconnessione multi-sito. In sostanza, NSX funge da ponte tra il mondo virtuale e quello fisico, unificando la connettività senza richiedere modifiche radicali alla topologia della rete tradizionale.

(I casi d'uso sopra descritti evidenziano la flessibilità di NSX nel supportare ambienti eterogenei e nel migliorare efficienza e isolamento della rete. Dall'agilità nel multi-tenant e cloud-native, fino alla continuità con le infrastrutture esistenti, il logical routing costituisce il fondamento di queste capacità.)

Prerequisiti per abilitare il routing logico

Prima di poter configurare e utilizzare il routing logico in NSX, è necessario assicurarsi che l’infrastruttura sia predisposta con alcuni prerequisiti fondamentali. In particolare, occorre che:

• NSX Management Cluster sia stato implementato ed operativo. L’NSX Manager (o cluster di manager) deve essere installato e funzionante, poiché fornisce il piano di controllo e gestione per distribuire le configurazioni di routing agli host e agli Edge.

• Transport Zone e N-VDS/VDS siano state create. Bisogna definire almeno una Transport Zone (overlay) e aver configurato uno switch virtuale NSX (N-VDS o VDS con NSX) associato, su cui verranno creati i segmenti logici e instaurati i tunnel.

• Gli hypervisor che ospiteranno i workload siano preparati come Transport Node ed aggiunti al plane di gestione NSX. Ciò implica che su ogni host ESXi (o KVM) sia installato il NSX Kernel Module e che l’host sia registrato nell’NSX Manager, in modo da poter eseguire le funzionalità di overlay e routing distribuito.

• I transport node (host transport e nodi Edge) siano collegati alle Transport Zone appropriate. Ogni nodo deve essere membro della/e Transport Zone su cui dovrà operare: tipicamente almeno una TZ overlay per connettività tra host (Geneve) e, per gli Edge, eventualmente una TZ VLAN per uplink fisici.

• Un’istanza di N-VDS/VDS sia presente su ciascun transport node. Quando un host o Edge viene preparato, viene creato uno switch virtuale NSX sul nodo (o si usa un VDS esistente integrato con NSX). Tale switch fornirà gli uplink fisici per incapsulare il traffico overlay (TEP) e connettere eventuali VLAN, e gli internal port per connettere le VM ai segmenti overlay.

• I NSX Edge Node siano stati deployati e configurati secondo i requisiti. I nodi Edge (siano essi VM virtuali o appliance bare-metal) devono essere installati, aggiunti al manager NSX e predisposti (es. con le interfacce uplink/TEP appropriate) prima di poter ospitare i servizi di routing centralizzato. Inoltre, è consigliabile che gli Edge siano organizzati in un Edge Cluster per garantire alta disponibilità e failover.

Solo soddisfacendo tutti i punti sopra, l'ambiente NSX sarà pronto per creare i Gateway Logici (Tier-0/Tier-1) e attivare il routing logico. In pratica, questi prerequisiti assicurano che esistano sia il control plane (NSX manager/controller) sia il data plane (transport nodes con tunnel overlay e Edge per uplink) necessari a instradare i pacchetti a livello virtuale. Ad esempio, senza un Edge Node non sarebbe possibile avere un Tier-0 connesso alla rete fisica, e senza transport nodes preparati non potrebbe esistere il router distribuito sugli host. Pertanto, questa checklist va completata prima di procedere con la configurazione dei router logici NSX.

Architettura Tier-0 / Tier-1

NSX adotta un’architettura di routing a due livelli (two-tier), composta da gateway logici Tier-0 e Tier-1. Questi componenti consentono di separare le funzioni di routing provider (a livello di data center) da quelle tenant (a livello di singola organizzazione o applicazione). A seconda delle esigenze, è possibile usare una topologia a singolo livello (single-tier) oppure una topologia multi-tier con due livelli:

• Topologia Single-Tier: prevede solo gateway Tier-0, ai quali sono collegati direttamente tutti i segmenti logici (le reti virtuali delle VM). In questa configurazione non ci sono router Tier-1. Il Tier-0 svolge sia il ruolo di instradamento east-west interno (distribuito sugli host) sia di gateway north-south verso l’esterno. La topologia single-tier è adatta per implementazioni più semplici o con un unico tenant, dove non serve isolamento tra diverse organizzazioni. In effetti, se non c’è necessità di delegare routing ai tenant, si può collegare direttamente i segmenti al Tier-0 e ottenere comunque tutti i benefici del routing distribuito in kernel. Nel caso single-tier, l’amministratore NSX (provider) gestisce un unico livello di router logico che funge da default gateway per tutte le VM e contemporaneamente provvede alla connettività con la rete fisica a monte.

Di seguito è illustrata una tipica topologia single-tier. Tutti i segmenti overlay delle VM sono connessi a un Tier-0 Gateway. Il Tier-0 include una componente distribuita (DR) presente su ogni transport node (hypervisor) per il routing locale east-west, e una componente di servizio (SR) in esecuzione su un NSX Edge Node per fornire connettività north-south verso i router fisici esterni.

Nell'esempio single-tier sopra, il Tier-0 DR (Distributed Router) risiede su tutti gli host, instradando localmente il traffico tra VM (percorso east-west). Il Tier-0 SR (Service Router) risiede sull'Edge Node ed è responsabile di portare all’esterno il traffico destinato al physical router (percorso north-south).

• Topologia Multi-Tier: prevede due livelli gerarchici di instradamento logico. Il livello Tier-0 rappresenta il router di provider (a livello di data center), mentre uno o più Tier-1 fungono da router di tenant collegati a valle del Tier-0. In questa topologia, i segmenti delle VM si connettono ai gateway Tier-1, e ciascun Tier-1 a sua volta si collega al Tier-0 (tramite una porta di RouterLink logica). Il Tier-0 rimane il punto di contatto con la rete fisica esterna, ma delega ai Tier-1 la gestione del routing per specifici gruppi di workload o tenant. La topologia multi-tier è utilizzata quando si desidera isolare domini di routing diversi (ad esempio diversi tenant, ambienti o applicazioni) sotto un comune Tier-0. Ogni Tier-1 può avere proprie tabelle di routing, servizi come NAT o Load Balancing dedicati, e politiche specifiche, mentre il Tier-0 si occupa solo di fornire connettività nord-sud e instradare il traffico tra i vari Tier-1 (inter-tenant) quando necessario.

Nel modello multi-tier, il Tier-0 e i Tier-1 lavorano in modo coordinato: i Tier-1 instradano il traffico east-west all'interno del loro dominio (in modo distribuito sugli host, come i Tier-0), e propagano le rotte delle loro sottoreti al Tier-0; il Tier-0 pubblica poi queste rotte verso l’esterno (tramite BGP/OSPF o statiche) e gestisce l’instradamento interdominio. Importante notare che l’uso di Tier-1 è opzionale: se non si necessita di multi-tenancy o separazione di domini, si può anche scegliere la topologia single-tier. Viceversa, se anche inizialmente viene adottato un solo Tier-1, NSX consente di scalare facilmente aggiungendo ulteriori Tier-1 in futuro per nuovi tenant senza dover toccare la configurazione del Tier-0 o della rete fisica sottostante. Questo è un vantaggio chiave: la presenza di un Tier-0 statico che funge da “provider router” permette di aggiungere o rimuovere intere topologie di tenant (Tier-1 + segmenti) con un impatto minimo.

Nel diagramma seguente è rappresentata una topologia multi-tier sia dal punto di vista logico che fisico. Si consideri un esempio con due Tier-1 gateway (Tenant A e Tenant B) collegati ad un Tier-0 comune:

Come illustrato sopra, logicamente il Tier-0 sta al vertice ed è connesso a più Tier-1 (ciascuno tipicamente appartenente a un tenant o contesto diverso). Ogni Tier-1 serve uno o più segmenti logici (reti VM) del proprio tenant. Dal punto di vista fisico, su ogni host hypervisor esisterà un'istanza di Tier-0 DR e Tier-1 DR per ciascun Tier-1 configurato (nell’esempio, Tier-1A DR e Tier-1B DR girano su tutti gli host, oltre al Tier-0 DR). Ciò significa che il routing east-west di ogni tenant avviene localmente sugli host, all’interno del rispettivo Tier-1 DR. Sul nodo Edge, invece, girerà sempre il Tier-0 SR (necessario per il north-south) e, se un Tier-1 ha bisogno di servizi centralizzati (ad esempio NAT, DHCP o load balancer), verrà instanziato sul cluster Edge anche un Tier-1 SR per quel Tier-1. Nell'esempio fisico mostrato, il Tier-1A SR e Tier-1B SR sono indicati con l’asterisco ad indicare che sono presenti solo se richiesti – ad esempio, se il Tenant A avesse un NAT configurato sul suo gateway Tier-1, ci sarebbe un Tier-1A SR su un Edge Node, altrimenti no.

Questa architettura a due livelli fornisce una chiara separazione delle responsabilità: l’amministratore infrastrutturale gestisce il Tier-0 (instradamento generale e politiche globali), mentre i tenant o amministratori applicativi possono gestire i propri Tier-1 (routing interno al tenant, segmenti e servizi dedicati) Il Tier-0 funge da punto di aggregazione: impara le reti dai Tier-1 e le annuncia al di fuori, e viceversa propaga ai Tier-1 la default route o altre rotte ricevute dalla rete fisica. Questo modello multi-tier favorisce la scalabilità operativa e l’agilità: nuovi tenant possono essere aggiunti creando semplicemente un Tier-1 e collegandolo al Tier-0 preesistente, senza coinvolgere i team di rete fisica per riconfigurazioni – il Tier-0 è già adiacente ai router fisici e si occupa di integrare le nuove reti automaticamente.

Nota: è possibile anche combinare i due approcci – ad esempio, avere alcuni segmenti collegati direttamente al Tier-0 (bypassando Tier-1) per servizi condivisi, mentre altri tenant utilizzano Tier-1 separati. NSX offre flessibilità nel design, ma conviene mantenere una chiara suddivisione: in ambienti multi-tenant, tutte le reti tenant dovrebbero stare dietro Tier-1 dedicati, riservando il Tier-0 solo all’interconnessione e ai servizi comuni.

Traffico East-West vs North-South

Un concetto fondamentale nel mondo NSX è la distinzione tra traffico east-west e north-south, e il modo in cui il sistema ottimizza il percorso di ciascuno. Come accennato, per traffico east-west si intende la comunicazione intra-data center tra workload (VM, container) all’interno dell’infrastruttura NSX – ad esempio traffico tra due VM su host diversi ma nella stessa sede. Il traffico north-south, invece, è il traffico che entra o esce dall’infrastruttura NSX verso l’esterno – ad esempio una VM che contatta un server su internet, o un client esterno che accede a un’applicazione ospitata nelle VM NSX.

East-West: NSX massimizza le prestazioni del traffico east-west tramite il routing distribuito. In pratica, quando due VM comunicano tra loro all’interno dell’overlay (anche se su subnet IP diverse), il loro traffico viene instradato localmente dall’istanza di Distributed Router (DR) presente sull’host. Non c’è bisogno che i pacchetti raggiungano un router centrale esterno: ogni host hypervisor esegue il routing nel kernel e può inviare direttamente i pacchetti all’host di destinazione tramite tunnel Geneve. Questo significa che il percorso east-west è sempre ottimale e rimane dentro l’infrastruttura virtuale, senza uscire verso la rete fisica. Ad esempio, nel caso di una topologia single-tier con Tier-0, se VM1 deve comunicare con VM2 (su host diverso), la sequenza è: VM1 invia al proprio Tier-0 DR locale che instrada verso la subnet di VM2, il pacchetto viene incapsulato e trasportato direttamente all’host di VM2 tramite l’overlay, dove il Tier-0 DR locale lo consegna a VM2. Il percorso copre quindi due segmenti: host sorgente -> host destinazione, passando logicamente per il DR distribuito (che è presente su entrambi gli host). Non c’è coinvolgimento di alcun Service Router o dispositivo fisico in questo flusso, perciò latenza e hop sono minimizzati.

Esempio di flusso East-West in topologia single-tier: due VM su host differenti comunicano attraverso il Tier-0 distribuito senza passare da un nodo Edge:

Nella figura sopra, VM1 invia il pacchetto al Tier-0 DR locale sul suo host (Host1), il quale lo incapsula nel tunnel Geneve (Overlay Tunnel). Il pacchetto viaggia fino all’Host2, dove viene decapsulato dal Tier-0 DR locale e inoltrato a VM2. Tutto il routing avviene tramite le istanze DR nei due host; la comunicazione resta interna all’overlay NSX e avviene con un singolo hop di rete (host-to-host). Questo è un tipico traffico east-west instradato in modalità distribuita.

Nel caso di topologia multi-tier, la logica è simile, salvo che il routing east-west può avvenire all’interno di un Tier-1 specifico. Ad esempio, due VM appartenenti allo stesso tenant (stessa Tier-1) ma su host diversi comunicano tramite il Tier-1 DR distribuito. Il pacchetto dal VM1 viene instradato dal Tier-1 DR sul suo host e inviato via overlay all’host di VM2, dove il Tier-1 DR locale lo consegna. Il Tier-0 non interviene affatto in questo scenario intra-tenant. Se invece il traffico east-west è tra tenant diversi (ad esempio VM in Tier-1 A che comunica con VM in Tier-1 B), allora il percorso coinvolgerà il Tier-0: VM -> Tier-1A DR -> Tier-0 DR -> Tier-1B DR -> VM. Anche in questo caso comunque il Tier-0 DR è distribuito (presente sugli stessi host), quindi il traffico non esce dall’infrastruttura NSX; sarà semplicemente il Tier-0 DR sul host a instradare tra i due domini prima di recapitare all’altro Tier-1 DR. A meno di policy che lo impediscano, NSX può dunque gestire anche traffico east-west inter-tenant interamente in modo virtuale. (Va considerato che di default i Tier-1 sono isolati, ma se configurato, il Tier-0 può permettere la comunicazione tra di essi, applicando ad esempio firewall centralizzati se necessario per controllo.)

Esempio di flusso East-West in topologia multi-tier: due VM nello stesso Tier-1 (Tenant A) su host diversi:

Come sopra, VM1 e VM2 appartengono al Tier-1 A: il loro traffico viene gestito interamente dal Tier-1 DR distribuito, restando confinato al dominio del tenant A senza passare dal Tier-0. In scenari simili, l’overlay NSX provvede a far recapitare i pacchetti tra host, mantenendo il traffico east-west locale al tenant.

North-South: Il traffico north-south, destinato a reti esterne (come la rete fisica aziendale o internet), deve passare attraverso un Service Router (SR) centralizzato per poter uscire dall’overlay. In NSX infatti l’SR funge da gateway verso l’esterno: possiede le interfacce uplink collegate ai segmenti VLAN fisici o peer BGP verso i router tradizionali. Quando una VM deve raggiungere un IP esterno non presente nell’overlay, il suo pacchetto verrà instradato dal DR locale fino a un Edge Node dove risiede l’SR, che poi lo inoltrerà fuori. Analogamente, i pacchetti in ingresso dall’esterno entrano tramite l’SR su un Edge e vengono consegnati al DR distribuito (e quindi alle VM) attraverso la rete overlay. Dato che l’SR risiede su nodi Edge (che tipicamente sono in numero ridotto rispetto agli host), il traffico north-south non è distribuito all’infinito, ma transita per questi punti centralizzati. NSX però permette ridondanza e scalabilità anche a questo livello: si può avere più Edge (in cluster) con istanze di SR in alta affidabilità o in ECMP attivo-attivo per gestire volumi di traffico elevati verso l’esterno. Inoltre, il fatto che solo il traffico destinato fuori dal dominio NSX debba attraversare l’SR significa che gran parte del traffico (quello east-west) rimane locale ed evita congestioni sull’uscita.

Esempio di flusso North-South in topologia single-tier: una VM invia traffico verso un server esterno (internet). Il pacchetto passa dal DR distribuito locale all’SR su un Edge, poi esce verso il router fisico:

Nell'esempio, la VM invia il pacchetto al Tier-0 DR locale; poiché la destinazione è esterna, il Tier-0 DR instrada il pacchetto verso l’SR (Service Router) del Tier-0, che risiede su un Edge Node. Il pacchetto attraversa l’overlay (Geneve) fino all’Edge, dove l’SR lo riceve e lo inoltra sull’interfaccia uplink fisica connessa al Physical Router. Da lì prosegue secondo le rotte tradizionali fuori dal dominio NSX. Per il traffico di ritorno, il percorso è invertito: arriva sull’SR tramite l’uplink fisico, e l’SR conosce (via routing) le subnet delle VM quindi lo recapita all’host corretto attraverso il Tier-0 DR distribuito.

Nel caso multi-tier, il traffico north-south di una VM segue un percorso simile, ma con un passo in più: deve risalire dal Tier-1 al Tier-0. Quando una VM sotto un Tier-1 vuole comunicare con l’esterno, il pacchetto va dal Tier-1 DR locale dell’host al Tier-0 DR (sempre sullo stesso host, tramite la porta RouterLink interna tra i due). Il Tier-0 DR poi instrada verso il Tier-0 SR su un Edge Node, da cui esce fuori. In formula: VM -> Tier-1 DR -> Tier-0 DR -> Tier-0 SR (Edge) -> rete fisica. Questo avviene in modo trasparente e automatizzato: NSX quando collega un Tier-1 a un Tier-0 configura implicitamente le rotte necessarie (il Tier-1 invia tutto il traffico esterno di default al Tier-0, e il Tier-0 conosce le rotte delle subnet interne del Tier-1). Se sul Tier-1 sono configurati servizi come NAT, questi verranno applicati dal Tier-1 SR (se presente) prima di consegnare il traffico al Tier-0. In generale comunque, l’ultimo hop prima di uscire è sempre un SR su Edge.

Esempio di flusso North-South in topologia multi-tier: una VM collegata a un Tier-1 invia traffico verso l’esterno:

Qui la VM parla con il Tier-1 DR locale; quest’ultimo inoltra il pacchetto al Tier-0 DR (sullo stesso host, tramite la connessione RouterLink). Il Tier-0 DR a sua volta invia il pacchetto attraverso l’overlay all’Edge Node dove risiede l’SR del Tier-0, che provvede all’instradamento fuori verso il Physical Router. Anche se il percorso include un passaggio in più (Tier-1 -> Tier-0), il principio rimane: l’instradamento dentro NSX è distribuito finché possibile (fino all’Edge), e solo l’uscita finale è centralizzata.

Riepilogando: il traffico east-west beneficia del routing distribuito NSX e rimane all’interno del fabric virtuale, con path corti e minimi attraversamenti di dispositivi. Il traffico north-south, invece, viene concentrato sui punti d’uscita (Edge), dove sono applicati servizi come NAT, firewall perimetrale o VPN se configurati, prima di entrare/uscire dalla rete tradizionale. Questo modello ibrido consente di ottenere il meglio dei due mondi: throughput e velocità per le comunicazioni interne al cloud privato, e controllo e sicurezza sui confini del data center.

Componenti Distributed Router (DR) e Service Router (SR)

Ogni gateway logico NSX (Tier-0 o Tier-1) è realizzato attraverso due componenti principali: il Distributed Router (DR) e il Service Router (SR). Insieme, queste componenti forniscono le funzionalità complete di un router logico, suddividendo però i compiti in modo da ottimizzare le prestazioni e supportare servizi avanzati. Di seguito descriviamo ruolo, posizionamento e connessione di DR e SR:

• Distributed Router (DR): è la componente di routing distribuita di un gateway NSX. Il DR gestisce il normale instradamento IP (L3) e si occupa di instradare il traffico tra segmenti logici connessi al router e verso eventuali router link inter-tier, il tutto in modo distribuito su ogni transport node. In pratica, una istanza di DR viene eseguita su tutti gli hypervisor (e sugli Edge) che partecipano alla transport zone, permettendo che il routing avvenga localmente in kernel vicino ai workload. Il DR fornisce le funzionalità base di forwarding IP: è come un router virtuale che ha interfacce logiche (LIF) collegate ai segmenti e/o ai Tier-0/Tier-1 link, e mantiene una tabella di routing. Quando una VM invia un pacchetto verso una subnet diversa, questo viene intercettato dal DR (sull'host) che lo instrada verso la destinazione appropriata (un altro segmento o verso il Tier-0). Tutte le rotte direttamente connesse (segmenti attaccati) sono presenti nel DR, e attraverso il control plane NSX i DR dei vari host rimangono sincronizzati. Grazie al DR, NSX realizza il concetto di routing distribuito a singolo hop: il DR funge da default gateway locale per le VM (first-hop router) e consente loro di comunicare senza hop aggiuntivi indipendentemente da dove risiedono. Dal punto di vista del posizionamento, il DR è un modulo kernel su ESXi (o processo user-space su KVM), quindi ha prestazioni molto elevate e scalabili con le risorse dell’host. Ogni gateway logico ha sempre un DR, anche i Tier-1 che non hanno servizi centralizzati, poiché il DR è ciò che implementa il routing di base e la connettività east.

• Service Router (SR): è la componente di routing centralizzata di un gateway NSX, deputata a gestire tutte le funzionalità che non possono essere distribuite a livello di hypervisor. In particolare l’SR è richiesto per: instradare il traffico north-south (verso reti esterne) e eseguire servizi di rete stateful che richiedono mantenere sessioni o modificare pacchetti (ad esempio NAT, DHCP relay, VPN, Load Balancer). L’SR viene eseguito sui NSX Edge Node, cioè su appliance dedicati che hanno connettività sia al mondo overlay che alle reti fisiche. A differenza del DR, ne esiste solo un numero limitato di istanze (in genere una o due per gateway, a seconda che sia in HA active/standby o active/active). Possiamo pensare all’SR come al “supervisore” centralizzato del router logico: mantiene le interfacce uplink fisiche (collegate a VLAN o peer esterni) ed effettua l’instradamento finale verso l’esterno. Inoltre, implementa le funzioni che richiedono uno stato centralizzato – ad esempio la traduzione degli indirizzi (NAT) o terminazione VPN – che per loro natura non possono essere semplicemente replicate su ogni host senza coordinamento. Un Tier-0 ha sempre un SR, perché deve per definizione collegarsi all’esterno (anche solo per una default route, necessita di un uplink su Edge). Un Tier-1 invece ha un SR solo se offre servizi che lo richiedono (NAT, Load Balancer, DHCP, etc.) e se è collegato a un Tier-0. Infatti, un Tier-1 puro L3 interno senza servizi può operare solo con il DR distribuito; nel momento in cui gli si configura ad esempio un NAT, NSX provvede a instanziare dinamicamente un SR per quel Tier-1 su un Edge Cluster associato, proprio per applicare quel NAT centralmente. Il posizionamento dell’SR su nodi Edge consente anche di assegnare risorse hardware dedicate (CPU/Memory) ai servizi di rete e di beneficiare di accelerazioni come DPDK o SmartNIC per i pacchetti in uscita. In sintesi, l’SR è lo strumento di NSX per interfacciarsi col mondo esterno e fornire servizi avanzati, complementando il DR distribuito che invece si occupa del forwarding locale.

Interconnessione DR-SR: sebbene concettualmente separati, il DR e l’SR di uno stesso gateway logico fanno parte di un unico router logico e devono quindi comunicare tra loro. NSX realizza automaticamente la connessione tra DR e SR tramite un collegamento interno chiamato intra-tier Transit Link (link di transito intratier). Si tratta di un’interfaccia virtuale punto-punto (con /30 o /31 IP) che unisce il DR al SR, permettendo al traffico instradato dal DR di “salire” all’SR e viceversa. Ad esempio, quando il DR decide che un pacchetto deve uscire dalla rete overlay, lo invia tramite il transit link al SR, che poi lo esce sull’uplink fisico. Questo avviene tutto all’interno del nodo Edge (quando DR e SR coesistono sull’Edge) oppure attraversando l’overlay (se il DR è su un host e l’SR su Edge, il pacchetto viaggia incapsulato fino all’Edge e lì arriva sul transit link verso SR). Il transit link è configurato automaticamente dal management plane NSX quando viene creato un router logico con SR, quindi non richiede intervento manuale. Oltre a ciò, NSX mantiene allineate le configurazioni tra DR e SR: ad esempio, le interfacce logiche collegate ai segmenti vengono rappresentate sul DR, mentre l’SR avrà tipicamente l’interfaccia uplink. Le rotte apprese dall’SR (es. da BGP esterno) vengono passate al DR, e le rotte locali del DR (segmenti) vengono rese note all’SR. Il tutto rende la coppia DR-SR un sistema unificato.

Instanziazione automatica: è importante evidenziare che l’amministratore non crea manualmente DR e SR – questi sono elementi interni a NSX. Quando si definisce un nuovo Tier-0 o Tier-1 via interfaccia NSX, il sistema dietro le quinte deploya il DR su tutti i nodi necessari e l’SR sugli Edge richiesti. Ad esempio, se creiamo un Tier-0 gateway e lo colleghiamo a un Edge Cluster, NSX instanzia immediatamente un Tier-0 DR su ogni transport node (ogni host e Edge) e un Tier-0 SR su uno o più Edge Node del cluster (a seconda del modello HA scelto). Se poi colleghiamo segmenti al Tier-0, i DR distribuiti li gestiranno; se configuriamo BGP o uplink, l’SR se ne occuperà. Analogamente per un Tier-1: finché rimane senza servizi centralizzati, esisteranno solo i DR distribuiti sugli host; non appena si abilita un servizio (ad esempio si attacca il Tier-1 a un Tier-0 o si configura un NAT), NSX farà comparire un SR per quel Tier-1 sugli Edge specificati. L’operatività è trasparente: l’utente vede un unico router logico, mentre NSX orchestra le sue componenti interne. In caso di Edge Cluster con ridondanza, l’SR può spostarsi su un altro Edge in caso di failure (failover) o essere replicato su più Edge (active-active). Il DR invece, essendo su tutti gli host, non necessita di failover – è intrinsecamente ridondante su ogni hypervisor.

In sintesi, Distributed Router e Service Router lavorano in tandem per implementare un router logico NSX completo. Il DR fornisce routing locale e scalabilità orizzontale (perfetto per traffico est-ovest intra-DC), mentre l’SR fornisce connettività e servizi centralizzati (necessari per traffico nord-sud e funzioni avanzate). Questa separazione di ruoli consente a NSX di ottimizzare il forwarding dove serve (sugli host) e al tempo stesso di avere punti di controllo unici per funzioni che richiedono uno stato (sugli Edge). L’architettura DR/SR è uno degli elementi chiave che distinguono il routing logico NSX dalle reti tradizionali, e comprenderla è fondamentale per progettare e operare ambienti NSX efficacemente.

Tipologie di interfacce dei gateway

I gateway logici NSX (Tier-0 e Tier-1) utilizzano diverse tipologie di interfacce per collegarsi alle entità di rete interne ed esterne. Ciascuna interfaccia ha uno scopo specifico nell’architettura. Ecco le principali categorie di interfacce dei router logici NSX e il loro ruolo:

• Uplink interface (uplink): è l’interfaccia utilizzata dal Tier-0 per connettersi verso l’esterno, ossia verso i router fisici o altre reti fuori dall’overlay. Le interfacce uplink sono tipicamente configurate sul Service Router del Tier-0 e mappate a una VLAN fisica (segmento VLAN) su un Edge Node. Attraverso l’uplink passano i pacchetti north-south: ad esempio, un Tier-0 uplink potrebbe avere un indirizzo IP in una subnet condivisa con il router fisico a monte, stabilire peer BGP e scambiare rotte. In configurazioni ridondate, un Tier-0 può avere più uplink (anche su Edge diversi) per collegarsi a multipli upstream router, implementando high availability o ECMP. L’uplink non viene usato dai Tier-1 (che non si connettono direttamente a reti fisiche).

• Downlink interface (downlink): è l’interfaccia che collega un router logico ai segmenti interni (logical switch). In altre parole, il downlink è il “port” attraverso cui un Tier-0 o Tier-1 fornisce connettività alle VM su una determinata rete logica. Ad esempio, se abbiamo un segmento logico Web (overlay) e lo connettiamo al Tier-1 Gateway di un tenant, quella connessione crea un’interfaccia downlink sul Tier-1 (che avrà un suo indirizzo IP gateway per la subnet Web). Tutto il traffico da/verso VM sul segmento Web passerà attraverso questa interfaccia downlink verso il router logico. I Tier-1 in genere hanno solo interfacce downlink (verso i segmenti) e una uplink (verso il Tier-0). I Tier-0 in topologia single-tier hanno downlink diretti verso i segmenti delle VM. Sia sulle interfacce downlink di Tier-0 che Tier-1 è possibile configurare servizi come DHCP relay o applicare firewall distribuiti (gateway firewall) per filtrare traffico tra segmenti e router.

• RouterLink port (router link): è l’interfaccia che collega un Tier-1 al Tier-0. Questo è un collegamento logico interno (completamente virtuale) che esiste solo quando un Tier-1 viene collegato al Tier-0. La porta RouterLink sul Tier-1 funge da “uplink” del Tier-1 verso il Tier-0, mentre sul Tier-0 appare come una porta downlink verso quel Tier-1. NSX assegna automaticamente un indirizzo IP a ciascuna estremità del link (tipicamente usando uno spazio IP di transit dedicato, di default 100.64.0.0/10 con /31 per ogni link). Questo permette ai due router logici di scambiarsi rotte: il Tier-1 impara dal Tier-0 la route di default (next hop l’IP della RouterLink del Tier-0) e il Tier-0 impara le rotte delle subnet connesse al Tier-1 (con next hop l’IP della RouterLink del Tier-1). In pratica, il RouterLink è l’equivalente di un collegamento punto-punto tra due router fisici in cascata. Non è qualcosa che l’utente crea manualmente come segmento: viene generato automaticamente al momento del collegamento Tier-1 -> Tier-0. Nel caso multi-tier, ogni Tier-1 avrà una porta RouterLink (uplink) che lo connette al Tier-0; dal lato Tier-0, vi saranno tante interfacce logical router link quanti Tier-1 collegati. Nei comandi e UI NSX, queste interfacce a volte sono indicate come Transit Link tra Tier-0 e Tier-1, ma da non confondere con il transit link intra-tier (DR-SR) descritto prima.

• Intra-Tier Transit Link: (da non confondere con il precedente) è l’interfaccia di transito interna che collega il DR e l’SR all’interno dello stesso router logico. Come già spiegato, funge da “ponte” tra la parte distribuita e la parte di servizio del gateway. Questo transit link intratier non è visibile o configurabile dall’utente nelle UI standard; è un dettaglio implementativo. Tuttavia è utile conoscerne l’esistenza per capire i percorsi del traffico: ad esempio, un pacchetto che dal DR deve passare all’SR percorre proprio questo link interno. Ogni router logico Tier-0 o Tier-1 che abbia un SR avrà una coppia di IP /30 o /31 riservati per il collegamento DR-SR. In caso di HA con Edge cluster, se un SR failover avviene, anche il transit link viene ricreato verso l’istanza DR sull’Edge secondario, in modo trasparente.

• Service interface: è un tipo speciale di interfaccia utilizzata per alcuni casi d’uso particolari, in genere legati a servizi L2 bridging o integrazioni con appliance di terze parti. Una service interface è tipicamente un’interfaccia su un Tier-0 o Tier-1 che si collega a una segment VLAN (rete VLAN tradizionale) non per fornire uplink IP, ma per estendere servizi. Ad esempio, su un Tier-1 si potrebbe configurare una service interface su una VLAN per collegare una VM di servizio (come un firewall di terza parte) in modo redirezionato: il Tier-1 può essere configurato per deviare specifici flussi verso quella interfaccia di servizio (che porta a un appliance esterno) e poi reintrodurli. Un altro esempio è il bridging L2: NSX permette di collegare un segmento overlay a una VLAN fisica tramite un Edge; questo avviene creando una service interface bridge su un Tier-0/Tier-1 che mappa l’overlay sulla VLAN. In sintesi, le service interface servono a integrazioni speciali su base VLAN e operano sul Service Router (Edge). Non sono comunemente utilizzate nelle configurazioni standard, se non quando si devono implementare scenari ibridi molto specifici.

Riassumendo, le interfacce di un gateway NSX si suddividono in: Uplink (verso l’esterno), Downlink (verso le reti interne delle VM), RouterLink (collegamento Tier-0 ↔ Tier-1), Transit intra-tier (collegamento interno DR-SR) e Service interface (per servizi speciali). Comprendere la differenza è importante per configurare correttamente il routing: ad esempio, sapremo che per collegare NSX al resto del mondo dobbiamo creare uplink su Tier-0, per collegare segmenti ai router useremo downlink, e che un Tier-1 collegato al Tier-0 avrà sempre in automatico un router link. La seguente tabella riepiloga le tipologie discusse:

• Uplink: Interfaccia Tier-0 verso router fisici (VLAN esterne).

• Downlink: Interfaccia verso segmenti/logical switch (Tier-1 o Tier-0).

• RouterLink: Connessione interna Tier-1 ↔ Tier-0 (transit IP tra router logici).

• Transit Link (intratier): Connessione interna DR ↔ SR sullo stesso router logico.

• Service Interface: Interfaccia speciale (tipicamente VLAN) su SR per servizi o integrazioni (es. bridging, partner services).

(Nota: quando si visualizzano i router logici tramite API o interfaccia di debug, queste interfacce appaiono come porte logiche con identificatori propri. In NSX, ciascuna interfaccia è chiamata Logical Interface (LIF). Ad esempio, un Tier-0 potrebbe avere LIF di tipo uplink, downlink e router-link. Sapere interpretare queste LIF aiuta nel troubleshooting avanzato, ma nelle configurazioni di alto livello l’utente gestisce concetti più astratti come “collega questo segmento al Tier-1” — dietro cui NSX crea una LIF downlink — o “collega il Tier-1 al Tier-0” — dietro cui NSX crea le LIF routerlink.)

Conclusione

In questa prima parte abbiamo esplorato l’architettura del Logical Routing in VMware NSX, delineando i suoi elementi costitutivi e principi di funzionamento. Abbiamo visto come NSX implementi un routing distribuito altamente efficiente per il traffico east-west e una gestione centralizzata ma scalabile per il traffico north-south, attraverso la combinazione di Distributed Router sugli hypervisor e Service Router sui nodi Edge. Questa suddivisione consente di ottenere al tempo stesso prestazioni e scalabilità (grazie al DR in kernel su ogni host) e funzionalità avanzate (grazie all’SR che connette all’esterno e offre servizi come NAT, firewall L3, etc.). L’architettura Tier-0/Tier-1 introduce inoltre un modello gerarchico a due livelli, fondamentale per abilitare ambienti multi-tenant e fornire isolamento e controllo granulare per diverse organizzazioni o applicazioni all’interno dello stesso data center virtuale. Abbiamo approfondito i concetti di traffico east-west vs north-south, chiarendo come NSX instradi i primi interamente nel dominio virtuale e gestisca i secondi attraverso punti di uscita dedicati, garantendo comunque percorsi ottimali e controllo sul traffico in ingresso/uscita.

Conoscere i componenti interni (DR e SR) e le interfacce di un router logico NSX è cruciale per progettare e operare la rete virtuale in modo corretto. Ad esempio, comprendere che ogni Tier-0/Tier-1 ha sempre un DR distribuito su tutti gli host e che l’SR appare solo quando necessario aiuta a prevedere il comportamento del sistema e a pianificare la capacità (sapendo dove avverrà l’instradamento di determinati tipi di traffico). Allo stesso modo, distinguere tra uplink, downlink e router link è essenziale quando si configurano collegamenti fisici o si collegano i router logici tra loro.

In conclusione, l’architettura di NSX Logical Routing offre un modo nuovo di pensare al routing: non più vincolato a dispositivi fisici centralizzati, ma distribuito nel software in tutto il data center, incapsulato nell’hypervisor stesso. Ciò porta benefici in termini di velocità, isolamento e automazione, allineandosi alle esigenze delle moderne infrastrutture cloud e Software-Defined Data Center. Nella Parte 2 di questa serie entreremo nel dettaglio di come configurare e ottimizzare il routing in NSX: esploreremo ad esempio l’aggiunta di route statiche e dinamiche (protocollo BGP/OSPF sul Tier-0), i meccanismi di ECMP e High Availability per i gateway, e analizzeremo packet walk dettagliati per consolidare la comprensione del flusso dei pacchetti attraverso DR e SR.

Grazie a questa solida base architetturale, il lettore è ora pronto per approfondire gli aspetti avanzati del routing logico NSX e applicarli efficacemente nel proprio ambiente IT. L’architettura presentata è il cuore pulsante che rende possibile il networking virtuale distribuito: padroneggiarla significa fare un passo deciso verso la piena realizzazione dei vantaggi del network virtualization nel proprio data center.