Windows Server 2012 NIC Teaming Part 5 – Configuration Matrix

Windows Server 2012 NIC Teaming Part 1 – Back To Basics

Windows Server 2012 NIC Teaming Part 2 – What’s What?

Windows Server 2012 NIC Teaming Part 3 – Switch Connection Modes

Windows Server 2012 NIC Teaming Part 4 – Load Distribution

In the last two posts I’ve discussed how to configure the switch connection modes and the traffic distribution algorithms of a NIC team to give you LBFO.  What’s the right overall design?

I said it before, but considering the length of this topic, it’s probably gotten lost: the configuration of the switch connection modes will depend primarily on what switch design you go with.  Very often, you have to use what is already there.  But in a greenfield implementation, you’ll have a choice.

I keep the choice of traffic distribution algorithm pretty simple.  I ask this question – Is the NIC team used for a Hyper-V external virtual switch?

• Yes: use Hyper-V Switch Port
• No: use Address Hashing

It’s not always that simple, but it probably will be for 99.99% of implementations.

That means there are 4 basic configurations of NIC team, excluding things like hot standby and additional team interfaces, and without using PowerShell to set specific Address Hash algorithms:

• Switch Independent with Hyper-V Switch Port
• Switch Independent with Address Hash
• Switch Dependent with Hyper-V Switch Port
• Switch Dependent with Address Hash

Each configuration behaves differently, and each one has best-use cases:

Switch Independent with Hyper-V Switch Port

Every team member in the team is used to send packets.  Remember that each virtual NIC (or port on the virtual switch) is limited to a single team member (and its bandwidth) for inbound and outbound traffic.  Inbound and outbound traffic goes through the same NIC, making it perfect for DVMQ.

Microsoft says that this configuration is best used when:

a) The number of VMs well-exceeds the number of team members; and

b) A restriction of a VM to not greater than one NIC’s bandwidth is acceptable

Don’t get all caught up in a virtual NIC being limited to a single NIC; we consolidated using virtualization because we were underutilizing physical server resources anyway!

Switch Independent with Address Hash

This NIC team configuration will send data out across all team members.  The packets are load balanced across the team members using address hashing based on the destination details of each packet.

Inbound traffic to this team is limited to a single team member.  That is because the IP addresses being used by the team interfaces or virtual NICs can only register with one MAC address on the physical network, and the physical network will send traffic to those IP addresses via those MAC addresses (the team member with that MAC).

Microsoft says that this configuration is best used when:

a) Native mode teaming where switch diversity is a concern;

b) Active/Standby mode teams; and

c) Teaming in a VM (I’ll be coming to this in a future post)

Switch Dependent with Hyper-V Switch Port

Once again, outbound packets are sent across all NICs, with each virtual NIC (or virtual switch port) being associated and restricted to a single team member.

“Switch dependent” should tell you what’s going to happen to inbound traffic: it’s up to the physical switch(es) that the team is connected with to determine how to best send traffic into the team.  We expect the switch to distribute traffic across the entire team.

Microsoft says that this configuration is best used when:

a) Hyper-V teaming when VMs on the switch well-exceed the number of team members and

b) When policy calls for switch dependent (e.g., LACP) teams and

a) When the restriction of a VM to not greater than one NIC’s bandwidth is acceptable.

Switch Dependent with Address Hash

It’s Address Hash so each outbound packet is inspected and routed to the physical network via the resulting physical NIC (team member) that is picked by the hashing algorithm.

Once again, inbound traffic distribution is determined by the physical switch(es) that the team members are connected to.  There is no affinity like with Hyper-V Switch Port.

Microsoft says that this configuration is best used when:

a) Native teaming for maximum performance and switch diversity is not required; or

b) Teaming under the Hyper-V switch when an individual VM needs to be able to transmit at rates in excess of what one team member can deliver.

This information has been brought to you by Windows Server 2012 Hyper-V Installation and Configuration Guide (available on pre-order on Amazon) where you’ll find lots of PowerShell like in this script:

Technorati Tags: Windows Server 2012,Hyper-V,Networking