venerdì 11 ottobre 2013

VMware: MAC hash based LB

In this series of post regarding Load Balancing in VMware vSwitches it's now time to spend a few words on MAC hash based load balancing.

This load balancing algorithm chooses which vmnic utilize for sending traffic based on a calculation performed on source VM MAC address rather than destination IP address of a TCP/UDP conversation like load balancing based on IP hash or a Round Robin vmnic assignation like route based on originating port ID. Nevertheless this has some pros and cons. Positive it's undoubtly the fact that no configuration changes are needed at physical switch level but on negative side it is a rather deterministic and static vmnic assignation.

Route based on source MAC hash is set at vSwitch or PortGroup level.

Quoting VMware Virtual Networking Concepts guide:

Route based on source MAC hash choose an uplink based on a hash of the source Ethernet MAC address.
When you use this setting, traffic from a given virtual Ethernet adapter is consistently sent to the same physical adapter unless there is a failover to another adapter in the NIC team.Replies are received on the same physical adapter as the physical switch learns the port association. This setting provides an even distribution of traffic if the number of virtual Ethernet adapters is greater than the number of physical adapters.

Every VM's virtual network adapter has a MAC address assigned to it. This is assigned by default by VMware during virtual network adapter creation and this process has a regular pattern. First 24bits are 00:50:56. They represents MAC OUI (Organizationally Unique Identifiers) and are common for all VMware's created virtual network adapters.

The MAC address range observed by VMware is from 00:50:56:00:00:00 to 00:50:56:3F:FF:FF and MAC Address generation algorithm guarantees unique addresses within a VM and attempts to provide unique MAC addresses across VMs.

As referred by MAC Address Generation article last MAC 24 bits (3 octets) are assigned in this way:

SMBIOS UUID for the physical ESXi machine, and a hash based on the name of the entity that the MAC address is being generated for.

You can also manually specify a MAC address for your VM despite I suggest you to let VMware decide which MAC address assign to your virtual network adapter to prevent MAC address duplications across VMs.

Let's now see how this actually works:

vmnic used = HEX(VM virtual network adapter MAC Address) mod (Number of vmnics)


VM vNIC MAC Address is the MAC address of the VM's virtual network adapter assigned to a certain VM.

Number of vmnics: the number of vmnics configured for portgroup on which VM resides.

Now let's examine a sample scenario:

Two VMs with two virtual network adapters on one ESXi host, each with following MAC address (automatically assigned by vSphere during creation):



One VM with two virtual network adapters on another ESXi host.


VMs MAC address is not changed by vMotion. If we vMotion or cold migrate Test3 from ESXi2 to ESXi1 MAC addresses are still the same.

Let's check which vmnic will each VM use:


00:50:56:a3:a5:e6 mod(4) -> 2 -> vmnic2
00:50:56:a3:4a:a2 mod(4) -> 2 -> vmnic2


00:50:56:a3:d6:d3 mod(4) -> 3 -> vmnic3
00:50:56:a3:17:4e mod(4) -> 2 -> vmnic2


00:50:56:a3:c6:fb mod(4) -> 3 -> vmnic3
00:50:56:a3:84:9e mod(4) -> 2 -> vmnic2

As you can see results from Test2 and Test3 confirm that every VM's virtual network adapter use a different vmnic for communicating outside vSwitch except Test1 which uses vmnic2 for both its virtual adapters.

Since all these MAC addresses were generated by VMware itself during VM network adapter creation this implies that MAC address generation process is not aware of load balancing technique used at vSwitch or PortGroup level so this could potentially affect in a negative way VM to vmnic mapping. If MAC hash LB is used it's advisable check to what vmnic each VM is assigned to.

This can be simply done by using esxtop (then press "n" for network screen)  in ESXi console.
In my case this is the result showing the MAC address "misconfiguration" for Test1 VM.

That's all!!

1 commento: