Il blueprint chiama questo obiettivo «VCF Network Gateway», ma nella console quella voce non compare con quel nome: ciò che dispieghi è la connettività di rete della piattaforma, e la prima schermata del wizard ti chiede solo il Gateway Type. Da quella scelta discende il resto: fra gateway centralizzato e distribuito cambia se dovrai accendere nodi NSX Edge.

Centralizzato o distribuito

Una connessione centralizzata instrada il traffico attraverso un gateway NSX ospitato su nodi Edge. Serve quando l’ambiente richiede i servizi NSX a pieno regime — DHCP, NAT, servizi di livello 3 — e quando vuoi routing dinamico verso il fabric fisico, BGP o OSPF. Il prezzo è che i nodi Edge vanno dispiegati, dimensionati e gestiti nel tempo.

Una connessione distribuita collega il transit gateway direttamente alle VLAN provisionate sul fabric, che vivono sugli host ESX: niente Edge, niente routing dinamico, configurazione minima sugli switch fisici. In cambio ottieni networking on demand, routing distribuito, NAT 1:1 (gli External IPs) e un server DHCP distribuito; non NAT stateful, non VPN, non load balancer. I prerequisiti sono netti: VLAN dedicate su tutti gli host ESX che offrono VPC, ICMP redirect disabilitato sul gateway esterno, blocchi IP esterni che coincidano con le subnet di quelle VLAN o ne siano un sottoinsieme.

Il wizard, da NSX Manager o da vCenter

Da NSX Manager il percorso è System > Quick Start > Setup Network Connectivity > Configure NSX Networking, con ruolo NSX Administrator. In VCF 9.0 lo stesso lavoro si fa dal vSphere Client sotto Networks > Network Connectivity: novità sostanziale, perché il VI admin configura la connettività senza entrare in NSX Manager.

Scegliendo il centralizzato, la pagina successiva crea l’edge cluster: nome, Tunnel Endpoint MTU ereditato dalle Global Fabric Settings, form factor dell’Edge (Medium è il predefinito), domini di ricerca, server DNS, credenziali CLI e password di root. Servono almeno due nodi Edge e il cluster ne accetta fino a dieci; la memoria va riservata al 100%, i record DNS devono esistere prima, e il port group di management degli Edge va tenuto separato da quello di management degli host ESX. La pagina Workload Domain Connectivity definisce poi il gateway: nome, HA mode (Active/Active o Active/Standby), tipo di routing (BGP o statico) con l’ASN locale, gli uplink e i blocchi IP — VPC External IP Blocks e Private-Transit Gateway IP Blocks.

Cosa deve essere già pronto

Il wizard non inventa il substrato. Il cluster ESX dev’essere già preparato come transport node, con un Transport Node Profile applicato e NSX attivo sul distributed port group. Dalla 9.0 il VI admin può fare questa preparazione da vCenter tramite i vSphere Configuration Profiles, ma su un cluster VCP NSX Manager blocca ogni operazione CRUD, disinstallazione compresa.

Le transport zone decidono quali transport node vedono quale segmento: un Edge ne vuole almeno due, una overlay e una VLAN per gli uplink; un host può stare in più zone, un segmento in una sola. L’uplink profile (System > Fabric > Profiles > Uplink Profiles) porta la teaming policy, il Transport VLAN ID — che etichetta solo il traffico overlay — e un MTU che, se valorizzato, prevale sul tunnel endpoint MTU. Sull’MTU la regola è secca: minimo 1600 byte, raccomandati 1700, con i TEP degli Edge allineati a quelli degli host della stessa transport zone.

Il gateway centralizzato poggia su un Tier-0 (Networking > Tier-0 Gateways > Add Tier-0 Gateway) associato a un edge cluster. Le interfacce sono External, Service o Loopback; le transit subnet hanno predefiniti da ricordare: 169.254.0.0/24 interna, 100.64.0.0/16 fra Tier-0 e Tier-1. Ogni nodo Edge accetta fino a due gateway uplink, e per ciascuno compili VLAN dell’interfaccia, IP dell’interfaccia, MTU e, in BGP, BGP Peer IP, Peer ASN, password ed eventualmente BFD per accorgerti in fretta della caduta del vicino. Con routing statico la documentazione suggerisce di usare l’HA VIP come next hop in Active/Standby.

Transit gateway, VPC ed external connection

Alla creazione di un NSX Project nasce automaticamente il suo transit gateway, e ogni progetto ne ha uno solo. Il TGW fa comunicare le VPC fra loro e le porta fuori tramite le External Connections, create dal Default (/infra) e condivise col progetto: così non serve condividere un Tier-0 direttamente col tenant. Un TGW accetta una sola connessione centralizzata oppure più connessioni distribuite. Dentro il progetto, le VPC hanno subnet di tipo Private-VPC, Private-Transit Gateway e Public.

Trappole tipiche d’esame

  • VCF Networking non è VCF Operations for Networks. Il primo è NSX; il secondo è lo strumento di visibilità, installato da Fleet Management > Lifecycle scegliendo operations-networks, con nodi Platform e Collector. Il blueprint lo chiama «VCF Network Operations», la documentazione di prodotto scrive «for Networks».
  • Distributed non fa tutto. Se lo scenario chiede NAT stateful, VPN, load balancing o peering BGP, la risposta è connessione centralizzata con nodi Edge. Il distribuito offre solo NAT 1:1 e DHCP distribuito.
  • Active-Active contro Active-Standby sul Tier-0. SNAT, DNAT, load balancing, firewall stateful e VPN sono supportati solo in active-standby. Il cambio di HA mode è ammesso solo se gira al più un service router, ed è bloccato se quei servizi sono configurati.
  • MTU: due voci, due default. Il Global Tunnel Endpoint MTU sta in Global Fabric Settings (default 1700), il Global Logical Interface MTU in Global Networking Config (default 1500). 1600 è il minimo assoluto, non il valore consigliato.
  • Edge VM e bare metal non si equivalgono. Entrambi usano DPDK, ma l’uplink profile di una Edge VM non supporta uplink di standby, mentre il bare metal sì; i membri di un edge cluster devono essere tutti dello stesso tipo, anche se le VM possono avere dimensioni diverse. Resta poi il vincolo: un solo Tier-0 per nodo Edge, molti Tier-1.