Introduction to Software-Defined Networking on Windows Server 2022

Software-Defined Networking (SDN) on Windows Server 2022 is a Microsoft implementation of a full-stack network virtualisation solution that decouples the network control plane from the data plane, allowing centralised programmatic management of the entire network fabric. Rather than configuring individual switches, routers, and firewalls device by device, SDN on Windows Server provides a single management plane — the Network Controller — that orchestrates all network functions across a cluster of Hyper-V hosts and software network appliances.

The Windows Server SDN stack is designed for large-scale multi-tenant datacentre deployments, private cloud scenarios, and environments using Azure Stack HCI. It is the same technology stack used internally by Microsoft Azure. This guide covers the key components, infrastructure requirements, and deployment process for Windows Server 2022 SDN.

SDN Components Overview

Windows Server SDN consists of four primary components that work together to deliver virtualised networking services.

Network Controller (NC) is the centralised management and orchestration component. It is a highly available server application deployed across a cluster of at least three nodes. The Network Controller exposes a RESTful Northbound API that is used by management tools (Windows Admin Center, SCVMM, PowerShell) to configure the entire SDN fabric. It communicates with Hyper-V hosts via a Southbound interface using the Open vSwitch Database (OVSDB) protocol. The NC stores all SDN configuration in its own distributed database and pushes policy to all hosts.

Software Load Balancer (SLB) provides Layer 4 (TCP/UDP) load balancing for both north-south traffic (between external clients and internal VMs) and east-west traffic (between VMs within the data centre). SLB uses a multiplexer (MUX) component deployed as a VM to handle Virtual IP (VIP) to Dynamic IP (DIP) translation. SLB supports Direct Server Return (DSR) for scalable high-throughput scenarios.

RAS Gateway provides Layer 3 connectivity between the virtual networks and the physical underlay network or remote locations. It supports IPsec site-to-site VPN, GRE tunnels, and BGP routing. RAS Gateway enables tenants in a virtualised multi-tenant environment to connect their virtual networks to their on-premises networks or to the Internet.

SDN Firewall (Distributed Firewall) implements access control lists (ACLs) at each VM vNIC in a distributed fashion. Unlike traditional firewalls where traffic is hairpinned to a centralised appliance, the SDN firewall enforces policies at the hypervisor level on each host, providing micro-segmentation with no performance bottleneck.

SDN Infrastructure Requirements

Deploying SDN on Windows Server 2022 requires a carefully planned infrastructure. The minimum requirements are as follows.

The compute fabric must consist of Hyper-V hosts running Windows Server 2022. For high availability, a minimum of three hosts is required for the Network Controller cluster. The physical network must support VLAN trunking to carry management, provider, and tenant VLANs. RDMA (iWARP or RoCE) is strongly recommended for Storage Spaces Direct (S2D) traffic that underpins the SDN VM storage.

Two logical networks are required: the Management Network (for communication between NC, hosts, and management tools) and the Provider Address (PA) Network (for encapsulated tenant traffic using VXLAN or NVGRE). The PA network must be routable across all hosts participating in the SDN fabric.

DNS must be configured so all SDN components can resolve each other by name. Active Directory is required for NC cluster formation. A PKI infrastructure (or at minimum self-signed certificates managed by the NC) is required for secure communication between NC and hosts.

Deploying SDN with SDN Express

Microsoft provides the SDN Express deployment framework, a set of PowerShell scripts that automate the deployment of the entire SDN stack. The scripts are available on GitHub in the Microsoft SDN repository. Clone or download the SDNExpress folder to a management machine.

The deployment is driven by a configuration file (typically MultiNodeSampleConfig.psd1). Edit this file to match your environment:

