• Guide, Sistemi Operativi
• 11 Febbraio 2026

Quando lavorate con ambienti virtualizzati basati su Hyper-V, vi trovate spesso a gestire non solo le macchine virtuali, ma anche tutto ciò che ruota intorno alla rete: VLAN, segmentazione, isolamento dei tenant, accesso verso l’esterno e servizi come firewall o load balancing. Nelle infrastrutture tradizionali queste attività richiedono configurazioni manuali sugli apparati fisici e una stretta dipendenza dall’hardware di rete.

Il Software-Defined Networking in Windows Server 2025 cambia questo approccio, spostando il controllo della rete direttamente nello stack di virtualizzazione. In questo modello non è più l’infrastruttura fisica a dettare le regole, ma è la piattaforma Hyper-V che definisce in modo centralizzato come devono comunicare le macchine virtuali, come devono essere isolate e quali servizi di rete devono utilizzare.

Secondo Microsoft, il Software-Defined Networking è un modello che consente di configurare e gestire centralmente la rete e i servizi di rete all’interno del datacenter, astraendo la componente fisica e rendendo la rete una risorsa programmabile. In un ambiente Hyper-V questo si traduce nella possibilità di creare reti virtuali isolate, applicare policy di sicurezza, distribuire gateway e bilanciatori di carico, il tutto senza intervenire manualmente sugli switch fisici.

In questo articolo vedremo come funziona l’architettura SDN in Windows Server 2025, quali sono i componenti principali e come può essere utilizzata in uno scenario tipico basato su Hyper-V per rendere la rete più flessibile, automatizzabile e pronta per ambienti multi-tenant o ibridi.

Figura 1: Schema di comunicazione tra i diversi elementi che compongono l’infrastruttura di Software-Defined Networking

Installazione con il modulo PowerShell SDN Express

Il modulo PowerShell SDN Express è lo strumento che Microsoft mette a disposizione per distribuire automaticamente l’infrastruttura Software-Defined Networking all’interno di un datacenter basato su Windows Server.

In uno scenario SDN reale non dovete installare un singolo ruolo, ma un insieme coordinato di componenti: Network Controller, Software Load Balancer, gateway, certificati, configurazioni di rete, integrazione con il cluster e con Hyper-V. Farlo manualmente significherebbe eseguire decine di passaggi, con un’elevata probabilità di errori e inconsistenze tra i nodi.

Il modulo SDN Express serve proprio a questo: automatizzare l’intero processo di deployment partendo da un file di configurazione. In pratica, invece di installare e configurare ogni componente singolarmente, preparate un file .psd1 con i parametri dell’infrastruttura (nomi, indirizzi IP, certificati, nodi del cluster, ecc.) e lasciate che gli script del modulo eseguano tutte le operazioni necessarie.

Dal punto di vista architetturale, SDN Express si occupa di:

• installare i ruoli e le funzionalità richieste sui nodi,
• distribuire il Network Controller in alta disponibilità,
• configurare la rete host e le virtual network,
• preparare i componenti opzionali come SLB e gateway,
• applicare in modo coerente le impostazioni su tutti i server coinvolti.

Il motivo per cui Microsoft ne suggerisce l’uso è semplice: standardizza e velocizza il deployment, riducendo drasticamente i passaggi manuali e rendendo l’installazione ripetibile sia in ambienti di test che in produzione. In pratica, SDN Express rappresenta l’equivalente, per la rete definita dal software, di ciò che gli script di deployment fanno per un cluster Hyper-V o per un ambiente Azure Local.

Per maggiori informazioni visitate la pagina Deploy infrastructure for Software Defined Networking managed by on-premises tools using SDN Express for Azure Local, version 23H2 – Azure Local | Microsoft Learn

In una console PowerShell con privilegi elevati installate il modulo con il comando:

Install-Module -Name SdnExpress

Il modulo viene installato nel percorso standard dei moduli, tipicamente sotto C:\Program Files\WindowsPowerShell\Modules\SdnExpress\

Nota importante: Microsoft specifica che gli script SDN Express non sono più distribuiti su GitHub, e il canale di riferimento diventa il modulo.

Da qui, in un’installazione “reale”, il flusso Microsoft è: preparate il file di configurazione (psd1) e poi eseguite gli script SDN Express per distribuire i componenti (Network Controller e, se necessario, SLB e Gateway), con possibilità di fare un deployment “a fasi” partendo dal solo Network Controller.

Figura 2: Installazione del modulo PowerShell SdnExpress dal PowerShell Gallery, come suggerito dalla documentazione Microsoft per il deployment dell’infrastruttura SDN

Figura 3: Il modulo SdnExpress installato nel percorso dei moduli PowerShell, pronto per essere utilizzato nel deployment dell’infrastruttura SDN

Laboratorio di test con SDN Sandbox

Oggi vi propongo un laboratorio di test che vi consente di provare il Software-Defined Networking utilizzando un solo host fisico. In uno scenario reale, infatti, l’infrastruttura SDN richiede più server, ruoli distribuiti e componenti ridondati, con un impegno non indifferente in termini di hardware e tempo di configurazione.

Per evitare questa complessità e poter testare rapidamente le funzionalità principali, possiamo utilizzare SDN Sandbox, una raccolta di script realizzata da Bill Curtis che automatizza la creazione di un ambiente completo basato su Hyper-V. Il laboratorio sfrutta la nested virtualization per simulare un cluster, il domain controller, il Network Controller e tutti i componenti necessari al funzionamento dell’SDN.

