I have been using the Windows Server NIC teaming feature in my lab and production environments ever since the release of Windows Server 2012. I had always assumed that NIC teaming would give my servers a performance boost, although admittedly I had never taken the time to do any benchmark comparisons. Recently, however, I began to notice that NIC teaming might not be doing what I always thought that it did. Let me explain.
What is Windows Server NIC teaming?
For those who might not be familiar with Windows Server NIC teaming, it is a mechanism that allows multiple physical NICs to be bound together into a single logical NIC. That logical NIC therefore has the capabilities of all the underlying physical hardware.
You can see the end result in the figure below. This figure shows an administrative PowerShell window on a lab server that is running Windows Server 2012 R2. As you can see, I used the Get-NetAdapter cmdlet to list all of the network adapters that are installed in the server.
The cmdlet used in the figure above displays five different network adapters. The first one on the list (vEthernet) is a Hyper-V virtual Ethernet adapter, and it has a link speed of 10Gbps. I don’t actually have any 10Gbps hardware installed, but it doesn’t matter because this NIC is purely virtual.
The next three NICs that are listed are physical NICs running at 1Gbps each. The last network adapter on the list is named MyTeam. This one is a NIC team that is made up of the three physical network adapters that are listed by the cmdlet. As previously mentioned, those three NICs run at 1Gbps each. The NIC team, therefore, has a listed speed of 3Gbps, which is the aggregate speed of the physical NICs that make up the NIC team. So far, so good, right?
But have I really created a 3Gbps NIC? Think about that one for a moment: The Ethernet standards generally define link speeds in increments of 10. The Fast Ethernet standard that everyone was using in the 1990s ran at 100Mbps. Today, of course, we have 1Gbps and 10Gbps Ethernet. Yes, there are some fairly abnormal speeds beyond 10Gbps, but the point is that there is no defined 3Gbps standard. So how is it that we have a 3Gbps link?
The simple explanation is that we don’t really have a 3Gbps link. Instead, we have three separate 1Gbps links, and 1Gbps is a clearly defined Ethernet standard. If that’s true, however, then the next logical question is whether Windows is really giving us 3Gbps connectivity. PowerShell says that we have a 3Gbps link, but are we really getting 3Gbps throughput?
This is where things start to get a little bit weird. In the time that has passed since the release of Windows Server 2012 (when NIC teaming was introduced), I have read numerous articles, blog posts, etc. that indicated that NIC teams aggregated the available bandwidth. Indeed, that is what PowerShell seems to indicate is happening. However, the idea that Windows Server NIC teaming provides aggregate bandwidth is only partially true. Let me show you what I mean.
The figure below shows what happened when I ran a utility called LAN Speed Test (Lite) on the desktop computer that I am using to write this article right now. Incidentally, this is a free and completely portable utility that you can easily use to try this experiment out for yourself.
At any rate, my desktop computer does not have a NIC team installed. It uses a single, 1Gbps adapter. I configured the utility to transfer a file to a file share residing on a computer that is configured to use a NIC team. In other words, the file transfer speed would have been limited to 1Gbps because of the speed of the NIC in my desktop computer.
The test evaluated both the write (upload) speed and the read (download) speed. I won’t bore you with all of the statistics, but the upload speed was roughly about 711Mbps and the download speed was about 732Mbps.
Next, I ran the test again. This time, I connected to the same share from a server that had NIC teaming enabled. Both systems had a 3Gbps NIC team, so the transfer speeds should theoretically not be limited to 1Gpbs if Windows was performing true bandwidth aggregation. Here are the results.
As you can see, the upload speed was only about 458Mbps, significantly slower than when I ran the test from a machine with no NIC team. The download speed was about 764Mbps, which was a little bit faster than the previous test.
Admittedly, this was not a scientific test. Although no major workloads were running on either machine, I did not go to great lengths to ensure that everything was configured identically on both machines. Even so, the important takeaway here is that neither machine exceeded 1Gbps in spite of having a 3Gbps NIC team.
So, what do we really have?
Based on my observations, Windows Server NIC teaming does not seem to provide true bandwidth aggregation. What they do seem to do, however, is to perform load balancing. While a NIC team may never distribute a single traffic stream across multiple NICs, it can perform load balancing by assigning different traffic streams to different NICs. NIC teams are also useful from a fault tolerant standpoint. In fact, it is possible to designate a spare NIC within a NIC team. The spare NIC will be automatically used in the event of a NIC failure.
Photo credit: Shutterstock