In vSphere Foundation la rete è quella di vSphere e basta. Non ci sono segmenti overlay, gateway T0/T1 o distributed firewall: VVF non include NSX. Quello che ti resta — e che l’esame ti chiede di riconoscere in uno scenario — è una catena di oggetti che parte dalla scheda fisica dell’host e arriva alla vNIC della macchina virtuale. Tenerla in testa come sequenza è il modo più rapido per rispondere a una domanda che ti descrive un sintomo e ti chiede quale componente è coinvolto.

La scheda fisica dell’host si chiama vmnic e non è un oggetto configurabile di rete: è hardware. Diventa un uplink solo quando la assegni a uno switch virtuale, e da quel momento è il ponte fra la rete virtuale e lo switch fisico a monte. Lo switch virtuale — standard o distributed — è l’oggetto che inoltra i frame, e la documentazione lo descrive esplicitamente come un dispositivo che «funziona come uno switch Ethernet fisico»: impara quali VM sono attaccate alle sue porte virtuali e instrada di conseguenza.

Sopra lo switch stanno i port group. Un port group non trasporta traffico: è un modello di configurazione. Definisce come una connessione attraversa lo switch verso la rete, e porta con sé VLAN ID, policy di teaming, security e traffic shaping. Le VM si collegano a un port group tramite la loro vNIC; l’host si collega a un port group tramite un adattatore VMkernel. Questa è la biforcazione che l’esame ama: traffico di workload da una parte, traffico dell’host dall’altra, entrambi su port group ma con oggetti terminali diversi.

Standard switch e distributed switch: dove vive la configurazione

Un vSphere Standard Switch esiste su un singolo host e si configura da Host > Configure > Networking > Virtual switches > Add Networking. Se hai otto host, hai otto vSS da tenere allineati a mano, e un errore di battitura in un’etichetta di rete su uno solo di essi rompe vMotion verso quell’host.

Un vSphere Distributed Switch «agisce come un singolo switch su tutti gli host associati in un data center»: il piano di controllo vive in vCenter, il piano dati resta su ciascun host. Si crea con il tasto destro sul data center, Distributed Switch > New Distributed Switch, scegliendo versione (9.0.0 in giù, per compatibilità ESX), numero di uplink e se attivare Network I/O Control. I port group di un vDS si chiamano distributed port group e i port group che rappresentano gli uplink sono un oggetto a parte, l’uplink port group.

Alcune capacità esistono solo sul vDS: Network I/O Control, traffic filtering and marking, port mirroring, port blocking e i LAG con LACP. Anche il traffic shaping cambia natura: sullo standard switch ESX modella soltanto il traffico in uscita dalla VM, sul distributed switch agisce in ingress e in egress. I parametri sono gli stessi tre — average bandwidth e peak bandwidth in bit al secondo, burst size in byte.

Il VMkernel adapter e i suoi servizi

Il layer VMkernel è quello che dà connettività all’host, non alle VM. Quando crei un adattatore VMkernel gli abiliti uno o più servizi: Management, vMotion, Provisioning, IP storage per iSCSI e NFS, Fault Tolerance logging, vSphere Replication, vSAN, vSphere Backup NFC, NVMe over TCP e NVMe over RDMA. La raccomandazione ufficiale è dedicare un VMkernel separato a ciascun tipo di traffico.

Distinto dai servizi, e spesso confuso con essi, c’è lo stack TCP/IP: Default, vMotion, Provisioning, Mirror, più eventuali stack personalizzati. Uno stack dedicato ha routing table, default gateway e impostazioni DNS proprie. Scegliere lo stack vMotion in fase di creazione non è la stessa cosa che spuntare il servizio vMotion sullo stack Default, ed è una scelta che non si cambia dopo.

VLAN: chi mette il tag

Tre modalità, distinte dal VLAN ID configurato sul port group.

  • EST (External Switch Tagging) — VLAN ID 0. Tagga lo switch fisico; gli uplink dell’host vanno su access port.
  • VST (Virtual Switch Tagging) — VLAN ID da 1 a 4094. Tagga lo switch virtuale prima che il pacchetto lasci l’host; gli uplink vanno su trunk port. È il caso normale.
  • VGT (Virtual Guest Tagging) — tagga il guest OS, che deve avere un driver 802.1Q. Sullo standard switch si esprime con VLAN ID 4095; sul distributed switch si specificano invece intervalli o singole VLAN ammesse, che è una versione più controllabile dello stesso comportamento.

Teaming, failover e le policy che si ereditano

Le policy di teaming and failover, security, VLAN e traffic shaping si applicano a livello di switch o di port group e si ereditano verso il basso: quanto imposti sullo standard switch si propaga ai suoi port group, e un port group può fare override. Sul vDS l’override arriva fino alla singola porta distribuita.

Il bilanciamento sceglie quale uplink usa un flusso: instradamento sulla porta virtuale di origine (il default), sull’hash del MAC sorgente, sull’hash IP, ordine di failover esplicito, e — solo su vDS — in base al carico della NIC fisica. L’IP hash è l’unico che pretende una configurazione corrispondente sullo switch fisico (EtherChannel o LAG), e attivarlo senza quella configurazione a monte è il classico modo di far cadere metà del traffico.

Il rilevamento del guasto è Link status only o Beacon probing; il failback è attivo di default, il che significa che un uplink che torna su riprende subito il traffico — comportamento indesiderato se il link risale prima che lo switch fisico sia pronto a inoltrare. La security policy resta la solita terna: promiscuous mode, MAC address changes, forged transmits.

Dove la rete incontra il Supervisor

Su VVF il Supervisor si attiva con networking basato su vSphere Distributed Switch, e tutti gli host dei cluster che lo sostengono devono stare sullo stesso vDS. Poiché non c’è NSX a fornire load balancing, serve un bilanciatore: il Foundation Load Balancer incluso, oppure Avi. Le workload network sono distributed port group assegnati ai vSphere Namespace.

Qui cade il limite che vale la pena imparare invece di ignorare: i vSphere Pod «sono supportati solo con Supervisor configurati con NSX come networking stack». Su VVF, quindi, i container non girano come vSphere Pod ma dentro i cluster VKS.

Trappole tipiche d’esame

  • Port group e VLAN vengono scambiati per la stessa cosa. Il port group è il contenitore di policy; la VLAN è uno dei suoi attributi. Due port group sulla stessa VLAN sono legittimi e comunissimi, e si distinguono per teaming o shaping.
  • VMkernel confuso con vNIC. Se lo scenario parla di vMotion, vSAN, NFS o management, l’oggetto è un adattatore VMkernel dell’host. Se parla di connettività della macchina virtuale, è una vNIC su un port group. Nessuna VM «usa» un VMkernel.
  • Servizio abilitato contro stack TCP/IP. Spuntare il servizio vMotion e selezionare lo stack vMotion sono due decisioni diverse: solo la seconda dà all’adattatore un gateway proprio, e non è reversibile a posteriori.
  • Feature del vDS attribuite al vSS. Network I/O Control, LACP, port mirroring, traffic filtering, shaping in ingresso: niente di tutto questo esiste sullo standard switch. Se la risposta corretta nomina una di queste, lo switch è distributed.
  • Il riflesso NSX. Appena compare la parola «container», «Kubernetes» o «load balancer», la memoria suggerisce NSX. Su VVF non esiste: il networking del Supervisor è VDS e il bilanciatore è il Foundation Load Balancer, con i vSphere Pod fuori portata e i workload nei cluster VKS.