In questo modo potete costruire un’infrastruttura di test interamente automatizzata, replicabile e soprattutto eseguibile anche su un singolo server, senza dover predisporre un ambiente fisico complesso. L’obiettivo non è realizzare un’architettura di produzione, ma avere un ambiente funzionante su cui sperimentare la creazione di reti virtuali, macchine tenant e servizi SDN.

Figura 4: Architettura del laboratorio SDN Sandbox: cluster a tre nodi in nested virtualization con Network Controller, Load Balancer e gateway, collegato alle reti di management e provider

Prerequisiti del laboratorio SDN Sandbox

Prima di iniziare con il deployment della sandbox è necessario verificare alcuni prerequisiti.

Secondo le indicazioni del progetto SDN Sandbox, il laboratorio richiede un server fisico con supporto alla virtualizzazione hardware e con Hyper-V installato. È necessario disporre di una quantità adeguata di memoria e spazio su disco, perché durante il deployment vengono create diverse VM che compongono il cluster, il domain controller e i componenti dell’infrastruttura SDN.

Sul sistema host devono essere disponibili:

• Windows Server con ruolo Hyper-V abilitato
• Supporto alla virtualizzazione hardware (Intel VT-x o AMD-V)
• Almeno una scheda di rete fisica
• Spazio su disco sufficiente per le macchine virtuali create dalla sandbox
• Immagini ISO di Windows Server 2025 da utilizzare per la creazione dei dischi VHDX

È inoltre necessario eseguire l’host con privilegi amministrativi e avere accesso a Internet per scaricare eventuali moduli PowerShell e dipendenze richieste dagli script.

I prerequisiti hardware per questo laboratorio non sono banali:

Preparazione dell’ambiente

Una volta verificati i prerequisiti, potete procedere con la preparazione del laboratorio.

Il primo passaggio consiste nello scaricare il progetto SDN Sandbox dal repository GitHub https://github.com/bliicurtis/SDN-SAndbox ed estrarlo in una cartella locale, ad esempio C:\SDNSandbox

Figura 5: Download del progetto SDN Sandbox dal repository GitHub di Bill Curtis, che contiene gli script necessari per creare automaticamente il laboratorio di test

All’interno della cartella troverete il file di configurazione SDNSandbox-Config.psd1, che contiene tutti i parametri utilizzati dagli script per creare l’ambiente. Qui potete modificare:

• nome del dominio,
• nome del domain controller,
• indirizzamento di rete,
• parametri delle macchine virtuali.

Per un laboratorio di test potete lasciare la maggior parte dei valori predefiniti e modificare solo i parametri principali, come dominio e nomi dei server.

Io ho modificato il file SDNSandbox-Config.psd1 con i parametri in figura. Di fatti ho cambiato solo nome del dominio e nome del domain controller lasciando tutto il resto invariato.

Figura 6: File di configurazione SDNSandbox-Config.psd1, dove vengono definiti dominio, percorsi dei dischi, memoria delle VM e parametri principali del laboratorio

Creazione dei dischi di base

Dopo aver configurato il file di configurazione, il passo successivo consiste nella creazione dei dischi VHDX che verranno utilizzati come base per le macchine virtuali del laboratorio.

Gli script della sandbox vi guidano nella creazione di:

• un disco con Windows Server Desktop Experience,
• un disco con Windows Server Core.

Durante questa fase dovrete indicare:

• il percorso dell’ISO di Windows Server,
• l’edizione da installare,
• il percorso in cui salvare i VHDX.

Questa operazione può richiedere diversi minuti, in base alle prestazioni dello storage.

Nella figura sotto viene eseguito lo script New-SDNVHDfromISO.ps1 dalla cartella C:\SDNSandbox. Questo script fa parte dell’SDN Sandbox e serve per creare i dischi VHDX di base che verranno poi utilizzati per generare automaticamente tutte le macchine virtuali del laboratorio.

Durante l’esecuzione, lo script richiede quale tipologia di immagine volete creare: GUI (Desktop Experience) oppure Core. In base alla scelta, verrà generato il relativo VHDX partendo dall’ISO di Windows Server, che verrà poi riutilizzato come template per le VM della sandbox.

Figura 7: Esecuzione dello script New-SDNVHDfromISO.ps1 per la creazione dei dischi VHDX di base, scegliendo tra immagine GUI o Core

Dopo aver avviato lo script New-SDNVHDfromISO.ps1, viene richiesto di selezionare l’immagine di Windows Server contenuta nel file ISO. Lo script monta automaticamente l’ISO indicata e mostra l’elenco delle edizioni disponibili nel file install.wim. In questo passaggio dovete scegliere l’edizione che verrà utilizzata per creare il disco di base della sandbox.

Figura 8: Selezione dell’edizione Windows Server 2025 Datacenter (Desktop Experience) dall’ISO per la creazione del disco VHDX di base

Dopo aver selezionato l’edizione di Windows Server, lo script procede con l’importazione dell’immagine dal file ISO e richiede il percorso in cui salvare il disco virtuale. In questo passaggio state definendo la posizione e il nome del file VHDX che verrà creato e utilizzato come immagine di base per le macchine virtuali con interfaccia grafica del laboratorio. Salvate il disco nel percorso C:\SDNVHDs\gui.vhdx

Figura 9: Salvataggio del disco gui.vhdx nel percorso C:\SDNVHDs, che verrà utilizzato come immagine base per le VM con Desktop Experience

