Da VMware NSX a Proxmox VE SDN? Si può.

NSX incapsula il traffico dei segmenti in Geneve e distribuisce il routing su tutti gli host. L'SDN di Proxmox VE fa la stessa cosa con protocolli standard: le reti virtuali (VNet) di una zona EVPN viaggiano in VXLAN tra i nodi, e la raggiungibilità degli indirizzi viene scambiata in BGP EVPN da FRR, presente su ogni nodo.

Il gateway di ogni subnet esiste su tutti i nodi con lo stesso indirizzo, come il Tier-1 distribuito di NSX. Il traffico tra subnet diverse viene instradato dal nodo su cui gira la VM, senza passare da un router centrale. Ogni zona ha la sua VRF: produzione e sviluppo non si vedono a livello di routing. Se zone diverse devono usare le stesse subnet, ognuna esce da un proprio router di frontiera, come facciamo per i tenant dei service provider.

Tutto è definito nella configurazione del cluster. Si crea una VNet una volta e la si ritrova su ogni nodo.

Il traffico che esce dalle zone EVPN passa dagli exit node, due nodi Proxmox VE indicati nella configurazione della zona, e da lì a router virtuali MikroTik Cloud Hosted Router, macchine virtuali con RouterOS su nodi diversi del cluster. I CHR ricevono in BGP dagli exit node le subnet delle VNet e le annunciano ai router fisici. In senso opposto passano agli exit node la rotta di default.

Sui CHR configuriamo NAT, filtri in ingresso, VPN IPsec e WireGuard. Se serve estendere un segmento di livello 2 verso un'altra sede, lo trasportiamo in VXLAN dentro il tunnel cifrato, mai in chiaro. Due CHR in VRRP, con BFD sulle sessioni BGP, garantiscono l'alta disponibilità: se un router o il suo nodo si ferma, l'altro prende gli indirizzi virtuali e i router fisici spostano il traffico in pochi secondi.

Perché MikroTik? Perché RouterOS è un sistema di routing completo e maturo, con BGP, OSPF, VRRP, VPN e firewall, licenze semplici a fascia di velocità e un costo che non ha nulla a che vedere con quello di NSX.

Il distributed firewall di NSX applica le regole sulla scheda di rete di ogni VM. Il firewall di Proxmox VE lavora allo stesso livello: le regole si applicano alla singola macchina virtuale, indipendentemente da dove gira nel cluster.

Le regole si organizzano in security group riutilizzabili per ruolo (web, applicativo, database, gestione) e usano IPSet e alias come elenchi di indirizzi. I gruppi dinamici di NSX, basati su tag o nomi, diventano security group assegnati per ruolo e IPSet tenuti allineati dall'automazione. Prima di tradurle osserviamo il traffico reale per qualche settimana. Quasi sempre una parte delle regole NSX non viene mai usata, e la nuova configurazione risulta più piccola e più leggibile dell'originale.

Un'informazione che preferiamo darti subito: Proxmox considera pienamente supportato il nucleo dell'SDN, cioè le VNet e la loro integrazione nel cluster, mentre il routing con FRRouting e l'integrazione dei controller, su cui si basano le zone EVPN, sono ancora classificati come anteprima tecnologica nella documentazione ufficiale (Proxmox VE 9.2). Per questo non chiediamo di fidarsi sulla parola. Prima della migrazione costruiamo un piccolo cluster Proxmox VE con la tua topologia: una zona EVPN con i suoi exit node, due CHR, i segmenti e le regole di un ambiente reale. Il tuo team verifica routing, failover dei router, live migration con mantenimento del gateway e applicazione delle regole firewall.

Durante la migrazione NSX e la nuova rete convivono. Per ogni gruppo di segmenti spostiamo le rotte e le macchine insieme, con indirizzi IP e gateway invariati.