SET vs. Traditional NIC Teaming

Switch Embedded Teaming (SET) is a software-defined NIC teaming feature introduced in Windows Server 2016 as an alternative to traditional NIC Teaming (often called LBFO for Load Balancing/Failover). Unlike legacy NIC teaming which operates at the OS level and then binds a Hyper-V switch on top, SET integrates the NIC teaming functionality directly into the Hyper-V virtual switch. This means you can combine multiple physical NICs (up to 8 identical adapters) into one logical virtual switch interface natively in Hyper-V. The physical network switches are unaware of the SET team – all uplinks run in a switch-independent mode, and Hyper-V itself handles load balancing of traffic with algorithms like Hyper-V Port or Dynamic mode. In essence, SET collapses what used to be two steps (creating an OS-level team, then attaching a vSwitch) into a single integrated virtual switch construct.

How SET Differs from NIC Teaming (LBFO): Traditional NIC teaming (LBFO) in Windows Server allowed various teaming modes (switch-independent, static, or LACP teaming) and could be used broadly for any server workload. However, LBFO teaming for a Hyper-V switch has been deprecated and is not supported in modern Hyper-V/SDN scenarios. Unlike LBFO, which required creating a “team NIC” (tNIC) that the vSwitch would bind to, SET is created as part of the Hyper-V vSwitch itself. This tight integration offers better support for virtualization-specific features (like VMQ, vRSS, and SR-IOV) and eliminates the extra layer of an LBFO team adapter. Moreover, SET requires all member NICs to be of the same make/model and similar configuration (symmetric) for consistency, and it only supports switch-independent mode with Hyper-V Port or Dynamic load-balancing (no LACP/802.3ad option). In summary, SET is purpose-built for Hyper-V, whereas LBFO was a general Windows teaming that has now been surpassed in performance and compatibility by SET.

 

When and Why to Use SET in Hyper-V Environments

Modern Hyper-V Deployments: In any modern Hyper-V environment on Windows Server (2016 and later, including Windows Server 2025), Microsoft strongly recommends using SET for NIC redundancy and aggregation. With Windows Server 2025, using the older LBFO teams for a Hyper-V switch is no longer viable – attempts to attach a vSwitch to an LBFO team will fail with a message that an LBFO team cannot be attached and to use SET instead.

Converged Fabrics and Fewer NICs: One key scenario for SET is converged networking on Hyper-V hosts or clusters. SET allows the same physical NIC team to carry multiple types of traffic (VM networking, storage (SMB Direct), management, etc.) through the Hyper-V virtual switch, using vNICs and QoS to separate flows. This drastically reduces the number of NICs required in each host. For example, in Azure Stack HCI (now called Azure Local for on-premises Azure services), a host must handle management, compute, and storage traffic; SET enables all these to run over a single team instead of dedicated NICs per purpose. By using one SET (say a team of 2×25 GbE NICs) rather than separate pairs of NICs for each function, administrators achieve the needed isolation and performance while simplifying the hardware footprint.

Failover Clustering and SDN: In Hyper-V failover clusters and Software-Defined Networking deployments, SET is not just recommended but often required. Traditional LBFO teaming is not supported with SDN because it lacks awareness of virtualized networks and can’t handle the new capabilities. SET, on the other hand, was built to work with the SDN stack – it allows the same NICs to handle host RDMA traffic (for Storage Spaces Direct or live migration) and virtual network traffic simultaneously, something impossible with LBFO in the past. In summary, you should use SET whenever you are running Hyper-V with multiple physical NICs and especially if you plan to leverage advanced features (RDMA, SDN, Network Virtualization, Azure Local) or simply want a cleaner, more integrated networking setup on your hosts.

 

Key Architectural Benefits of SET