Lo script importerà l’immagine di Windows Server 2025 dal file ISO e genererà il disco virtuale gui.vhdx a partire dal contenuto del file WIM. In questa fase il VHDX viene creato e preparato come immagine di base che verrà poi clonata per le macchine virtuali del laboratorio. Attendete il completamente della creazione del file gui.vhdx

Figura 10: Creazione del disco gui.vhdx a partire dall’immagine di Windows Server; attendete il completamento dell’operazione prima di proseguire

Rieseguite lo stesso script per generare il secondo disco di base, questa volta selezionando l’opzione CORE, che servirà per le macchine virtuali senza interfaccia grafica utilizzate nel laboratorio.

Figura 11: Riesecuzione dello script per generare anche il disco con immagine Windows Server Core

Come prima, dopo aver montato l’ISO, viene mostrato l’elenco delle edizioni disponibili nel file install.wim. In questo passaggio dovete selezionare l’edizione senza interfaccia grafica che verrà utilizzata come immagine di base per le VM Core del laboratorio. Scegliete l’opzione 3.

Figura 12: Selezione dell’opzione 3 – Windows Server 2025 Datacenter per la creazione del disco basato su immagine Core

Dopo aver selezionato l’edizione Core, lo script richiede il percorso in cui salvare il secondo disco virtuale. In questa fase state definendo la posizione e il nome del file core.vhdx, che verrà utilizzato come immagine di base per le macchine virtuali senza interfaccia grafica all’interno del laboratorio. Salvate in C:\DSNVHDs\core.vhdx

Figura 13: Salvataggio del disco core.vhdx nel percorso C:\SDNVHDs, che verrà utilizzato come immagine base per le VM Windows Server Core

Figura 14: Creazione del disco core.vhdx a partire dall’immagine Windows Server Core; attendete il completamento dell’operazione

Terminata la creazione del disco, potete verificare che in Esplora file è visibile la cartella C:\SDNVHDs con entrambi i dischi creati: gui.vhdx e core.vhdx.

Figura 15: Creazione completata: nella cartella C:\SDNVHDs sono disponibili i dischi gui.vhdx e core.vhdx pronti per il deployment della sandbox

Creazione automatica della sandbox SDN

Dopo aver preparato i dischi di base gui.vhdx e core.vhdx, potete avviare lo script principale della sandbox, New-SDNSandbox.ps1. Questo è il passaggio in cui il laboratorio prende realmente forma, perché lo script si occupa di creare e configurare automaticamente tutta l’infrastruttura necessaria.

Lo script legge i parametri definiti nel file SDNSandbox-Config.psd1 e utilizza le immagini VHDX appena generate per distribuire le macchine virtuali del laboratorio. Durante l’esecuzione vengono creati gli switch virtuali, configurata la rete interna e la NAT, preparato l’ambiente Hyper-V sull’host e copiati i dischi nelle posizioni corrette.

Successivamente lo script procede con la creazione delle VM che compongono l’ambiente: domain controller, nodi del cluster, macchine di gestione e tutti i componenti necessari per il funzionamento dell’SDN. Al termine dell’operazione vi ritroverete con un’infrastruttura completa, pronta per essere gestita tramite Windows Admin Center e per proseguire con il deployment dell’SDN.

L’intero processo è completamente automatizzato e può richiedere anche diverse ore, a seconda delle risorse disponibili sull’host. Una volta concluso, la sandbox sarà pronta per le configurazioni successive.

Figura 16: Esecuzione dello script New-SDNSandbox.ps1, che crea automaticamente l’intero laboratorio SDN partendo dai dischi di base

Attendete il completamento del deployment. Nel mio caso ci sono volute più di 2 ore.

in Hyper-V Manager si vedono le macchine virtuali create automaticamente dallo script e già in esecuzione.

Figura 17: Deployment della sandbox completato; le macchine virtuali del laboratorio sono state create e avviate automaticamente

Qui di seguito il particolare delle VM create sul nodo di Management.

Figura 18: VM create sul nodo di Management

Al termine del deployment, sul desktop dell’host viene creato automaticamente un collegamento a Windows Admin Center. Aprendo il link, compare la finestra di autenticazione in cui dovete inserire le credenziali configurate nel file SDNSandbox-Config.psd1. Queste credenziali consentono l’accesso all’ambiente di gestione del cluster e dell’infrastruttura SDN.

Figura 19: Accesso a Windows Admin Center utilizzando le credenziali definite nel file di configurazione della sandbox

Lanciate il collegamento al Windows Admin Center. All’apertura della console compare la finestra di autenticazione, dove dovete inserire le credenziali definite nel file SDNSandbox-Config.psd1 per accedere all’ambiente di gestione.

Figura 20: Avvio di Windows Admin Center e autenticazione con le credenziali configurate nella sandbox

Dopo l’accesso a Windows Admin Center, dalla schermata principale dovete aggiungere il cluster creato dalla sandbox. Nella sezione Server clusters selezionate Add e indicate il nome del cluster, in questo caso SDNCLUSTER, così da poterlo gestire direttamente dalla console.

Figura 21: Aggiunta del cluster SDNCLUSTER in Windows Admin Center dalla sezione Server clusters

Durante l’aggiunta del cluster in Windows Admin Center, la console rileva automaticamente i nodi che fanno parte del cluster. Se lasciate selezionata l’opzione Also add servers in the cluster, verranno aggiunti automaticamente anche gli host del cluster, così da poterli gestire singolarmente dalla stessa interfaccia.

