It is important to set the right load balancing policy on your standard or distributed vSwitch. In this article I will talk about how each policy work and give my general recommendation.
In vSphere we have the following policies to choose from:
- Route based on originating virtual port ID
- Route based on IP hash
- Route based on source MAC hash
- Use Explicit failover order
- Route based on physical NIC load (Distributed Switch only)
The originating virtual port ID is the default policy and there is a good reason for that. This policy does not require any special physical switch configuration. In fact you can use all policies except the one based on IP hash without configuring your physical switches with cisco etherchannels or hp trunks. The IP hash policy differs in the way that it let a virtual machine spread its traffic over two or more different vmnic’s (physical network adapter). Because of this the MAC address of the virtual machine will appear on multiple physical switch ports simultaneously. This is why it is required to use ether-channel or trunk the links.
Lets take an example. We have a virtual switch with a port group. We have 4 virtual machines connected to the port group and 3 physical NICS connected to the virtual switch.
Route based on originating virtual port ID works kind of like round robin. VM-A will use vmnic1, VM-B will use vmnic-2, VM-C will use vmnic-3 and VM-D will use vmnic1. The virtual machines are just balanced over the physical available NICS. The virtual machines will have its network running on the designated physical NIC and only that NIC. Of course if we have a failure it will fail over to a different vmnic.
The good about this configuration is that it is easy to configure. It requires not special physical switch configuration. The bad is that VM-A and VM-D how are both utilizing the same vmnic could be the two most network intensive virtual machines and they compete for bandwidth while VM-B and VM-C does nothing on their respective vmnics.
Route based on IP hash requires physical switch configuration. (Ether-channel). In this configuration the traffic flows according to the source IP and destination IP. In this case if VM-A is communicating with three different IP’s (clients, other servers etc.) the traffic can use all available vmnic’s. If the VM-B is only communicating with one destination the traffic will not be shared.
Route based on phyiscal NIC load is a newer addition. It quite similar to virtual port ID. But with the addition that it actually looks at the physical NIC load! This means that if VM-A and VM-B both are using a lot of bandwidth on the same physical NIC one of the will be moved to another! If you are running the originating virtual port ID policy on a distributed switch you should change to physical nic load right away.
There are a lof of information out there on this subject. This was just a brief introduction.
Any use cases for when to use route based on source MAC hash?
I have never been able to find a use case for source MAC hash. I would just ignore it. If anyone have a use case I would love to hear about it.
“Source port ID based” vmnic assignment could change after poweroff/poweron, or after vmotion to and back. Source MAC based wouldn’t change the uplink assignment in those cases. That’s the only potentially positive aspect to “Source MAC based” that I know. I don’t know specific situation where changing vmnic assignment would be unwanted, but there may be examples. You pay with higher overhead.
for, Route based on phyiscal NIC load, do we need any special configurations on phy switch side ?
Super Short & Sweet article 🙂
Nice and very handy info
A possible advantage is if you have another hypervisor running on a VM, with it’s own VMs, source MAC hash could load balance between these nested VMs. Not a common occurence though, I’m sure!