{"id":2424,"date":"2018-01-05T19:59:39","date_gmt":"2018-01-05T19:59:39","guid":{"rendered":"http:\/\/microsoftgeek.com\/?p=2424"},"modified":"2018-01-05T20:00:29","modified_gmt":"2018-01-05T20:00:29","slug":"2424","status":"publish","type":"post","link":"https:\/\/microsoftgeek.com\/?p=2424","title":{"rendered":"Windows Server 2016: NIC Teaming functionality"},"content":{"rendered":"

NIC teaming is not something we got with Windows Server 2016 but I just find it interesting to review this functionality as we have it in the current iteration of Windows Server, as usual, touching a bit on basics and history of this feature.<\/p>\n

NIC teaming feature reached its maturity in\u00a0Server 2012 R2\u00a0and there are (almost) no major changes in this department in Server 2016, yet if you just starting out with a practical use of NIC teaming on prepping for any related Microsoft exam you may find it useful to review this feature thoroughly.<\/p>\n

Link Teaming was first introduced as OOB feature in Windows Server 2012 with intent to add simple, affordable traffic reliability and load balancing for server workloads. First-hand explanations of pros of this feature by Don Stanwyck, who was the program manager of the NIC teaming feature back then can be found\u00a0here. But long story short, this feature gained special importance because of an arrival of virtualization and high-density workloads: knowing how many services can be run inside of multiple VMs hosted by\u00a0Hyper-V\u00a0host you just cannot afford connectivity loss which impacts all of them. This is why we got NIC teaming: to safeguard against the range of failures from plain accidental network cable disconnect to NIC or switch failures. The same workflow density pushes for increased bandwidth too.<\/p>\n

In a nutshell, Windows Server NIC teaming provides hardware-independent bandwidth aggregation and transparent failover suitable both for physical and virtualized servers. Before Server 2012 you had to rely on hardware\/driver based NIC teaming which obliged you to buy NICs from the same vendor and rely on third party software to make this magic happen. This approach had some major shortcomings, e.g.: you were not able to mix NICs from different vendors in the team, and each vendor has its own approach to management of teaming and such implementations also lacked remote management features \u2013 basically it was not simple enough. Once Windows Server NIC teaming was introduced hardware specific teaming solutions fell out of common use as it no longer makes sense for hardware vendors reinvent the wheel\/offer functionality which is better handled by OOB Windows feature which simply supports any WHQL certified Ethernet NIC.<\/p>\n

\"Windows<\/p>\n

Like I said earlier,\u00a0Windows Server 2016\u00a0have not introduced any major changes to NIC Teaming except for\u00a0Switch Embedded Teaming<\/strong>\u00a0which is positioned to be the future way for teaming in Windows. Switch Embedded Teaming or SET is an alternative NIC Teaming solution that you can use in environments that include Hyper-V and the Software Defined Networking (SDN) stack in Windows Server 2016. SET integrates some NIC Teaming functionality into the Hyper-V Virtual Switch.<\/p>\n

On the LBFO teaming side Server 2016 added ability to change LACP timer between a slow and fast one \u2013 which may be important for those who use Cisco switches (there seems to be an\u00a0update\u00a0allowing you to do the same in Server 2012 R2).<\/p>\n

Gains and benefits of Windows Server NIC teaming are somewhat obvious, but what can give you a hard time (especially if you in for some Microsoft exams) is attempt to wrap your head around all possible NIC teaming modes and their combinations. So let\u2019s see if we can sort out all these teaming modes which naturally can be then configured both via GUI and PowerShell.<\/p>\n

Let\u2019s start with teaming modes as it is first step\/decision to make when configuring NIC teaming. There are three teaming modes to choose from: Switch Independent and two Switch Dependent modes \u2013 LACP and static.<\/p>\n

Switch Independent mode means we don\u2019t need to configure anything on the switch and everything is handled by\u00a0Windows Server. You can attach your NICs to different switches in this mode. In this mode all outbound traffic will be load balanced across the physical NICs in the team (exactly how will depend on load balancing mode),\u00a0but incoming traffic won\u2019t be load balanced as in this case switches are unaware about NICs team\u00a0<\/strong>(this is important distinction which sometimes takes a while to spot especially if you frame your question to Google as something like \u201cLACP VS switch independent performance\u201d or something along these lines).<\/p>\n

Switch dependent modes<\/strong>\u00a0require configuring a switch to make it aware of NICs team and NICs have to be connected to the same switch. Once again, quoting\u00a0official documentation: \u201cSwitch dependent teaming requires that all team members are connected to the same physical switch or a multi-chassis switch that shares a switch ID among the multiple chassis.\u201d<\/p>\n

There are a lot of switches allowing you to try this at home, for example, I have quite affordable yet good D-Link DGS-1100-18 switch from\u00a0DGS-1100 Series\u00a0of their Gigabit Smart Switches. This switch has support for 802.3ad Link Aggregation supporting up to 9 groups per device and 8 ports per group and costs around 100 EUR at this point in time.<\/p>\n

Static teaming<\/strong>\u00a0mode requires us to configure the individual switch ports and connect cables to specific switch ports and this is why it is called static configuration: we assign static ports here and if you connect a cable to different port you\u2019ll break your team.<\/p>\n

LACP<\/strong>\u00a0stands for Link Aggregation Control Protocol and essentially it is the more dynamic version of switch dependent teaming meaning that with if you configure the switch rather than individual ports. Onc the switch is configured it becomes aware about your network team and handles dynamic negotiation of the ports.<\/p>\n

In both of switch dependent teaming modes your switches aware about NICs team and hence can load balance incoming\u00a0network\u00a0traffic.<\/p>\n

To control how load distribution handled we have a range of load balancing modes (you can think about them as \u201cload balancing algorithms\u201d) which includes:\u00a0address hash<\/strong>,\u00a0Hyper-V port<\/strong>\u00a0and\u00a0Dynamic mode<\/strong>\u00a0which was first introduced in Server 2012 R2.<\/p>\n

Address hash<\/strong>\u00a0mode uses attributes of network traffic (IP address, port and MAC address) to determine to which specific NIC traffic should be sent.<\/p>\n

Hyper-V port<\/strong>\u00a0load balancing ties a VM to specific NIC in the team, which may work well for Hyper-V host with numerous VMs on it so that you distribute their NIC traffic across multiple NICs in your team but if you have just a few VMs this may not be your best choice as it leads to underutilization of NICs within the team.<\/p>\n

Dynamic<\/strong>\u00a0is default option introduced in\u00a0Server 2012 R2\u00a0which is recommended by Microsoft and gives you advantages of both previously mentioned algorithms: it uses address hashing for outbound and Hyper-V port balancing for inbound with additional logic built into it to rebalance in case of failures\/traffic breaks within the team.<\/p>\n

So now we covered things you supposed to know to make informed NIC teaming configuration decisions or take Microsoft exams, let\u2019s have a look at practical side of configuring this.<\/p>\n

GUI way to manage NIC teams available through Server Manager \u2013 you just click on Disabled link for NIC teaming to start with configuration process:<\/p>\n

\"Server<\/p>\n

This will get you into NIC teaming console where things are straightforward and easy (providing you read the first half of the article:<\/p>\n

\"NIC<\/p>\n

In case you are doing this VM you may notice that your choices in Additional properties of New team dialog may be limited to switch independent mode and Address Hash distribution mode, so that two first drop downs are greyed out\/inactive \u2013 this simply means that we have to review what\u2019s supported and required when it comes to NIC teams inside VMs. From supportability point of view, only two member NIC teams are supported by Microsoft, and NICs participating in the team have to be connected to two different\u00a0external<\/u><\/strong>\u00a0Virtual Switches\u00a0(which means different physical adapter). And with all these requirements met inside VMs NIC Teams must have their Teaming mode configured as Switch Independent and Load Balancing mode for the NIC Team in a VM must be configured with the Address Hash distribution mode.<\/p>\n

After looking at these limitations it is tempting to say that it is better to go for configuring NIC teaming on Hyper-V host itself and just don\u2019t use it inside VM. But I bet there may be the use case for doing teaming inside of VM \u2013 just can\u2019t think of anything right now (if you do \u2013 just let me know in comments to this blog post).<\/p>\n

In case you want to manage NET teaming via PowerShell you can get all required information in\u00a0NetLbfo Module documentation on TechNet, or just issue\u00a0Get-Command *NETLbfo*<\/strong>\u00a0and further on leverage\u00a0Get-Help\u00a0<\/strong>as necessary:<\/p>\n

\"managing<\/p>\n

I think this blog post provided enough information to get you started with NIC teaming especially if you have not read anything on it just yet.<\/p>\n","protected":false},"excerpt":{"rendered":"

NIC teaming is not something we got with Windows Server 2016 but I just find it interesting to review this functionality as we have it in the current iteration of Windows Server, as usual, touching a bit on basics and history of this feature. NIC teaming feature reached its maturity in\u00a0Server 2012 R2\u00a0and there are […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[63],"tags":[],"class_list":["post-2424","post","type-post","status-publish","format-standard","hentry","category-server-2016-2016"],"_links":{"self":[{"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/posts\/2424","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2424"}],"version-history":[{"count":2,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/posts\/2424\/revisions"}],"predecessor-version":[{"id":2426,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=\/wp\/v2\/posts\/2424\/revisions\/2426"}],"wp:attachment":[{"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2424"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2424"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/microsoftgeek.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2424"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}