Vswitch or Port Group NIC Teaming Policy

[phowarth]

Can someone give a clear explanation of the NIC Teaming Load Balancing Policies? What each does and why you would choose from the degault which is " Route based on the originating virtual port ID".

Here are the four choices that show up in the drop down list box.

Route based on the originating virtual port ID

Route based on IP Hash

Route based on source MAC Hash

Use explicit failover order

[Texiwill · Accepted solution]

Hello,

Route based on the originating virtual port ID

Each VM has a vSwitch port ID associated with it. Load is balanced based on the port ID and nothing else. Useful as it encompasses all protocols, etc.

Route based on IP Hash

If the packet being sent is a TCP/IP packet this works great and is balanced based on the IP Hash, however if the packet is not TCP/IP the load is balanced based on a round robin approach. This is packet level not VM level.

Route based on source MAC Hash

The MAC address of the VM is used as the basis for load balancing.

Port ID is the default because it will always work. MAC has issues if you change the MAC mid stream, things will behave differently. And IP Hash only works for TCP/IP based protocols. Not everything is TCP/IP. UDP, GRE, etc.

Use explicit failover order

Not load balancing but failover.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

SearchVMware Blog: http://itknowledgeexchange.techtarget.com/virtualization-pro/

Blue Gears Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

[phowarth]

Thanks Ed. I noticed in the Context Help that Failover Order indicates: "Use explicit failover order - Always use the highest order uplink from the list of Active adapters that passes failover detection criteria." Isn't this saying 'traffic will all flow over the nic listed as the first nic in the failover order" ? This would mean that all traffic flows over that nic until it fails a link status and then all traffic will flow over the second nic in the failover order. Not really load balancing and making use of both nics right?





Pete

</span>

[Texiwill]

Hello,

Correct.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

SearchVMware Blog: http://itknowledgeexchange.techtarget.com/virtualization-pro/

Blue Gears Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

[ucsc-vmteam]

Route based on IP Hash

If the packet being sent is a TCP/IP packet this works great and is balanced based on the IP Hash, however if the packet is not TCP/IP the load is balanced based on a round robin approach. This is packet level not VM level.

From the documentation, "For non-IP packets, whatever is at those offsets is used to compute the hash." So the uplink is chosen by hashing part of the Ethernet payload and is not round-robin.

Route based on source MAC Hash

The MAC address of the VM is used as the basis for load balancing.

Port ID is the default because it will always work. MAC has issues if you change the MAC mid stream, things will behave differently. And IP Hash only works for TCP/IP based protocols. Not everything is TCP/IP. UDP, GRE, etc.

UDP (type 17), and GRE (type 47), along with TCP (type 6), are all IP protocols. All IP-based protocols are deterministic using IP hash, and behave as well as Port ID load balancing with the added benefit of balancing network load from a single guest, as long as that guest communicates to more than one endpoint.

Traffic that might not be well-behaved with IP hash load balancing is anything with an EtherType other than 0x0800 (IPv4) or possibly 0x86DD (IPv6) including IPX, SNA, Appletalk, ARP. If, for example, IPv6 is not specifically supported, the hash will be the 64-bit network prefix of the source IPv6 address, which is likely to be the same across guests on a given host, and so will fail to distribute such traffic across links.