Windows Server 2012 NIC Teaming: So Easy a Caveman Can Do It?

One of the most highly requested and anticipated features of Windows Server 2012 and Hyper-V is the built in NIC teaming functionality. As many readers know, NIC teaming is the concept of taking two physical NICs and creating from them a “team” which appears to the operating system as one NIC. This provides network high availability as one member of the team may fail but the team remains functional and network connectivity preserved as long as one or more of the team’s NICs are still connected. This has long been an area of complexity and some frustration in Hyper-V through Windows Server 2008 R2 as providing network resiliency required 3rd party solutions, some of which were pretty good, and some of which were not. I’ll not name names here :) For a while VMware has had teaming functionality built in, and with Windows Server 2012, Microsoft will now have a robust but very simple to configure solution built in with a number of advantages.

Two of the best resources for learning about this new capability are listed below. The first is a good overview, the second an in-depth document for understanding and setting up NIC teaming in the Beta release. Since this is Beta, obviously specifics and details may change by RTM.

Network Adapter Teaming Technical Preview (link)

The Windows Server “8” Beta NIC Teaming User Guide (link)

As you will see, there are a couple of design choices to be made when implementing NIC teaming (using switch independent or LACP modes of operation and which traffic distribution algorithm to use). A second critical consideration is the network adapter hardware and the combination of networking features you require at both the host and guest level.

It is critical when designing a Windows Server 2012 and Hyper-V based solution to map out which features can work in conjunction with each other and which features are mutually exclusive. Examples include whether and when RDMA (link) is available, what features are compatible with SR-IOV (link) and so on.

For this post I’ll focus on one example which is that when using SR-IOV, the network traffic of VMs does not pass through the virtual switch, thus does not pass through a team at the host level. The benefit of direct network adapter access by the VM is important, but at first seems to prohibit network connection high availability. Fortunately, the powerful NIC teaming capability also functions within Windows Server 2012 virtual machines. So in the case where you want to take advantage of SR-IOV capable NICs (and associated server motherboards/BIOS), you can still provide highly available network connectivity to virtual machines by adding two vNICs to each VM, with the vNICs assigned to virtual functions of the underlying adapters (if you read John Howard’s SR-IOV series linked to above you will know what this is). Then, inside the Windows Server 2012 VMs, you will see two adapters, which themselves can be teamed. Should there be a failure or loss of connectivity to one of the two host NICs, the team inside the VMs will maintain connectivity as the team will keep the connection alive.

This is a very powerful feature and illustrates that Windows Server 2012 and Hyper-V provide a variety of features that can be combined in different ways to meet varying business and technical requirements.

The user interface for NIC teaming is quite simple but also very powerful. Given the ease of use and the robustness evident even in the Beta, I’m certain this will be one of the most highly utilized features in Windows Server 2012 and Hyper-V. I’m running it on some of my lab servers with cheap and disparate NICs.

  • Pingback: High Availability SMB 3.0 Connectivity

  • Pavol Boles

    Hi,

    how is the MAC of the team been determined? The foll. explanation: “In switch independent / address hash configuration the team will use the MAC address of the primary team member” is a little bit vague I think. At least that’s not what I was able to test:

    1. I’ve set up a “switch independent / address hash conf.” team
    2. the MAC address of the team matched the address of the primary (the first NIC I’ve added to the team) team member
    3. after reboot the MAC address of the team matches the second NIC added to the team

    How to work past this if you want to have your IPs assigned dynamically (DHCP)?

    Thank you for your reply.
    Best regards,
    P

    • http://blogs.technet.com/davidzi davidzi

      Hi Pavol, great question, I had to do some checking on this one with the product group. What you saw is default behavior where its not guaranteed that the team will pick up the MAC of the first or primary adapter consistently. However, if you go into the properties of the team interface (in Network Connections, the one that says “Microsoft Network Adapter Multiplexor”, then click the Configure button, then select the Advanced tab, the 6th item in the list is MAC Address. If you configure a MAC there for the team, it should be consistent across reboots therefore letting you use it for configuring DHCP reservations. I’ll verify this today or tomorrow in my lab and put up a post with details. Thx! Dave

      • Pavol Boles

        Hi Dave,

        first of all: thanx for your reply. Manually setting the MAC address might indeed seem as the easiest way, however it’s far from convenient. The question is more a general one: How is the order determined? Because from what you’ve now already witnessed the team will not pick up the MAC of what MS refers to as the “primary team member”.

        Does the “primary” here refer to the order at all? Or should we think of it as of a “priority” perhaps? Can this be modified?

        For years I’ve been using HP teaming and observed a pattern (depends on the HW installed) when assigning (prioritizing) the MAC to the team by the vendor driver. This helped me to create the DHCP scopes appropriately. The thing is these MAC addresses never changed, yet with Win2012 the MAC changed after the first reboot.

        So the question is: Will it be randomized after each reboot or is there some sort of determinism to it? I’d like get to the gist of it.

        Best regards,
        Pavol

        • http://blogs.technet.com/davidzi davidzi

          The teamed NIC will pick up the MAC of whichever physical NIC reports to the OS first which, unfortunately, will vary between reboots so will not be deterministic. So that is the root issue in your question.
          One thing that may help is another feature in WS 2012 called consistent device naming (CDN) which (if your server hardware supports it) provides a deterministic mapping between physical ports and how Windows sees them (ex. physical port 1 equals Local Area Connection 1 in Windows)
          So you could have a methodology where you always want port 1 and port 2 teamed and using the MAC of NIC1 for the team’s MAC so you can do DHCP reservations. Using the method I described about the advanced property all that can be configured.
          Certainly doing that manually is not optimal but I believe all of it can be automated:

          1. With CDN we know the NIC names will map to physical in a deterministic way (NIC 1 = Local Area 1 or something like that)
          2. I could logically decide that NIC 1 and 2 will always be teamed on my servers
          3. PowerShell from here out:
          a. I could get the MAC of NIC 1
          b. Create a new team
          c. Write the MAC of NIC1 as the MAC of the team in advanced properties
          d. Create a DHCP reservation for the tNIC using the MAC from the advanced properties
          That’s a pretty normal set of initial setup automation and should be relatively straight forward. If I have time I might try that out in my lab this week.
          Thanks!
          Dave