If you would like to be read the other parts of this article series please go to:
- Windows NIC Teaming using PowerShell (Part 1)
- Windows NIC Teaming using PowerShell (Part 3)
- Windows NIC Teaming using PowerShell (Part 4)
- Windows NIC Teaming using PowerShell (Part 5)
- Windows NIC Teaming using PowerShell (Part 6)
- Windows NIC Teaming using PowerShell (Part 7)
- Windows NIC Teaming using PowerShell (Part 8)
Introduction
As I mentioned in my previous article in this series, planning is the key to success in all cases. This is no less true when it comes to something like Windows NIC Teaming, so this present article examines various things you need to be aware of and to consider before you try to implement NIC Teaming on Windows Server 2012 or later.
Choosing the right teaming mode
We saw from Figure 1 in the previous article that when you use the UI to create a new team you have a choice of three teaming modes to choose from:
- Static Teaming
- Switch Independent
- LACP
This is actually a bit confusing because there are really only two types of teaming modes available:
- Switch independent
- Switch dependent
The UI doesn’t display a mode called Switch Dependent but instead displays two types of switch dependent modes:
- Static Teaming
- LACP
So your choices for teaming mode really look like this:
- Switch Independent
- Switch Dependent
- Static Teaming
- LACP
Let’s examine this in more detail.
When to use Switch Independent teaming
Switch Independent is the default teaming mode when you create a new team. This mode assumes that you don’t need your Ethernet switches to participate in making NIC teaming happen for your server. In other words, this mode assumes the Ethernet switch isn’t even aware that the NICs connected to it are teamed.
Because of this, selecting Switch Independent mode allows you to connect each NIC in a team to a different Ethernet switch on your backbone. However, you can also use this mode when all the NICs in the team are connected to the same Ethernet switch.
One scenario where you could use this functionality is to provide fault tolerance in the case of one of the teamed NICs failing. For example, you could create a team from two NICs (NIC1 and NIC2) on your server and then connect NIC1 to SWITCH1 and NIC2 to SWITCH2. You could then configure NIC1 as the active adapter for the team, and NIC2 as the standby adapter for the team. Then if NIC1 fails, NIC2 will automatically become active and your server won’t lose its connectivity with your backbone.
Note that the above approach, which is variously called Active/Passive Teaming or Active/Standby teaming, provides fault tolerance but not bandwidth aggregation for your server’s connection to the network. You can just as easily leave both NICs configured as active and get both fault tolerance and bandwidth aggregation if you prefer, but the choice is up to you.
When to use Switch Dependent teaming
You can only use one of the Switch Dependent modes (static teaming or LACP) if all of the teamed NICs are connected to the same Ethernet switch on your backbone. Let’s consider
Static Teaming (also called generic teaming or IEEE 802.3ad teaming) requires configuring both the server and Ethernet switch to get the team to work. Generally only enterprise-class Ethernet switches support this kind of functionality, and since you need to manually configure it on the Ethernet switch it requires additional work to get it working. Plus manually configuring something always increases the odds of configuration errors happening if you make some kind of mistake during the setting up process. If at all possible, try to stay away from following this approach to NIC teaming on Windows Server.
LACP (also called IEEE 802.1ax teaming or dynamic teaming, which should not be confused with the new Dynamic load balancing mode available for NIC Teaming in Windows Server 2012 R2) uses the Link Aggregation Control Protocol to dynamically identify the network links between the server and the Ethernet switch. This makes LACP superior to static teaming because it enables the server to communicate with the Ethernet switch during the team creation process, thus enabling automatic configuration of the team on both the server and Ethernet switch. But while most enterprise-class Ethernet switches support LACP, you generally need to enable it on selected switch ports before it can be used. So LACP is less work to configure than Static Teaming, but still more work to set up than switch independent teaming which is the default option for Windows NIC Teaming.
Choose Switch Independent teaming
The bottom line then is that Switch Independent teaming is generally your best choice to select for the teaming mode when creating a new NIC Team for two reasons. First, you don’t need to perform any configuration on the Ethernet switch to get it working. And second, you can gain two kinds of fault tolerance:
- Protection against the failure of a NIC in the team
- Protection against the failure of an Ethernet switch connected to a teamed NIC (when you are connecting different teamed NICs to different Ethernet switches)
However, there are a couple of scenarios described later on below where Switch Dependent teaming might be the best choice if your Ethernet switches support such functionality and you’re up to configuring it.
Choosing the right load balancing mode
Let’s say you’ve chosen Switch Independent teaming as the teaming mode for a new NIC team you’re creating. Your next decision is which load balancing mode you’re going to use. As described in the previous article in this series, NIC Teaming in Windows Server 2012 supports two different load balancing modes: Address Hash or Hyper-V Port. Windows Server 2012 R2 adds a third option for load balancing mode called Dynamic, but at the time of writing this article there are few details on how it works so we’ll revisit it later once more information becomes available. And if you’re server is running Windows Server 2012, this load balancing mode isn’t an option for you anyways.
When to use Address Hash
The main limitation of this load balancing approach is that inbound traffic can only be received by a single member of the team. The reason for this has to do with the underlying operation of how address hashing uses IP addresses and TCP ports to seed the hash function. So a scenario where this could be the best choice would be if your server was running the kind of workload where inbound traffic is light while outbound traffic is heavy.
Sound familiar? That’s exactly what a web server like IIS experiences in terms of network traffic. Incoming HTTP/HTTPS requests are generally short streams of TCP traffic. What gets pumped out in response to such requests however can include text, images, and video.
When to use Hyper-V Port
This load balancing approach affinitizes each Hyper-V port (i.e. each virtual machine) on a Hyper-V host to a single NIC in the team at any given time. Basically what you get here is no load balancing from the virtual machine’s perspective. Each virtual machine can only utilize one teamed NIC at a time, so maximum inbound and outbound throughput for the virtual machine is limited to what’s provided by a single physical NIC on the host.
When might you use this form of load balancing? A typical scenario might be if the number of virtual machines running on the host is much greater than the number of physical NICs in the team on the host. Just be sure that the physical NICs can provide sufficient bandwidth to the workloads running in the virtual machines.
Other options
If you implement NIC teaming on a Hyper-V host and your virtual machines need to be able to utilize bandwidth from more than one NIC in the team, then an option for you (if your Ethernet switch supports it) is to configure LACP or Static Teaming as your teaming mode and Address Hash as your load balancing mode. This is possible because it’s how you configure the Ethernet switch that determines how traffic will be distributed across the team members. This scenario is kind of unusual however because typically if you have a virtualized workload that requires high bandwidth for both inbound and outbound traffic (such as a huge SQL Server database workload) then you’re probably only going to have one or two virtual machines running on the Hyper-V host.
Then there’s the matter of implementing NIC teaming within the guest operating system of the virtual machine as opposed to the underlying host’s operating system. But we’ll leave discussion of that topic until the next article in this series, and after that we’ll start examining how Windows PowerShell can be used to configure and manage NIC teaming on Windows Server 2012 or later.
If you would like to be read the other parts of this article series please go to:
- Windows NIC Teaming using PowerShell (Part 1)
- Windows NIC Teaming using PowerShell (Part 3)
- Windows NIC Teaming using PowerShell (Part 4)
- Windows NIC Teaming using PowerShell (Part 5)
- Windows NIC Teaming using PowerShell (Part 6)
- Windows NIC Teaming using PowerShell (Part 7)
- Windows NIC Teaming using PowerShell (Part 8)