Figura 22: Aggiunta del cluster SDNCLUSTER con rilevamento automatico degli host che ne fanno parte

Dopo l’aggiunta del cluster, nella schermata principale di Windows Admin Center compaiono sia il cluster sdncluster.virtual.lab sia i singoli nodi sdnhost1 e sdnhost2. Questo significa che il cluster è stato rilevato correttamente e che ora potete gestire l’intera infrastruttura e i singoli host direttamente dalla console.

Figura 23: Il cluster sdncluster e i relativi nodi sono stati aggiunti correttamente in Windows Admin Center

Avvio del deployment SDN da Windows Admin Center

Una volta aggiunto il cluster in Windows Admin Center, è possibile avviare la configurazione della piattaforma Software Defined Networking direttamente dall’interfaccia grafica. Dal menu laterale sinistro selezionate la sezione SDN infrastructure.

Il pulsante Get started avvia la procedura guidata di configurazione dell’infrastruttura Software Defined Networking (SDN) all’interno del cluster Hyper-V. Questa procedura automatizza il deployment dei componenti principali della fabric SDN utilizzando le risorse già presenti nel cluster.

In pratica, il wizard esegue le seguenti operazioni:

1) Raccolta delle informazioni di base

Vengono richiesti i parametri fondamentali per l’infrastruttura SDN, tra cui:

• Indirizzi IP per i nodi dell’infrastruttura.
• Rete di gestione.
• Configurazione del provider network.
• Credenziali amministrative.

Questi dati servono al Network Controller per orchestrare l’intera fabric.

2) Deployment del Network Controller

Il wizard distribuisce automaticamente:

• Le macchine virtuali del Network Controller.
• Le configurazioni di cluster e disponibilità.
• Le policy di comunicazione tra i nodi.

Il Network Controller è il control plane dell’SDN: da qui vengono gestite tutte le reti virtuali, le ACL e i servizi.

3) Configurazione dei servizi di rete SDN

Successivamente vengono predisposti:

• Software Load Balancer (SLB).
• Gateway (per connettività verso reti esterne o Internet).
• Reti virtuali di infrastruttura.

Questi componenti costituiscono il data plane dell’SDN.

4) Integrazione con il cluster

Il wizard:

• Collega i nodi Hyper-V al Network Controller.
• Configura gli switch virtuali e le estensioni necessarie.
• Abilita la gestione centralizzata della rete.

Figura 24: Connessione al cluster e accesso alla sezione SDN infrastructure in Windows Admin Center per avviare il deployment dell’SDN tramite il pulsante Get started

Native SDN in Windows Server 2025

Una delle novità più importanti dell’implementazione SDN in Windows Server 2025 è la modalità Native SDN, che semplifica in modo significativo l’architettura e il deployment rispetto alle versioni precedenti.

Nelle versioni di Windows Server fino alla 2022, il Network Controller veniva distribuito all’interno di macchine virtuali dedicate, tipicamente in un cluster di tre nodi, con una configurazione più complessa e diversi prerequisiti infrastrutturali. Questo approccio, chiamato Service Fabric, richiedeva più risorse, una gestione separata delle VM di infrastruttura e un processo di deployment più articolato.

Con Windows Server 2025 viene introdotto il modello Native SDN, in cui il Network Controller non viene più eseguito all’interno di macchine virtuali, ma come risorsa clusterizzata direttamente sugli host Hyper-V. In pratica:

• Il controller diventa un servizio nativo del cluster.
• Non è più necessario creare e gestire VM dedicate per il piano di controllo.
• Si riducono i requisiti hardware e la complessità operativa.
• Il deployment è molto più rapido e lineare.

Dal punto di vista architetturale, questo significa che il piano di controllo SDN è integrato direttamente nel cluster di virtualizzazione, con un modello più vicino a quello delle piattaforme hyper-converged moderne. L’alta disponibilità viene gestita dal cluster stesso, senza dipendere da un’infrastruttura Service Fabric separata.

Nel wizard di Windows Admin Center, la scelta Native SDN (Recommended) indica proprio questo nuovo modello. L’opzione Service Fabric resta disponibile solo per compatibilità con ambienti esistenti o scenari specifici, ma per i nuovi deployment Microsoft consiglia esplicitamente l’approccio nativo.

In un laboratorio come quello che stiamo realizzando, la modalità Native SDN consente di ottenere un’infrastruttura completa con meno macchine virtuali, tempi di provisioning ridotti e una gestione molto più semplice.

Figura 25: Scelta del tipo di infrastruttura: Native SDN

Nella schermata Cluster settings vengono definiti i parametri operativi del Network Controller. Qui si specificano il nome REST del controller, l’indirizzo IP di gestione, le credenziali amministrative e il percorso del database sul cluster. Inoltre, viene configurato il pool di indirizzi MAC che l’SDN utilizzerà per le macchine virtuali. Una volta completati questi campi, facendo clic su Deploy il wizard avvierà automaticamente il provisioning dei componenti SDN nel cluster. Inserite i parametri come nella figura sotto:

Figura 26: Configurazione dei parametri del Network Controller prima dell’avvio del deployment dell’infrastruttura SDN

Durante la fase di Deploy dell’infrastruttura SDN, Windows Admin Center richiede nuovamente le credenziali amministrative per eseguire operazioni di configurazione sui nodi del cluster tramite PowerShell remoting. La richiesta compare perché il deployment richiede una connessione “double hop”, cioè l’accesso a un sistema remoto che a sua volta deve eseguire operazioni su altri host o risorse di rete.

