How to Configure Teaming Network Adapters on Windows Server 2025
A single physical network adapter is a single point of failure. If that adapter, its cable, or the switch port it connects to fails, the server loses network connectivity — potentially bringing down hosted services, virtual machines, or database connections. Network adapter teaming solves this by bonding two or more physical adapters into a single logical interface that provides both redundancy and, depending on the algorithm chosen, additional aggregate bandwidth. Windows Server 2025 supports two distinct teaming technologies: Load Balancing and Failover (LBFO), which is the traditional software-based teaming available since Windows Server 2012, and Switch Embedded Teaming (SET), which is the recommended approach for Hyper-V hosts. This tutorial covers LBFO teaming in depth — modes, algorithms, VLAN interfaces — along with an overview of SET and guidance on choosing between them.
Prerequisites
- Windows Server 2025 (Server Core or Desktop Experience)
- Two or more physical network adapters — ideally identical models from the same vendor for consistent behaviour
- A managed switch with LACP support if you plan to use LACP (802.3ad) mode
- PowerShell running as Administrator
- The
NetLbfomodule (built into Windows Server 2025)
Step 1: Identify Available Network Adapters
Before creating a team, identify the physical adapters you intend to use. Adapters already assigned an IP address can be teamed — the IP will be moved to the team interface automatically — but teaming drops connectivity momentarily during creation, so plan a maintenance window if this is a live server.
# List all physical adapters (exclude virtual and loopback)
Get-NetAdapter -Physical | Select-Object Name, InterfaceDescription, LinkSpeed, Status, MacAddress
# Check for any existing teams
Get-NetLbfoTeam | Format-Table Name, TeamingMode, LoadBalancingAlgorithm, Members
# Verify the NetLbfo module is available
Get-Module -ListAvailable -Name NetLbfo | Select-Object Name, Version
Step 2: Create an LBFO Team
Use New-NetLbfoTeam to create the team. The three key decisions are the team members (physical adapters), the teaming mode, and the load-balancing algorithm. The example below creates a Switch Independent team — the most flexible choice because it requires no switch configuration.
# Create a Switch Independent team with two adapters using Dynamic load balancing
New-NetLbfoTeam `
-Name "LAN-Team" `
-TeamMembers "Ethernet 1","Ethernet 2" `
-TeamingMode SwitchIndependent `
-LoadBalancingAlgorithm Dynamic
# Monitor the team coming online (it takes 5-10 seconds)
Get-NetLbfoTeam -Name "LAN-Team"
# List the team members and their roles
Get-NetLbfoTeamMember -Team "LAN-Team" | Format-Table Name, AdministrativeMode, OperationalMode
Once created, Windows presents a new virtual adapter named LAN-Team. Assign your IP address to this virtual adapter, not to the individual physical adapters. The physical adapters show no IP address in ipconfig — that is expected and correct.
# Assign a static IP to the team interface
New-NetIPAddress `
-InterfaceAlias "LAN-Team" `
-IPAddress "10.10.1.50" `
-PrefixLength 24 `
-DefaultGateway "10.10.1.1"
Set-DnsClientServerAddress -InterfaceAlias "LAN-Team" -ServerAddresses "10.10.1.10","10.10.1.11"
# Verify connectivity
Test-NetConnection -ComputerName 10.10.1.1
Step 3: Understand Teaming Modes
Choose the teaming mode based on your switch capabilities and network design:
- SwitchIndependent: The switch is unaware of the team. Both adapters can connect to different switches — ideal for resilience against switch failure. Only one adapter transmits at a time for a given flow (outbound); both adapters can receive. Works with any switch. No switch configuration required.
- LACP (802.3ad): The switch and server negotiate the team using the Link Aggregation Control Protocol. Both adapters actively pass traffic. Requires a managed switch with LACP enabled on the port channel. Provides true bidirectional bandwidth aggregation from the switch’s perspective.
- Static (IEEE 802.3ad without LACP): Manual aggregation configured on both the switch and server without the LACP negotiation protocol. Used when your switch supports static link aggregation but not LACP. Fragile — misconfiguration causes traffic blackholes with no protocol to detect the error.
# Create an LACP team (switch must have LACP configured on the corresponding ports)
New-NetLbfoTeam `
-Name "LAN-Team-LACP" `
-TeamMembers "Ethernet 3","Ethernet 4" `
-TeamingMode LACP `
-LoadBalancingAlgorithm Dynamic
# Change the teaming mode on an existing team (requires brief connectivity drop)
Set-NetLbfoTeam -Name "LAN-Team" -TeamingMode LACP
Step 4: Understand Load-Balancing Algorithms
The load-balancing algorithm determines how outbound traffic is distributed across team members:
- Dynamic (recommended): Distributes flows across adapters and dynamically rebalances as flows complete. Uses both source/destination ports and IP addresses for the hash. Best overall throughput for mixed workloads.
- HyperVPort: Pins each Hyper-V virtual machine port to one team member. Suitable for Hyper-V hosts using LBFO (not SET). Provides predictable per-VM assignment.
- TransportPorts: Hash based on source and destination TCP/UDP ports. Good for servers with many simultaneous connections (web servers, database servers).
- IPAddresses: Hash based on source and destination IP addresses only. Simple and deterministic — all traffic to the same remote host travels the same adapter. Useful when the remote endpoint count is high.
- MacAddresses: Hash based on MAC addresses. Rarely ideal for server workloads; most useful in specific layer-2 scenarios.
# Change the load-balancing algorithm on an existing team
Set-NetLbfoTeam -Name "LAN-Team" -LoadBalancingAlgorithm TransportPorts
# Confirm current team configuration
Get-NetLbfoTeam -Name "LAN-Team" |
Select-Object Name, TeamingMode, LoadBalancingAlgorithm, BandwidthSettingMbps
Step 5: Create VLAN Interfaces on the Team
A single LBFO team can carry multiple VLANs by creating additional team NIC interfaces, each tagged with a different VLAN ID. This is useful when a server needs connectivity to multiple network segments — for example, a management VLAN and a production data VLAN — without adding more physical adapters.
# Create a team NIC interface for VLAN 10 (Production)
New-NetLbfoTeamNIC `
-Name "LAN-Team-VLAN10" `
-Team "LAN-Team" `
-VlanID 10
# Create a team NIC interface for VLAN 20 (Management)
New-NetLbfoTeamNIC `
-Name "LAN-Team-VLAN20" `
-Team "LAN-Team" `
-VlanID 20
# Assign IP addresses to each VLAN interface
New-NetIPAddress -InterfaceAlias "LAN-Team-VLAN10" -IPAddress "10.10.10.50" -PrefixLength 24
New-NetIPAddress -InterfaceAlias "LAN-Team-VLAN20" -IPAddress "10.20.20.50" -PrefixLength 24
# List all team NIC interfaces
Get-NetLbfoTeamNIC -Team "LAN-Team" | Format-Table Name, VlanID, Primary
Note: the base team interface (no VLAN tag) becomes the untagged or native VLAN. If your switch uses a specific native VLAN, ensure the team’s base interface matches.
Step 6: LBFO vs SET (Switch Embedded Teaming)
Switch Embedded Teaming (SET) is the teaming solution built into the Hyper-V virtual switch and is the preferred approach on Hyper-V hosts running Windows Server 2025. Understanding the differences prevents choosing the wrong technology:
- LBFO: Works at the OS level independently of Hyper-V. Supports all three teaming modes (SwitchIndependent, LACP, Static). Visible as a standard NIC to Hyper-V if used as an external switch uplink. Supports up to 32 members. Does not support RDMA on team members.
- SET: Embedded inside the Hyper-V virtual switch. Supports only SwitchIndependent mode. Supports RDMA (Remote Direct Memory Access) on team members — critical for SR-IOV, RDMA-over-Converged-Ethernet (RoCE), and iWARP workloads. Supports up to 8 team members. Managed via
New-VMSwitchrather thanNew-NetLbfoTeam.
# --- Switch Embedded Teaming (SET) for Hyper-V hosts ---
# Create a Hyper-V external switch using SET with two physical adapters
# SET is enabled automatically when you specify multiple adapters to New-VMSwitch
New-VMSwitch `
-Name "HyperV-SET-Switch" `
-NetAdapterName "Ethernet 1","Ethernet 2" `
-EnableEmbeddedTeaming $true `
-AllowManagementOS $true
# Add an RDMA-capable management OS vNIC (Converged NIC pattern)
Add-VMNetworkAdapter -ManagementOS -Name "SMB-01" -SwitchName "HyperV-SET-Switch"
Add-VMNetworkAdapter -ManagementOS -Name "SMB-02" -SwitchName "HyperV-SET-Switch"
# Enable RDMA on the management vNICs
Enable-NetAdapterRdma -Name "vEthernet (SMB-01)"
Enable-NetAdapterRdma -Name "vEthernet (SMB-02)"
# Verify SET team members
Get-VMSwitch -Name "HyperV-SET-Switch" | Select-Object Name, EmbeddedTeamingEnabled, NetAdapterInterfaceDescriptions
Step 7: Verify Team Health and Simulate Failover
# Check team status and member states
Get-NetLbfoTeam -Name "LAN-Team" | Format-List
Get-NetLbfoTeamMember -Team "LAN-Team" | Format-Table Name, AdministrativeMode, OperationalMode, TransmitLinkSpeed
# Simulate a failover: administratively remove one member from the team
Set-NetLbfoTeamMember -Name "Ethernet 1" -Team "LAN-Team" -AdministrativeMode Standby
# Confirm traffic is flowing on the remaining adapter
Get-NetAdapterStatistics -Name "Ethernet 2" | Select-Object Name, ReceivedBytes, SentBytes
# Restore the adapter to active mode
Set-NetLbfoTeamMember -Name "Ethernet 1" -Team "LAN-Team" -AdministrativeMode Active
# Check Windows event log for teaming events (Event IDs 15314-15317)
Get-WinEvent -ProviderName Microsoft-Windows-NdisLbfo -MaxEvents 20 |
Format-Table TimeCreated, Id, Message -AutoSize
Conclusion
Network adapter teaming is one of the most cost-effective reliability improvements you can make to a Windows Server. With LBFO configured in Switch Independent mode and Dynamic load balancing, you get both failover protection and improved throughput with no switch-side configuration whatsoever — making it straightforward to deploy even in environments with unmanaged switches or limited network team access. For Hyper-V hosts, Switch Embedded Teaming unlocks RDMA and Converged NIC capabilities that are essential for high-performance storage and live migration workloads. Whichever technology you choose, always test failover explicitly by taking a team member offline and confirming that services continue uninterrupted before the configuration goes into production. Pair adapter teaming with monitoring of Windows NdisLbfo events so that silent adapter failures — where the link stays up but the adapter drops packets — do not go unnoticed.