If you would like to be read the other parts of this article series please go to:
- Windows NIC Teaming using PowerShell (Part 2)
- 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
Windows servers today are often huge beasts with tons of processing power to handle the biggest business workloads. Getting data in and out of such servers requires fat pipes–lots of network bandwidth–and for some environments even a single 10 GbE Ethernet network interface card (NIC) is insufficient and becomes a bottleneck. And what if that NIC fails for some reason? Your enterprise-class server suddenly becomes an expensive paperweight!
NIC teaming can address such problems. Also known as Load Balancing/Failover (LBFO), NIC teaming refers to any technological approach that enables two or more NICs to be linked together to form a team of some kind. Until recently, if you wanted to use NIC teaming you had to implement a proprietary solution provided by your NIC hardware vendor. But beginning with Windows Server 2012, you now have an in-box solution called Windows NIC Teaming that you can use for implementing NIC teaming on your Windows servers.
NIC Teaming in Windows Server 2012
Let’s begin with a quick overview of what Windows NIC Teaming is, what kinds of scenarios it can address, and what types of configuration modes it supports. The following short description is excerpted from my free ebook Introducing Windows Server 2012 RTM Edition (Microsoft Press, 2012) which has been downloaded over 650,000 times since it was released just over a year ago.
Windows NIC Teaming is the name for the new network adapter teaming functionality included in Windows Server 2012. Network adapter teaming is also known as load balancing and failover (LBFO) and enables multiple network adapters on a server to be grouped together into a team. This has two purposes:
- To help ensure availability by providing traffic failover in the event of a network component failure
- To enable aggregation of network bandwidth across multiple network adapters
Previously, implementing network adapter teaming required using third-party solutions from independent hardware vendors (IHVs). Beginning with Windows Server 2012, however, network adapter teaming is now an in-box solution that works across different NIC hardware types and manufacturers.
Windows NIC Teaming supports up to 32 network adapters in a team in three teaming modes:
- Static Teaming – Also called Generic Teaming and based on IEEE 802.3ad draft v1, this mode is typically supported by server-class Ethernet switches and requires manual configuration of the switch and the server to identify which links form the team.
- Switch Independent – This mode doesn’t require that the team members connect to different switches; it merely makes it possible.
- LACP – Also called dynamic teaming and based on IEEE 802.1ax, this mode is supported by most enterprise-class switches and allows automatic creation of a team using the Link Aggregation Control Protocol (LACP), which dynamically identifies links between the server and a specific switch. To use this mode, you generally need to enable LACP manually on the port of the switch.
Since a picture is worth a thousand words, Figure 1 shows the three teaming modes you can choose from when creating a new team in Windows Server 2012:
Figure 1: The three teaming modes in Windows Server 2012.
NIC Teaming in Windows Server 2012 R2
While NIC Teaming in Windows Server 2012 provided both distribution of network load across NICs in a team and failover support for teamed NICs, network traffic was not distributed across teamed NICs in a balanced fashion. Beginning with Windows Server 2012 R2 however, a new feature called dynamic load balancing automatically and continuously balances traffic across teamed NICs in an equitable fashion.
Figure 2 is another thousand-word picture that illustrates this new functionality for NIC Teaming in Windows Server 2012 R2. Previously in Windows Server 2012 you only had two load balancing modes you could choose from:
- Address Hash – This algorithm distributes traffic among the teamed NICs by creating a hash from the address components of the packets that comprise a single stream of TCP traffic. The algorithm then assigns packets that have that particular hash value to one of the NICs in the team.
- Hyper-V Port – This approach distributes traffic among the teamed NICs on the basis of the Mac address or port a virtual machine uses to connect to the virtual switch on a Hyper-V host.
As you can see from the figure however, a third load balancing mode called Dynamic has now been added to NIC Teaming in Windows Server 2012 R2. Not only that but this new mode is now the default load balancing mode when you create a new team on the new platform.
Figure 2: The new Dynamic load balancing mode for NIC Teaming in Windows Server 2012 R2.
Why use PowerShell for configuring NIC Teaming?
And with that being said, those two figures are the only ones we’ll include in this series of articles on configuring and managing NIC Teaming in Windows Server 2012 and Windows Server 2012 R2. For instead of using the NIC Teaming user interface shown in the above figures, we’re going to use Windows PowerShell instead to create and configure our NIC teams in our physical and virtual Windows Server environments. Why is that?
First, you can use Windows PowerShell to configure NIC Teaming on servers running the Server Core installation option of Windows Server 2012 or later. Why is that important? Well, if you’re thinking of deploying new Windows servers into your environment, you should consider making them Server Core machines rather than Server With A GUI machines. In fact, Microsoft gives us a big fat hint pushing you in this direction because if you perform a manual installation of Windows Server 2012 or later, the Server Core option is automatically selected by default. Why should you choose the Server Core option over the GUI one when you deploy Windows Server? Because Server Core machines require less servicing and have a smaller attack surface since they have fewer components installed and needing to be kept current with software updates.
The second reason of course for using PowerShell is that it allows automation through scripting. This means you can use PowerShell to script the creation and configuration of NIC teams across multiple servers in your environment. Automation saves time and reduces error when you have tasks you need to perform repeatedly.
In the next article
Before we can actually start using PowerShell to configure and manage NIC teams, we first need to better understand the different kinds of scenarios one can implement with NIC teaming. Planning is the key for success in all cases, so in the next article of this series we’ll examine NIC teaming planning issues and considerations in more detail.
If you would like to be read the other parts of this article series please go to:
- Windows NIC Teaming using PowerShell (Part 2)
- 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)