In pratica:

• Windows Admin Center si connette al cluster.
• Il cluster deve eseguire comandi PowerShell sugli host o su altre risorse.
• Per motivi di sicurezza, le credenziali non vengono inoltrate automaticamente.
• Viene quindi richiesto di inserirle di nuovo per autorizzare queste operazioni remote.

Figura 27: Richiesta delle credenziali per la connessione PowerShell “double hop” necessaria al deployment dei componenti SDN sui nodi del cluster

Il deployment durerà circa 10 minuti.

Durante il deployment dell’infrastruttura SDN è possibile monitorare l’avanzamento collegandosi in PowerShell remota a uno degli host del cluster, in questo caso SDNHOST1. Dopo aver aperto una sessione remota con Enter-PSSession sdnhost1, si accede alla cartella Documents dell’host dove vengono salvati i file di log generati dagli script SDN Express. Con il comando Get-Content <LogFileName> -Wait si segue in tempo reale il contenuto del log, verificando le operazioni eseguite e l’eventuale presenza di errori.

Figura 28: Monitoraggio del deployment SDN tramite sessione PowerShell remota e visualizzazione in tempo reale dei file di log su SDNHOST1

Figura 29: Log in tempo reale chemostra il deployment della configurazione SDN

Al termine del processo, tutte le operazioni risultano nello stato Complete, segno che il deployment dell’infrastruttura SDN è andato a buon fine. In questa fase il Network Controller è stato creato, gli host sono stati configurati e gli strumenti di gestione sono stati installati automaticamente.

Fate clic su Finish per chiudere la procedura guidata e tornare alla gestione del cluster. Da questo momento l’infrastruttura SDN è operativa e pronta per la creazione delle reti virtuali e delle altre componenti di test del laboratorio.

Figura 30: Completamento del deployment SDN

Dopo qualche secondo, Windows Admin Center rileverà automaticamente l’infrastruttura SDN appena distribuita e mostrerà il messaggio di conferma. Questo indica che il Network Controller è attivo e che l’integrazione con il cluster è andata a buon fine.

Nota sulla modalità Service Fabric

Nel laboratorio che ho realizzato ho preferito utilizzare la modalità Service Fabric invece della modalità Native SDN. Durante i test, infatti, il deployment con l’opzione nativa generava alcuni errori che non mi permettevano di completare correttamente la configurazione dell’infrastruttura.

Per utilizzare la modalità basata su Service Fabric è stato sufficiente modificare il file di configurazione della sandbox SDNSandbox-Config.psd1 impostando il parametro ProvisionLegacyNC = $True

Con questa opzione viene distribuito il Network Controller nella modalità tradizionale, basata su macchine virtuali gestite tramite Service Fabric, invece della nuova implementazione nativa introdotta nelle versioni più recenti di Windows Server.

Questa scelta non influisce sugli scenari di laboratorio mostrati nell’articolo, ma consente di ottenere un ambiente funzionante anche in presenza di problemi con il deployment Native SDN. In ambienti di produzione o in nuovi test, resta comunque consigliato l’utilizzo della modalità nativa quando supportata correttamente dall’infrastruttura.

Verifica dell’infrastruttura SDN in modalità Service Fabric

Dopo il completamento del deployment e l’accesso alla sezione SDN Infrastructure di Windows Admin Center, inizia la fase di verifica delle risorse create automaticamente dallo script in modalità Service Fabric, controllando lo stato dei componenti principali come Network Controller, gateway, load balancer e virtual network.

Da Windows Admin Center, nel nodo SDN Infrastructure, fate clic su Continue per accedere alla gestione dell’infrastruttura SDN.

Figura 31: Rilevamento automatico dell’infrastruttura SDN

Al termine della procedura, verrà visualizzato il pannello di riepilogo dell’infrastruttura SDN. Questa schermata mostra lo stato dei principali componenti, come Network Controller, load balancer, gateway e pool di indirizzi virtuali. Da qui è possibile monitorare la salute dell’ambiente e accedere alle diverse sezioni per la configurazione delle reti virtuali e dei servizi SDN.

Figura 32: Dashboard dell’infrastruttura SDN

Nella figura sotto potete vedere i dettagli del Network Controller, componente centrale dell’infrastruttura SDN. Vengono mostrati lo stato del servizio, la versione installata, l’endpoint REST e i certificati utilizzati per la comunicazione e la cifratura delle credenziali.

Nella parte inferiore è visibile l’elenco dei servizi che compongono il controller, tutti nello stato Ready, segno che il controller è operativo. A destra viene invece indicato lo stato del nodo che ospita il controller, con configurazione completata con esito Success.

Figura 33: Scheda Network Controller

Dalla apposita scheda potete vedete il riepilogo del Software Load Balancer integrato in SDN. Il servizio è già stato creato durante il provisioning dell’infrastruttura e risulta in stato Succeded, quindi operativo. Viene mostrato l’indirizzo IP del Load Balancer Manager, utilizzato dal Network Controller per programmare le regole di bilanciamento, insieme alle informazioni sui pool di indirizzi pubblici e privati disponibili.

Figura 34: Scheda Load Balancer

Dalla scheda Gateway potete configurare i gateway dell’infrastruttura SDN, utilizzati per collegare le reti virtuali dell’ambiente con reti esterne, locali o remote.

