Windows Server 2012: NIC Teaming

Windows Server 2012: NIC Teaming

I don’t tend to use a lot of Windows in recent years, but if you look at my past articles I used to do quite a bit around Hyper-V, DFS, Exchange, and various other Windows Services.  One thing that was always frustrating is the inconsistent experience around NIC teaming.  Basically Teaming allows you to gain throughput and resiliency by having multiple physical NICs listen over the same logical NIC.  The reason of this inconsistency was that teaming was always provided by the hardware/driver manufacturer so features and configurations would be implemented separately.

Well the good news is that it appears that Microsoft has decided to reverse course with this in Windows Server 2012.  Which is most definitely a good thing for users.

So while I don’t plan on going too deep into Windows 2012 I thought this would be worth a quick run through.

Figure 1-1:  Above you will find the Local Server view of the Server Manager tool.  You will notice on the left near the center we have our 2 ethernet connections.  In my case these are inside of Virtualbox VM and these are NAT connections.  But directly above that you see “Nic Teaming: Disabled”

Figure 1-2:  Above you will notice the NIC Teaming Details screen.  You get here by clicking on Disabled in Figure 1-1.  Notice in the bottom left we have no Teams configured, and in the bottom right we have 2 adapters available for teaming.

Figure 1-3:  Here we simply highlight the available interfaces, then in the TASKS menu select Add to New Team.

Figure 1-4:  Assign a Team Name.  Here I am using team0.

Figure 1-5:  Now we have a working Team which contains the two Ethernet Adapters.

Figure 1-6:  Just for giggles I switched the second Ethernet Adapter in Virtualbox from “NAT” to “Not Attached” to simulate network failure, and above is what I got.

Now I don’t like to do anything that I can’t do from the command line, frankly that is mostly because that is far easier to document then having to worry about screenshots.  So lets do the same thing with Powershell.

PS> New-NetLbfoTeam -Name team0 -TeamMembers (Get-NetAdapter | where {$_.name -match "Ethernet"}).name

Confirm
Are you sure you want to perform this action?
Creates Team:'team0' with TeamMembers:{'Ethernet 2', 'Ethernet'}, TeamNicName:'team0', TeamingMode:'SwitchIndependent'
and LoadBalancingAlgorithm:'TransportPorts'.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

Name                   : team0
Members                : {Ethernet 2, Ethernet}
TeamNics               : team0
TeamingMode            : SwitchIndependent
LoadBalancingAlgorithm : TransportPorts
Status                 : Down

As we can see from the above output we can choose the Teaming Mode and Load Balancing Algorithm.  For the Teaming Mode you can use Switch Indepent, Static, and LACP.  The latter two options require the switch to support and/or be configured to allow that configuration to work.  You have your choice of Load Balancing Algorithms (IP Address, MAC Address, Transport Ports, and Hyper-V Port) the first three use the IP/MAC/Port from the source and destination to create a hash and then balance the traffic appropriately, the Hyper-V Port doesn’t do any hashing as far as I can tell, it simply splits the Hyper-V Ports over the interfaces.

We can also see that the status is “down” but fear not.  Give it about 15 seconds and then look at the team again.

PS> Get-NetLbfoTeam

Name                   : team0
Members                : {Ethernet 2, Ethernet}
TeamNics               : team0
TeamingMode            : SwitchIndependent
LoadBalancingAlgorithm : TransportPorts
Status                 : Up

This will give you network based teaming, there are also some additional options to allow you to use LACP and other algorithms.  For me this is a big change, but the more impactful change is the change in Network Connection names.  Now they seem to be using Ethernet followed by Ethernet 2 and so on.  Which for me is far superior to Local Area Connection followed by Local Area Connection 2 and so on.  I think it would have been better to use Ethernet0 or Ethernet1 just to give you consistent numbering, through multiple interfaces.  But I will take what I can get.