NIC Teaming with Windows 2012 R2

While working on the new Active Directory it struck me that we may have a bottleneck issue on the network between all my users and my one MAD-DC/File Server machine, Jupiter. So I wondered if there was any way I could leverage the three extra NIC’s on the HP Proliant Gen8 server. We started by unbagging three Cat5e cables we bought from Monoprice, then I stranded them together and braided them along to make one three-ended Cat5e super-cable. I plugged them into the three remaining NIC’s and then my S3 plugged the other ends into our switches. We elected to use a diversity of switches, so two connections go to our Catalyst 3850 called Bravo, and two go to our mostly open Catalyst 3560 called Delta. There is probably no real good reason why using different switches would matter, but it also seems to not matter either way, so hooray. Then I did a bit of reading and it turns out that Windows 2012 R2 Server includes server-based NIC teaming as part of the basic function of the OS. I poked around the shrubberies for a little while, did a little bit of TechNet reading and then added all four NIC’s to a team. That was a mistake. The one NIC has, previous to this, been created as a Hyper-V vEthernet Virtual Switch for my two Hyper-V guests running on this server and when I added everyone together as a happy team I sort of expected it to work. I suppose it was a hold-over from when I was a Mac admin in the long-ago. Everything sputtered and stopped, so I attached a terminal to the server, logged in, and deleted the “everyone all together” team. Then I turned around and left the Hyper-V vEthernet Virtual Switch all by itself, but added the remaining three NIC’s together as a new team and that came together very nicely. They are switch-independent, using “Dynamic” load balancing (which turns out to be the default and the best option) and I configured them all to use a new IP address on my LAN. So now I’ve got my MAD-DC/File Server with two IPs for its DNS entry. I half wanted to figure out some way to force the issue, that the team-IP takes precedence over the non-team-IP interface. From what I’ve seen, the only distinction seems to be who connects first, and perhaps it’s related to some specific drive mappings we have set up. I like to consider the non-teamed interface as “Local Lanes” and the teamed interface as “Express Lanes”. Our CAD department moves rather large files, and to avoid their activities from clogging up the file server for everyone else I defined the drive map for them to point explicitly to the IP address related to the teamed interface. When a CAD user logs in, this appears to force every connection to use the teamed interface. When a non-CAD user logs in, without the drive mapping that’s specifically for the teamed interface, it uses the non-teamed interface instead. I suppose I don’t really care either way, but it is nice to know that the extra ports and NICs will be doing actual work and not just sitting there being lazy. We’ll only really see any benefit from any of this if CAD starts to move big data sets around and nobody else notices any issues with the file server. That the chance of people actually noticing is probably slim to none, this entire thing is probably going to end up being a flash in the pan. At best it eliminates a bottleneck, at worse, I suppose, it makes full use of all the NICs on the server and four ports on our Catalysts. That’s a win/win. Not too bad for a pie-in-the-sky start, I have to say.