Il gateway rappresenta il punto di uscita e di ingresso tra le reti virtuali dei tenant e le reti esterne, come la rete fisica o altre sedi remote.

Nella vista vengono riportate le principali metriche operative della macchina gateway, tra cui utilizzo di CPU, memoria e storage, stato della rete e uptime della VM. A destra sono visibili le informazioni logiche del pool di gateway, lo stato di ridondanza, il heartbeat e la capacità disponibile.

Questa sezione consente quindi di verificare rapidamente la salute e la disponibilità del servizio di routing tra la rete virtuale SDN e le reti esterne.

Figura 35: Scheda Gateway

La Scheda Data Path Diagnostics consente di eseguire analisi e troubleshooting del traffico all’interno dell’infrastruttura SDN. Lo strumento automatizza le catture di pacchetti nei vari punti del percorso di rete e presenta i risultati in un’unica vista, facilitando l’individuazione di problemi di connettività o di configurazione.

Per abilitare la decodifica dei pacchetti è necessario installare il componente WSDissect tramite il pulsante Install WSDissect, che aggiunge le funzionalità di parsing e analisi del traffico. Una volta installato, sarà possibile avviare le sessioni di diagnostica direttamente da questa sezione.

Figura 36: Scheda Data Path Diagnostics

Dopo l’installazione di WSDissect, la scheda Data Path Diagnostics consente di scegliere lo scenario di troubleshooting da analizzare. In questa sezione sono disponibili diversi scenari infrastrutturali predefiniti, che permettono di verificare la comunicazione tra i componenti principali dell’SDN, come Network Controller, host, multiplexer e gateway.

Selezionando uno scenario, Windows Admin Center avvierà automaticamente le catture di traffico nei punti rilevanti del data path, raccogliendo e presentando i risultati in modo centralizzato per facilitare l’analisi e l’individuazione di eventuali problemi di rete.

Figura 37: Selezione degli scenari di diagnostica

Creazione di macchine virtuali tenant su rete virtuale SDN

Nel primo esempio pratico che vi propongo utilizzeremo gli script presenti nella cartella 01_Create_TenantVMs per simulare uno scenario multi-tenant tipico di un’infrastruttura SDN.

L’obiettivo del laboratorio è creare una o più macchine virtuali collegate a una rete virtuale gestita dal Network Controller, in modo da verificare il funzionamento dell’overlay network e delle funzionalità di isolamento.

Questo scenario rappresenta il caso d’uso più comune: la creazione di workload tenant isolati su una rete logica SDN, senza la necessità di configurare manualmente VLAN o regole di rete sugli host.

Gli script inclusi nella cartella eseguono automaticamente le operazioni principali:

• creazione di una rete virtuale (Virtual Network) nel Network Controller
• definizione di una subnet logica per il tenant
• provisioning di una o più macchine virtuali connesse alla rete SDN
• assegnazione degli indirizzi IP e delle impostazioni di rete

In pratica, questo esempio mostra come SDN consenta di distribuire rapidamente workload isolati tra loro, replicando un modello simile a quello utilizzato nei cloud pubblici, ma all’interno del proprio datacenter.

Il collegamento sul desktop della macchina di gestione punta direttamente alla cartella C:\SDNEXAMPLES\01_Create_TenantVMs

Figura 38: Cartella con gli script che è possibile utilizzare per simulare diversi scenari

Da qui è possibile eseguire gli script e osservare in tempo reale, tramite Windows Admin Center, la creazione delle risorse SDN e delle macchine virtuali tenant.

Questo primo scenario è ideale per prendere confidenza con il funzionamento della rete virtuale e verificare che l’infrastruttura SDN appena distribuita sia operativa.

Alla pagina https://github.com/billcurtis/SDN-Sandbox/tree/master/SDNSandbox/Applications/SDNEXAMPLES/01_Create_TenantVMs, trovate il dettaglio dello svolgimento del laboratorio e anche le immagini esplicative dei diversi passaggi.

Figura 39: Esecuzione dello script di creazione delle macchine virtuali del tenant

Al termine dell’esecuzione dello script, le macchine virtuali del laboratorio (TenantVM1 e TenantVM2) risultano create e avviate automaticamente. Nella sezione Virtual machines di Windows Admin Center è possibile verificarne la presenza e lo stato operativo.

Figura 40: Inventario delle macchine virtuali dopo l’esecuzione dello script

Figura 41: Overview delle configurazioni della macchina virtuale TenantVM1

La scheda di rete di TenantVM1 è collegata allo switch virtuale SDN, con isolamento in modalità Virtual network, associata alla virtual network TenantNetwork1 e alla subnet TenantSubnet1 (10.0.1.0/24), con indirizzo IP assegnato 10.0.1.4.

Figura 42: Configurazione di rete della VM del tenant

Collegandovi alla console di TenantVM1 potete aprire un prompt dei comandi o un browser (su entrambe le VM è stato attivato il ruolo di web server dallo script) e verificare la connettività verso l’altra macchina del tenant, ad esempio eseguendo un ping verso l’indirizzo IP assegnato a TenantVM2. Questo passaggio consente di confermare che entrambe le macchine sono correttamente collegate alla stessa virtual network e possono comunicare tra loro tramite l’infrastruttura SDN.

Figura 43: Verifica della connettività tra le due Tenant VM all’interno della virtual network

Nota sul servizio iDNS