@{
    ScriptVersion    = "2.0"
    VHDPath          = "\fileservervhds"
    VHDFile          = "ws2022datacenter.vhdx"
    VMLocation       = "C:ClusterStorageVolume1"
    JoinDomain       = "corp.example.com"
    SDNMacPoolStart  = "AA-BB-CC-DD-EE-00"
    SDNMacPoolEnd    = "AA-BB-CC-DD-EE-FF"
    ManagementSubnet = "10.0.0.0/24"
    ManagementGateway= "10.0.0.1"
    ManagementDNS    = @("10.0.0.5")
    ManagementVLANID = 10
    DomainJoinUsername = "CORPAdministrator"
    DomainJoinPassword = "YourPassword"
    LocalAdminPassword = "LocalAdminPass"
    NCNodes = @(
        @{ComputerName="NC01"; IPAddress="10.0.0.11"},
        @{ComputerName="NC02"; IPAddress="10.0.0.12"},
        @{ComputerName="NC03"; IPAddress="10.0.0.13"}
    )
    HyperVHosts = @(
        @{ComputerName="HV01"; ManagementIP="10.0.0.21"; PAIPAddress="192.168.0.1"; PAVLANID=200},
        @{ComputerName="HV02"; ManagementIP="10.0.0.22"; PAIPAddress="192.168.0.2"; PAVLANID=200},
        @{ComputerName="HV03"; ManagementIP="10.0.0.23"; PAIPAddress="192.168.0.3"; PAVLANID=200}
    )
}

Run the SDN Express deployment script from the management machine:

.SDNExpress.ps1 -ConfigurationDataFile .MultiNodeSampleConfig.psd1 -Verbose

The script will create the NC VMs, install the Network Controller role, deploy SLB MUX VMs, configure all hosts with the SDN host agent (NC host plug-in), and configure BGP peering between RAS Gateway VMs and the physical ToR switches.

Network Controller Cluster Creation (Manual)

If deploying manually without SDN Express, install the Network Controller role on three VMs:

Install-WindowsFeature -Name NetworkController -IncludeManagementTools

Configure the NC node on the first VM:

$nodeList = @()
$nodeList += New-NetworkControllerNodeObject -Name "NC01" -Server "NC01.corp.example.com" -FaultDomain "fd:/rack1/NC01" -RestInterface "Ethernet"
$nodeList += New-NetworkControllerNodeObject -Name "NC02" -Server "NC02.corp.example.com" -FaultDomain "fd:/rack1/NC02" -RestInterface "Ethernet"
$nodeList += New-NetworkControllerNodeObject -Name "NC03" -Server "NC03.corp.example.com" -FaultDomain "fd:/rack2/NC03" -RestInterface "Ethernet"

Install-NetworkControllerCluster -Node $nodeList -ClusterAuthentication Kerberos -ManagementSecurityGroup "CORPNC-Admins" -DiagnosticLogLocation "\fileserverNCLogs"

After the cluster is created, install the Network Controller application:

Install-NetworkController -Node $nodeList -ClientAuthentication Kerberos -ClientSecurityGroup "CORPNC-Clients" -RestIpAddress "10.0.0.100/24" -PassThru

Verify the NC is operational:

Get-NetworkController
Get-NetworkControllerNode

Creating Virtual Networks with HNV/VXLAN/NVGRE

Virtual networks in SDN use either VXLAN (Virtual Extensible LAN) or NVGRE (Network Virtualisation using Generic Routing Encapsulation) for overlay encapsulation. The NC manages the mapping between tenant (Customer Address) space and physical (Provider Address) space. To create a virtual network via the NC REST API using PowerShell:

$uri = "https://10.0.0.100"

# Create a logical network for the physical underlay
$logicalNetwork = New-NetworkControllerLogicalNetwork -ConnectionUri $uri -ResourceId "HNVPA" -Properties @{
    NetworkVirtualizationEnabled = $true
    Subnets = @(
        @{
            ResourceId = "HNVPA_Subnet"
            Properties = @{
                AddressPrefix = "192.168.0.0/24"
                DefaultGateways = @("192.168.0.1")
                VlanID = 200
            }
        }
    )
}

# Create a virtual network for a tenant
$virtualNetwork = New-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId "TenantVNet01" -Properties @{
    AddressSpace = @{
        AddressPrefixes = @("172.16.0.0/16")
    }
    LogicalNetwork = @{ ResourceRef = "/logicalNetworks/HNVPA" }
    Subnets = @(
        @{
            ResourceId = "WebSubnet"
            Properties = @{
                AddressPrefix = "172.16.1.0/24"
            }
        }
    )
}

Software Load Balancer Configuration

The SLB provides both inbound NAT (public VIP to private DIP) and outbound NAT for VM Internet access. To create an SLB load balancing rule that distributes HTTP traffic across a pool of web VMs:

$uri = "https://10.0.0.100"