SET was designed with modern datacenter needs in mind, and it provides several important benefits over older teaming methods:

  • Performance and Hardware Offloads: SET improves performance by enabling advanced networking offloads and acceleration features in a virtualized context. Because the teaming is integrated in the Hyper-V switch, features like Virtual Machine Multi-Queue (VMMQ) and virtual RSS can distribute VM traffic efficiently across host CPUs. Additionally, SET supports RDMA (Remote Direct Memory Access) on teamed adapters, allowing you to converge high-speed storage traffic (SMB Direct) with VM traffic without sacrificing RDMA’s low latency.
  • Fault Tolerance and Resiliency: Like any NIC teaming, SET provides NIC-level fault tolerance. If one physical NIC in the team fails or is disconnected, the Hyper-V virtual switch remains up on the remaining NIC(s) without interrupting the VMs’ connectivity.
  • Simplified Management and Fewer Layers: SET reduces complexity by removing one networking layer from the host. SET allows you to create one object – a Hyper-V vSwitch with embedded team members – in a single step.
  • Integration with Virtual Networking Features: SET naturally works with Hyper-V extensible switch features and virtual NIC configurations. You can use Hyper-V switch extensions, QoS policies, port ACLs, and virtualization-based security features, among others.

 

Integration with SDN and Azure Local (Azure Stack HCI)

SET is a cornerstone for Microsoft’s Software Defined Networking and the Azure Stack HCI (now Azure Local) architecture. In Azure Local – which is essentially an on-premises Hyper-V based cloud – SET is the only supported teaming technology.

  • Software Defined Networking (SDN): In SDN deployments, the host’s physical NICs may carry encapsulated traffic (VXLAN/GRE for virtual networks) and handle virtual network functions. Traditional teaming through LBFO is not supported with SDN. Instead, SET is used because it allows the SDN stack to fully utilize the NICs.
  • Azure Local / Azure Stack HCI Integration: Azure Local relies on SET to achieve a converged network architecture on hyper-converged hosts. In Azure Local, each host typically has a small number of high-speed NICs. SET enables those NICs to be teamed to handle VM (compute) traffic, storage replication traffic (SMB3 over RDMA), and management traffic all together.

 

When SET May Not Be the Best Choice (and Alternatives)

  • Non-Hyper-V Workloads: If a server is not running Hyper-V and you simply need to team NICs for a standalone workload, traditional NIC Teaming (LBFO) may still be used.
  • Requirement for Switch-Dependent Teaming (LACP): SET only supports switch-independent mode. If LACP is mandatory for your design, LBFO might be required – but you cannot attach an LBFO team to a Hyper-V switch.
  • Heterogeneous or High-Count NIC Teams: SET requires homogeneous NICs and supports up to 8 adapters. LBFO might support larger or more diverse team configurations.
  • Legacy Systems and Compatibility: SET is only available when the Hyper-V role is installed. Legacy environments may still use LBFO for compatibility.
  • Alternatives in Guest or Higher Layers: In certain cases, network redundancy can be implemented at the VM level or through application-aware methods.

 

Configuration and Management Examples Using PowerShell

  • Creating a New SET Switch:
    New-VMSwitch -Name "SETvSwitch" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true
    
  • Adding or Removing NICs in a SET:

    Add-VMSwitchTeamMember -VMSwitchName "SETvSwitch" -NetAdapterName "NIC3"
    Remove-VMSwitchTeamMember -VMSwitchName "SETvSwitch" -NetAdapterName "NIC1"
    
  • Configuring Load Balancing Algorithm:

    Get-VMSwitchTeam -Name "SETvSwitch" | Select-Object LoadBalancingAlgorithm, TeamingMode
    Set-VMSwitchTeam -Name "SETvSwitch" -LoadBalancingAlgorithm HyperVPort
    
  • Example: Converged SET with Host vNICs:

    Add-VMNetworkAdapter -SwitchName "SETvSwitch" -Name "Storage-vNIC" -ManagementOS
    Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "Storage-vNIC" -Access -VlanId 40
    Set-VMNetworkAdapter -ManagementOS -Name "Storage-vNIC" -PercentageBandwidthWeight 50
    

 

Switch Embedded Teaming is a critical feature for modern Hyper-V deployments on Windows Server 2025, bringing together the benefits of NIC teaming with the intelligence of the Hyper-V virtual switch. By using SET, datacenter professionals can achieve high performance, robust fault tolerance, and simplified network architectures. SET’s tight integration with Windows Server SDN and Azure Local makes it a foundational element of cloud-ready infrastructure design. While there are niche cases where traditional NIC teaming or other approaches might be used, SET is the strategic direction for host networking in Hyper-V.

 

Hope this helps!
É