Nello stato attuale del laboratorio, TenantVM1 e TenantVM2 possono comunicare tra loro solo utilizzando gli indirizzi IP, perché all’interno della virtual network non è ancora stato configurato un servizio di risoluzione dei nomi.

Questo significa che:

• non è possibile raggiungere le VM tramite nome host
• non esiste ancora un DNS interno alla rete del tenant
• tutte le comunicazioni devono avvenire tramite indirizzi IP statici

Per abilitare la risoluzione dei nomi all’interno della virtual network è necessario distribuire il servizio iDNS (Internal DNS) dell’infrastruttura SDN.
Una volta attivo, le macchine virtuali del tenant potranno registrarsi automaticamente nel DNS e comunicare tra loro anche tramite nome, non solo tramite indirizzo IP.

Configurazione di iDNS e registrazione dei record

Per abilitare la risoluzione dei nomi nel laboratorio ho utilizzato lo script:

C:\SDNEXAMPLES\03_Software_Load_Balancers_NAT\03.05_Deploy_iDNS.ps1

Lo script configura il servizio iDNS nel Network Controller e prepara l’infrastruttura per la registrazione automatica dei record DNS delle macchine virtuali dei tenant. Durante l’esecuzione viene creata la zona principale tenantsdn.local sul domain controller, che rappresenta la zona DNS dedicata alle virtual network dell’ambiente SDN.

A partire da questa zona principale, il sistema crea automaticamente anche le sottozone associate alle singole virtual network. In questo modo ogni VNet dispone del proprio spazio dei nomi, mantenendo l’isolamento tra tenant e una struttura DNS ordinata e scalabile.

È importante notare che la registrazione degli indirizzi IP nel DNS non avviene in modo continuo, ma viene eseguita in momenti specifici. In particolare, il record viene creato o aggiornato:

• quando la macchina virtuale viene creata tramite gli script SDN,
• oppure quando l’indirizzo IP della scheda di rete viene modificato manualmente.

Nel laboratorio, ad esempio, ho modificato l’indirizzo della TenantVM1 da 10.0.1.4 a 10.0.1.6 dalle proprietà della VM e solo in quel momento è stato aggiornato il relativo record DNS. Questo comportamento è normale, perché la registrazione viene gestita dal Network Controller in base agli eventi di provisioning o modifica della configurazione di rete.

Nella figura sotto è visibile l’output del comando ipconfig eseguito all’interno della TenantVM1. Si può notare che la macchina ha ricevuto correttamente le informazioni di rete dalla virtual network SDN.

La presenza del suffisso TenantNetwork1.tenantsdn.local indica che la macchina è stata registrata correttamente nella sottozona DNS associata alla virtual network. Questo conferma che il servizio iDNS è attivo e che la risoluzione dei nomi all’interno della VNet può avvenire tramite il namespace dedicato al tenant.

In pratica, ogni virtual network riceve una propria sottozona sotto tenantsdn.local, e le macchine collegate a quella rete vengono registrate automaticamente con il relativo suffisso DNS. Questo meccanismo consente l’isolamento tra tenant e una gestione centralizzata dei record DNS da parte del Network Controller.

Figura 44: Verifica della configurazione DNS sulla macchina virtuale

Nella figura sotto è visibile la console DNS Manager sul server DC1, dove è possibile controllare il funzionamento del servizio iDNS configurato in precedenza.

All’interno della zona tenantsdn.local è stata creata automaticamente la sottozona TenantNetwork1, che corrisponde alla virtual network del tenant. In questa sottozona è presente il record TenantVM1, associato all’indirizzo IP 10.0.1.6.

Figura 45: Verifica della registrazione DNS nella zona iDNS

Connettività Internet delle VM tenant: Outbound NAT e VIP

Al momento le macchine virtuali dei tenant non hanno accesso a Internet. Possono comunicare tra loro all’interno della virtual network grazie all’overlay SDN, ma senza una configurazione specifica non esiste alcun percorso verso l’esterno. In un’infrastruttura SDN, infatti, la navigazione non è “automatica”: dovete creare voi il punto di uscita, decidendo se farlo tramite NAT in uscita oppure assegnando direttamente un indirizzo pubblico alla VM.

Nel mio laboratorio ho utilizzato lo script, opportunamente modificato per lavorare sulla rete TenantNetwork1, presente in:

C:\SDNEXAMPLES\03_Software_Load_Balancers_NAT\03.06_Create_SLB_for_Outbound_NAT.ps1

Questo script configura sul Software Load Balancer (SLB) una regola di Outbound NAT per la subnet del tenant. In pratica le VM continuano a usare il loro indirizzo privato (ad esempio 10.0.1.x), ma quando escono verso Internet il traffico viene tradotto (SNAT) su un indirizzo del pool pubblico configurato nell’infrastruttura SDN. È la modalità più comoda quando avete più VM e volete dare loro connettività in uscita senza esporle direttamente: dall’esterno non sono raggiungibili, ma possono aggiornarsi, scaricare pacchetti e navigare.

Dopo l’esecuzione dello script, se la VM non naviga, le cause più comuni sono sempre le stesse: o manca un vero percorso dall’infrastruttura verso l’esterno (routing/gateway upstream), oppure la VM non sta usando un DNS valido per risolvere i nomi Internet. In questi casi il NAT può essere configurato correttamente, ma la navigazione non funziona perché la risoluzione DNS fallisce o perché l’IP “pubblico” non è instradabile fuori dal laboratorio.

VIP e port forwarding

