La rete di VCF 9.0 si legge su tre piani, e mezza dozzina di domande d’esame vive esattamente sulla loro confusione: il piano di gestione della piattaforma VCF, il piano di gestione e controllo di NSX, e il piano dati fatto di host ESX preparati come transport node e di nodi NSX Edge. Chi amministra davvero sa in quale console si trova ciascun oggetto; chi ha studiato solo il blueprint, no.

Dove finisce VCF e dove comincia NSX

Il network pool è un oggetto del piano di gestione VCF, non di NSX: raccoglie le subnet di un dominio di livello 2 e assegna automaticamente indirizzi IP statici alle porte VMkernel di vSAN, NFS, iSCSI e vMotion. Un pool di default nasce con il deployment, e per aggiungere host all’inventario globale bisogna prima crearne uno nuovo o estendere quello di default. Non ha nulla a che vedere con gli IP pool di NSX, che servono agli indirizzi dei tunnel endpoint.

Il piano di gestione e di controllo di NSX sta interamente nei nodi NSX Manager, che espongono via interfaccia e API il networking virtuale — segmenti, VPC, transit gateway — e gestiscono flussi e topologie. I modelli documentati sono tre: nodo singolo con un indirizzo VIP predisposto per l’espansione futura, cluster a tre nodi con VIP, cluster a tre nodi dietro un load balancer esterno. Il Global Manager, quando serve la federazione, ha il suo modello a tre nodi con VIP.

Il fabric: transport zone, transport node, profili

Le transport zone decidono quali transport node — e quindi quali VM — possono usare una certa rete. Si creano in System > Fabric > Transport Zones > Add Zone, scegliendo il Traffic Type fra Overlay Backed, Overlay Standard e VLAN; per l’overlay si imposta anche il Forwarding Mode IPv4 o IPv6, perché il dual stack non è supportato. La regola asimmetrica da mandare a memoria: un host transport node può appartenere a più transport zone, ma un segmento appartiene a una sola.

L’uplink profile (System > Fabric > Profiles > Uplink Profiles > Add Profile) definisce le policy degli uplink: teaming policy (Failover Order, Load Balance Source, Load Balance Source MAC Address), uplink attivi e in standby, eventuali LAG con LACP, la transport VLAN — che tagga solo il traffico overlay — e l’MTU. Sull’MTU la pagina di guidance è netta: il minimo richiesto è 1600 byte, il valore raccomandato per coprire tutte le funzioni è 1700, e si sale a 9000 se il fabric fisico lo regge. Il TEP MTU globale si imposta in System > Settings > Global Fabric Settings, l’MTU delle interfacce logiche in Networking > Global Networking Config, e va allineato anche l’MTU del VDS in vCenter.

Sugli host, Multi-TEP High Availability sposta le vNIC delle VM da un TEP guasto a uno sano dello stesso host ESX: un TEP è considerato guasto se non ha indirizzo IP o se tutte le sessioni BFD sono down. Servono almeno due TEP e due uplink attivi, e sono supportati solo TEP IPv4; il profilo si abilita via API. L’architettura di forwarding predefinita in VCF 9.x è Enhanced Datapath, nelle varianti EDP Standard ed EDP Dedicated, con lo stack Standard legacy tenuto solo per NIC vecchie; l’ECMP L4, che distribuisce sul hash a 5-tuple, richiede EDP ed è disattivato di default.

Segmenti, port group e preparazione degli host

Il segmento si aggiunge da Networking > Segments > Add Segment: nome, Connectivity (None, Tier-1 o Tier-0), Gateway IP in CIDR, transport zone — che determina se il segmento è overlay-backed o VLAN-backed — ed eventuale VLAN ID o range per il guest VLAN tagging. In vCenter lo stesso segmento compare come distributed virtual port group NSX. Attenzione a non confonderlo con i distributed port group discovered: sono i DVPG di vCenter scoperti da NSX quando si installa la sicurezza distribuita su un VDS, restano sincronizzati con vCenter, accettano profili come IP Discovery e SpoofGuard, ma il loro VLAN tag si modifica solo in vCenter.

Per il piano dati NSX gira su vSphere Distributed Switch: la preparazione dei cluster passa da vCenter con un Transport Node Profile creato lato NSX e il VDS definito a livello di cluster. Il vincolo che l’esame ama: per preparare una VM NSX Edge come transport node si può usare solo un host switch N-VDS, anche se poi le sue interfacce si attestano su port group di un VDS.

Connettività distribuita o centralizzata

Il workflow nuovo di 9.0 sta in System > Quick Start > Setup Network Connectivity > Configure NSX Networking, ed è disponibile in forma equivalente anche in vCenter (Networks > Network Connectivity > Configure Network Connectivity). La prima scelta è il Gateway Type.

