Monday 21 September 2015

The use case of Route based on source MAC hash load balancing

It is a big pleasure to work with experienced clients and there is always something to learn from them.

We all know main load balancing options -  based on source port, source mac, IP hash. etc.
Very often people stick with load balancing bases on source port just because it provides sufficient distribution of the traffic across all physical NICs assigned to the port group and doesn't require any configuration on the physical switch.

What I know about source mac address load balancing does absolutely the same, but uses extra CPU cycles to compute the MAC address hash. So there was no point in using it.

However, as I have learnt today, there is significant difference in load balancing behaviour between two methods mentioned above when using VM with more than one virtual NIC.

So, when the source port load balancing is used the ESXi switch will use the port ID of the first virtual NIC of the VM to identify the uplink to use and the same port ID (and hence the same uplink) will be applied to the traffic sent/received by all other virtual NICs of that VM.

However, with source MAC address load balancing the uplink will be selected using the MAC address of each of VM's virtual NICs.

That's not very common use case, but it is still good to learn the use case of the feature nobody paid much attention.

PS  I haven't yet tested myself if this is true, but I definitely will once I get access to my home lab

2 comments:

  1. Route based on the originating virtual switch port ID is based on the PORT-ID. If you create a VM with two vnics, it will be attached to two different PORT-ID (eth0 to 33554439 and eth1 to 33554440). My expectation with two uplinks (vmnic0/1 are in active mode) is, the Algorithm should bind eth0 to vmnic0 and eth1 to vmnic1, but definitely not the two vnics to the same uplink. Are you agree?
    Source Mac should have the same behavior with extra CPU cycles to compute the MAC address hash.

    ReplyDelete
  2. I thoroughly enjoyed this blog thanks for sharing

    ReplyDelete