In alternativa, se volete assegnare alla VM un indirizzo “pubblico” direttamente sulla scheda di rete (quindi renderla raggiungibile anche dall’esterno, in base alle policy), potete usare lo script:

C:\SDNEXAMPLES\03_Software_Load_Balancers_NAT\03.07_Create_Forwarding_VIP.ps1

Qui il concetto è diverso rispetto all’Outbound NAT: non si tratta più di dare solo uscita Internet, ma di pubblicare la VM tramite un VIP (Virtual IP). Lo script crea un VIP e una regola di port forwarding che mappa il traffico in ingresso su quell’IP verso l’IP privato della VM (ad esempio 10.0.1.6). Dal punto di vista pratico è come dire: “questo indirizzo pubblico termina sul load balancer, ma inoltra il traffico a questa specifica VM”. In questo modo potete esporre un servizio (RDP, HTTP/HTTPS, ecc.) senza assegnare realmente un indirizzo pubblico dentro il sistema operativo della VM, ma ottenendo lo stesso risultato operativo: un IP pubblico da utilizzare per raggiungerla.

In sintesi, i due script risolvono due esigenze diverse: lo script 03.06 vi serve quando volete far uscire le VM su Internet mantenendole private, lo script 03.07 quando invece vi serve un “IP pubblico” (VIP) per pubblicare una VM o un servizio verso l’esterno tramite regole di forwarding gestite dall’SLB.

Figura 46: Verifica della connettività Internet dalla TenantVM1 dopo la configurazione dell’Outbound NAT

Analisi dei Provider Address e instradamento del traffico tra host SDN

Adesso analizziamo l’host SDNHOST1 e verifichiamo gli indirizzi Provider configurati. I Provider Address (PA) sono gli indirizzi utilizzati dagli host Hyper-V per instradare il traffico tra loro all’interno della rete fisica del fabric.

Nello scenario appena configurato avete eseguito un ping tra le due macchine del tenant:

• TenantVM1: 10.0.1.4
• TenantVM2: 10.0.1.5

Entrambe appartengono alla subnet 10.0.1.0/24 della virtual network TenantNetwork1, che è una rete isolata e sovrapposta (overlay). Inoltre, le due VM risiedono su host fisici diversi del cluster.

A questo punto nasce la domanda: se la rete 10.0.1.0/24 esiste solo come virtual network e le VM si trovano su host differenti, come viene instradato il traffico tra 10.0.1.4 e 10.0.1.5?

La risposta è nel meccanismo di mappatura CA-PA implementato dall’SDN:

• CA (Customer Address): è l’indirizzo della VM nella virtual network, ad esempio 10.0.1.4 o 10.0.1.5.
• PA (Provider Address): è l’indirizzo dell’host fisico nella rete di trasporto, ad esempio 172.16.0.x.

Quando TenantVM1 (10.0.1.4) invia traffico verso TenantVM2 (10.0.1.5):

1. L’host che esegue TenantVM1 intercetta il traffico destinato alla virtual network.
2. Tramite la tabella di mappatura CA-PA, scopre su quale host si trova la VM di destinazione.
3. Il pacchetto viene incapsulato e inviato all’indirizzo Provider (PA) dell’host di destinazione.
4. L’host ricevente decapsula il traffico e lo consegna alla VM corretta.

In questo modo:

• le VM comunicano tra loro usando gli indirizzi 10.0.1.x;
• il traffico viaggia realmente sulla rete fisica usando gli indirizzi 172.16.0.x degli host.

Figura 47: Instradamento del traffico tra TenantVM1 e TenantVM2 tramite mappatura CA-PA e tunnel overlay

La cmdlet Get-ProviderAddress mostra gli indirizzi Provider (PA) assegnati all’host all’interno della rete fisica. Get-PACAMapping visualizza la mappatura tra gli indirizzi Customer (CA) delle VM e gli indirizzi Provider (PA) degli host.

Figura 48: Verifica degli indirizzi Provider e delle mappature PA-CA tramite PowerShell sull’host SDN

Per chi desidera approfondire ulteriormente l’argomento, consiglio di dare un’occhiata al seguente video, in cui vengono mostrate altre funzionalità e scenari della Software Defined Networking su Windows Server:

Nel video troverete una panoramica più ampia dell’architettura SDN, con ulteriori esempi pratici e spiegazioni sui componenti principali della soluzione. È un buon punto di partenza per continuare l’esplorazione dopo aver completato questo laboratorio.

Conclusioni

In questo articolo non avevo l’obiettivo di essere esaustivo né di coprire tutte le funzionalità della Software Defined Networking in Windows Server 2025. L’intento era piuttosto quello di fornire un primo approccio pratico, mostrando come avviare l’ambiente, creare le prime virtual network e comprendere i meccanismi di base che permettono la comunicazione tra le macchine dei tenant.

Questo laboratorio rappresenta solo il punto di partenza. L’infrastruttura SDN di Windows Server 2025 include molte altre funzionalità avanzate, tra cui gateway multi-tenant, load balancing interno ed esterno, micro-segmentazione tramite Network Security Groups e integrazione con scenari ibridi.

Il consiglio è di continuare a sperimentare con gli script del sandbox, analizzare le configurazioni create dal Network Controller e modificare gli scenari per comprendere meglio il comportamento della rete software-defined. È proprio attraverso queste prove pratiche che si acquisisce familiarità con i concetti e con gli strumenti messi a disposizione dalla piattaforma.