Con Distributed Gateway il transit gateway si attesta direttamente su una VLAN del fabric: servono solo VLAN ID, Gateway CIDR IPv4 e i VPC External IP Blocks, il routing è distribuito sull’host, si ottengono NAT 1:1 e DHCP distribuito, e non si distribuisce nessun edge node né si configura routing dinamico. Prerequisito spesso dimenticato: ICMP redirect disabilitato sul gateway esterno.

Con Centralized Gateway il transit gateway passa da un Tier-0 ospitato su edge node: qui si ottengono i servizi di livello 3 a pieno regime, NAT, DHCP e routing dinamico BGP o OSPF. La procedura chiede nome dell’edge cluster, Tunnel Endpoint MTU, Edge Form Factor (Medium se non si sceglie), search domain e DNS, e da due a dieci nodi; poi HA mode Active Active o Active Standby, Gateway Routing Type BGP o Static con Local ASN, gli uplink del gateway e i blocchi IP per VPC e Private-Transit Gateway. Fra i prerequisiti: Transport Node Profile sul cluster ESX, l’opzione «Activate NSX on DVPG» sotto System > Fabric > Hosts, riserva di memoria al 100% per gli edge e ASN riservato.

Tier-0, Tier-1, VRF ed edge cluster

Il Tier-0 si crea da Networking > Tier-0 Gateways > Add Tier-0 Gateway scegliendo HA mode active-active (default) o active-standby, e in active-standby anche il failover mode preemptive o non-preemptive. Il Tier-1 (Networking > Tier-1 Gateways) si collega al Tier-0 con Linked Tier-0 Gateway; l’edge cluster è opzionale, ma senza di esso il Tier-1 resta distributed-only e non offre servizi stateful come NAT, load balancer o firewall. La route advertisement si spunta voce per voce: All Static Routes, All NAT IP’s, All DNS Forwarder Routes, All LB VIP Routes, All Connected Segments and Service Ports.

Un VRF gateway sotto un Tier-0 padre eredita HA mode, edge cluster, subnet di transito interne e T0-T1 e la configurazione BGP, ma mantiene connettività esterna propria e ammette indirizzamenti sovrapposti fra tenant. L’edge cluster si costruisce in System > Fabric > Nodes > Edge Clusters > Add Edge Cluster: un edge transport node appartiene a un solo cluster e tutti i membri devono essere dello stesso tipo, VM o bare metal. I metodi di installazione documentati sono l’interfaccia di NSX Manager (raccomandata), il vSphere Client o l’OVF Tool, e l’ISO via PXE sui server fisici.

Multi-tenancy: project, transit gateway, VPC

Un project è l’analogo di un tenant e si seleziona dal menu a tendina nella barra di NSX Manager; lo crea l’Enterprise Admin e isola oggetti di rete e di sicurezza. Alla creazione del project nasce automaticamente il suo transit gateway, uno solo per project: al posto di condividere direttamente il Tier-0 si condivide una External Connection a cui il TGW si aggancia — una sola se centralizzato, più di una se distribuito. Le VPC sono un ulteriore livello di multi-tenancy dentro il project (non esistono nello spazio Default): subnet isolate instradate insieme da un VPC gateway, nei tre tipi Private - VPC, Private - Transit Gateway e Public.

Trappole tipiche d’esame

  • Distributed vs Centralized connectivity. Se lo scenario cita BGP, OSPF, NAT stateful o servizi L3 a pieno regime, la risposta richiede edge node e Tier-0, quindi connettività centralizzata. Se cita «configurazione minima del fabric fisico, solo VLAN e IP, nessun edge da distribuire», è distribuita.
  • Transport zone: la regola è asimmetrica. Un host transport node può stare in più transport zone; un segmento sta in una sola. E VM in transport zone diverse non si parlano in livello 2, per quanto il segmento sembri identico.
  • N-VDS non è morto. Gli host ESX si preparano su VDS, ma una VM NSX Edge come transport node usa un host switch N-VDS. Chi risponde «VDS ovunque» perde il punto.
  • Project, transit gateway e VPC non sono sinonimi. Il TGW è uno per project e nasce da solo; la VPC vive dentro un project e mai nello spazio Default; la External Connection è ciò che si condivide, non il Tier-0.
  • Edge cluster e servizi stateful sul Tier-1. Un Tier-1 senza edge cluster funziona benissimo per il routing distribuito est-ovest ma non eroga NAT, load balancer o gateway firewall: lo scenario che chiede uno di questi servizi implica sempre l’assegnazione di un edge cluster.