How to Set Up Native Teams in Hyper-V Server 2012

Network adapter teaming is not a new concept by any means, but the introduction of native teaming in the Windows Server 2012 product marks the first time that Microsoft has openly supported it. It is also the technology that made Converged Fabrics feasible for a Hyper-V host. Since we have covered the concepts of the team in other entries, this post will only deal with functionality.

How to Set up a Team in Windows Server 2012 or Hyper-V Server 2012

Unlike the virtual switch, it’s not as critical that you use PowerShell for a team, since nothing is permanent. I still prefer PowerShell because it’s faster and, in my opinion, easier than the GUI.

The GUI Way

In Server Manager, switch to the “Local Server” tab. There’s a “Teaming” entry on the left. It will have a status of “Enabled” if you have a team and “Disabled” if you don’t. Whichever it says, click it. You should get something akin to the following:

Main Teaming Window

To create a new team, click on the Tasks drop-down box in the Teams section in the lower left and choose “New Team”. You’ll be greeted with the following window:

New Team Window

This is pretty straightforward. Name it and pick the adapters you want to be part of it. Expand “Additional Properties” for the other options. Pick your teaming and load-balancing mode. When the team is created, an adapter will be created on it. If necessary, you can pick a VLAN for that adapter to be a member of. If you do so, it will only receive packets with an 802.1q tag for that VLAN. If no other adapters are created, then all other traffic on that team is discarded. If you leave the adapter at default, it gets all traffic. This is the setting you want for an adapter that will host a Hyper-V virtual switch.

The right side of the main screen deals with the team’s adapters, both the physical adapters it sits on and the adapters that it hosts, called “Team Interfaces”. You can use the Tasks drop-down on this section to create additional adapters on the team. Do not do this in any situation in which you will use the Hyper-V switch on the team. More on this later.

The PowerShell Way

All the magic happens with New-NetLbfoTeam. There aren’t many parameters on this. Let’s go through them:

LoadBalancingAlgorithm

You can choose between TransportPorts, IPAddresses, MacAddresses, or HyperVPorts. The descriptions in the Microsoft document are accurate but will be expanded on in the section after this.

Name

If you guessed, “Name of the team”, give yourself a gold star.

TeamMembers

This is a comma-separated list of the names of the adapters that you want to put into the team. You can find adapter names with Get-NetAdapter.

TeamNicName

No, not a nickname, a NIC name. When the team is created an adapter (team interface) is created on it. If you want, it can have its own name. Otherwise, you can skip this parameter and it will get the same name as the team.

TeamingMode

Your choices are LACP, Static, and SwitchIndependent. The descriptions in the document are pretty good but will be expanded on later.

Related Cmdlets

There are a number of supporting cast members for your team. They are all documented in one convenient location. Of particular interest are Get-NetLbfoTeam, which is a quick way to see the status of a team, Get-NetLbfoTeamMember, which shows you the status of an individual member, and Add-NetLbfoTeamMember and Remove-NetLbfoTeamMember, who pretty much speak for themselves. You can use Set-NetLbfoTeam to modify the team and Set-NetLbfoTeamMember to set a member online or offline.

Notes on the Windows Team

• There is no functional difference between LACP and Static teaming. They both require that the switch you connect to be set to the same mode and you cannot connect to multiple physical switches in the same LACP or Static team. There are some switches that allow a stacked configuration in which multiple switches join to become the same logical switch, and these can usually accept a LACP or Static team that spans physical members.
  A static team trusts that the administrator knows what s/he’s doing. If a member adapter sees a connection on the other end, it marks that link as up and participating in the team. If there’s a misconfiguration, the static team won’t know. You’ll know because you’ll have lots of communications problems. A LACP team is (effectively) a static team with integrity checks. The ports on each side negotiate with each other and will stop participating if anything is wrong on the other end.
• Not all switches support LACP equally. You may need to change your load-balancing algorithm to get some to work, and some may never work.
• There is a reason for the apparent discrepancy in the load-balancing names in the GUI and in PowerShell, although it’s up to you if you think it’s a good one. The “Address Hash” mode in the GUI is essentially the same thing as “TransportPorts” in PowerShell. They both rely on a hash of the source/destination ports and source/destination IPs. However, not all communications has all that information. Packets can be tracked by IP  if they don’t have port information, and then by MAC address if they don’t have IPs. Higher levels will automatically fall back to lower levels. You can force the maximum level in PowerShell by using one of the other two modes. Once done, it will show in the drop-down box in the GUI.
• The load-balancing mode you set only applies to outbound traffic. Inbound traffic load-balancing is determined by the connected switch.
• In switch independent mode, all inbound traffic will cross the primary adapter. This is because a MAC address can only be registered on a single port. LACP and static teams are treated like ports and so MAC addresses are registered on the team, not the member ports. You cannot choose the primary adapter on the Hyper-V side.
• If using HyperVPorts load-balancing, virtual adapters are bound to specific physical adapters and do not move unless the port fails. This is the one exception to the rule of all MAC addresses being bound to a single port in switch independent mode.
• I haven’t found any way to designate a standby adapter using PowerShell. I haven’t looked all that hard, either. Standby adapters are only available in switch independent mode, and don’t seem to be incredibly useful. Feel free to leave a comment if you can do it in PowerShell and/or you know of a good reason to use active/standby.
• You cannot use SR-IOV with teaming.
• HyperVTransports mode is pretty much useless if you aren’t using virtual adapters on a Hyper-V switch. As in, 100% of your outbound traffic will use the primary adapter. Inbound traffic will still be balanced by the connected switch, but it will need to be a switch dependent mode.
• Don’t use multiple team interfaces at the same time as you use a Hyper-V virtual switch. The behavior is unpredictable at best.
• There is no QoS balancing for multiple team interfaces. Use the Hyper-V virtual switch with a single team interface.
• There can be only one team interface per VLAN.
• For all load-balancing methods except HyperVPorts, vNICs will try to register a VMQ on every single adapter in the team. This can deplete your available queues in a hurry. Use HyperVPorts if VMQ is important and your physical adapters don’t have enough queues to satisfy the evenly-spread load.
• Many guides insist that you should default to the HyperVPorts mode if you are using a Hyper-V switch. Unless you’re using the switch independent mode, this is an unjustified oversimplification. The closer you are to a 1:1 ratio of vNICs to pNICs, the better the AddressHash mode will perform. There is, unfortunately, no magic number that will tell you which to use. Higher vNIC counts with higher traffic loads are usually better served by HyperVPorts mode.