Bug in NIC Teaming Wizard makes Duplicate Default Routes in Server 2012

When I build Windows 2012 Servers, I am often using the (fantastic) in-box NIC Teaming feature. While it let’s me join multiple network adapters together and treat them like one logical adapter, I often will create a “team” that has only one member so that I can assign the network settings to the logical adapter and then arbitrarily assign physical adapters to the team.? This give me great flexibility to do things like replace failed adapters, increase or decrease link redundancy, easily move servers to different physical switches or even upgrade from 1GBit to 10GBit adapters without needing to reassign network address information or be concerned with Hyper-V Virtual Network switch settings. However, I have discovered what appears to be a bug related to the NIC Teaming wizard that causes the server to end up with two default routes being set, and if left alone can result in failed network connectivity or some pretty terrible packet loss. The problem only seems to come up under pretty specific conditions:

• You create a team using only a single network adapter
• That adapter already had a static IP and Gateway defined
• You set a static IP and Gateway on the new logical team adapter
• The Gateway on the team does not “stick” and you manually set it a second time

What seems to be happening is the Default Route (gateway) that? was set on the physical adapter is not being deleted when the team is made, and when you add the gateway to the Team adapter, the default route is defined a second time, which causes confusion and delay. Below is the process that you can use to reproduce the problem, as well as how to fix it. Install Windows Server 2012 RTM (I used Datacenter, but Standard will do it too) and configure a network adapter (I named it NIC1) with a Static IP, Gateway and DNS.

You should be able to access the network, ping things and see a single route being defined when you use route print” from the command prompt. 

Create a new network team (I’ll call it Host) and add the network adapter (NIC1) to it. In this example, the team will only have the one-member adapter.

Once created, open the TCP/IPv4 Properties of the new Team adapter (Host) and you’ll notice that it is configured to use DHCP, yet the Gateway is defined but greyed out.? Odd?? Yeah.

Configure a static IP address and click OK twice.

Test the network connectivity by attempting to ping a hostname outside the subnet of the statically assigned address. DNS will resolve if the DNS servers are in the same subnet, but pinging may fail.

Using route print indicates that the default gateway is defined… However, if you look at the TCP/IPv4 Properties of the Teamed nic, the gateway is now blank.

Manually re-enter the gateway and click OK twice. 

 Attempt to ping the external resource again, and this time it may work. Note: If you use a persistent ping, you may discover that up to 30% of the packets are lost!

Using route print again, you’ll discover that there are now TWO routes defined for 0.0.0.0, and sometimes a different metric may be set for each.

To fix this, delete the route for 0.0.0.0, which will remove both entries.

Return to the TCP/IPv4 Properties of the Teamed adapter and re-enter the gateway address (which is now blank again).

Using route print shows that only one route for 0.0.0.0 is defined now, and pings work just fine. 

So how do you avoid this problem in the first place?? Well, it seems if you (1) create the team with two or more members (which is vastly more common) this doesn’t happen.? Also, (2) if the gateway is not defined on any of the physical adapters, then there are no routes to mess with, so there are no problems to cause.? You can also (3) remove the static IP and Gateway from the physical adapter before creating the team. I’ve already reported this as a bug to Microsoft, albeit a little one.? N’joy!