# Create a load balancer
$lbProps = @{
    FrontendIPConfigurations = @(
        @{
            ResourceId = "FE-WebVIP"
            Properties = @{
                PrivateIPAddress = "10.10.10.100"
                PrivateIPAllocationMethod = "Static"
                Subnet = @{ ResourceRef = "/logicalNetworks/PublicVIP/subnets/VIPSubnet" }
            }
        }
    )
    BackendAddressPools = @(
        @{
            ResourceId = "BE-WebPool"
            Properties = @{}
        }
    )
    LoadBalancingRules = @(
        @{
            ResourceId = "HTTP-Rule"
            Properties = @{
                FrontendIPConfiguration = @{ ResourceRef = "/loadbalancers/WebLB/frontendIPConfigurations/FE-WebVIP" }
                BackendAddressPool = @{ ResourceRef = "/loadbalancers/WebLB/backendAddressPools/BE-WebPool" }
                Protocol = "TCP"
                FrontendPort = 80
                BackendPort = 80
                EnableFloatingIP = $false
            }
        }
    )
}

New-NetworkControllerLoadBalancer -ConnectionUri $uri -ResourceId "WebLB" -Properties $lbProps

SDN Firewall (Distributed Firewall) Policies

The SDN Distributed Firewall enforces ACLs at each VM network interface at the hypervisor level. Policies are applied via Network Controller ACL resources and assigned to VM network interfaces or subnets. Create a firewall ACL:

$uri = "https://10.0.0.100"

$aclRules = @(
    @{
        ResourceId = "Allow-HTTP"
        Properties = @{
            Protocol = "TCP"
            DestinationPortRange = "80"
            SourceAddressPrefix = "*"
            DestinationAddressPrefix = "*"
            Action = "Allow"
            Priority = 100
            Direction = "Inbound"
            Type = "Stateful"
            Logging = "Enabled"
        }
    },
    @{
        ResourceId = "Allow-HTTPS"
        Properties = @{
            Protocol = "TCP"
            DestinationPortRange = "443"
            SourceAddressPrefix = "*"
            DestinationAddressPrefix = "*"
            Action = "Allow"
            Priority = 110
            Direction = "Inbound"
            Type = "Stateful"
            Logging = "Enabled"
        }
    },
    @{
        ResourceId = "Deny-All-Inbound"
        Properties = @{
            Protocol = "*"
            DestinationPortRange = "*"
            SourceAddressPrefix = "*"
            DestinationAddressPrefix = "*"
            Action = "Deny"
            Priority = 65000
            Direction = "Inbound"
            Type = "Stateless"
            Logging = "Enabled"
        }
    }
)

New-NetworkControllerAccessControlList -ConnectionUri $uri -ResourceId "WebTier-ACL" -Properties @{ AclRules = $aclRules }

Assign the ACL to a VM network interface via the NC API by referencing the ACL ResourceRef in the network interface properties.

Managing SDN with Windows Admin Center

Windows Admin Center (WAC) version 2103 and later includes native SDN management capabilities when connected to a Network Controller. To use WAC for SDN management, add the NC REST endpoint as a connection in WAC and install the SDN gateway extension if prompted.

From WAC, you can visually manage virtual networks, create load balancers, configure firewall ACLs, and monitor the health of all SDN components. The SDN dashboard in WAC shows the status of the NC cluster, all registered Hyper-V hosts, SLB MUX instances, and RAS Gateway VMs in a single view.

To verify NC health from PowerShell:

$uri = "https://10.0.0.100"
Get-NetworkControllerServerResource -ConnectionUri $uri | Select-Object ResourceId, Properties
Get-NetworkControllerCredential -ConnectionUri $uri

SDN vs Traditional Networking

The primary distinction between SDN and traditional networking is the separation of the control plane from the data plane. In traditional networking, each switch or router makes its own forwarding decisions based on locally configured routing tables and protocols. Configuration requires logging into each device individually. Changes propagate slowly and are error-prone at scale.

In SDN, the Network Controller holds the global network view and pushes forwarding and policy decisions to all hosts simultaneously via the Southbound API. A single PowerShell command or WAC action can instantaneously apply a firewall policy across thousands of VM interfaces. This centralised model enables automation at cloud scale, consistent policy enforcement, and dramatically faster change management.

SDN is best suited for environments with more than 20-30 Hyper-V hosts, multi-tenant requirements, or where the network policy complexity justifies the deployment overhead. For smaller environments, traditional Hyper-V virtual switching with manual VLAN configuration remains simpler to operate.