Specific uses of 'Route based on source MAC hash' load balancing policy

[ianlancaster]

As we all know, there are four policies for configuring NIC Teaming Load Balancing:

-Route based on the originating port ID

-Route based on source MAC hash

-Route based on ip hash

-Use explicit failover order

Where Virtual Machines are configured each with a single virtual Ethernet Adapter, load balancing with 'Route based on the originating port ID' and

'Route based on source MAC hash' work identically.

Where Virtual Machines are configured with multiple virtual Ethernet Adapters, 'Route based on source MAC hash' may result in a particular VMs virtual Ethernet Adaters being bound to one physical vmnic Ethernet Adapter.

I understand how each option works very well but I have a very specific question:

Are there any circumstances where you must use or there is an advantage in using 'Route based on source MAC hash'?

[weinstein5]

Welcome to the Forums - not really the source mac based option, as I understand it, remained because it was a carryover from ESX 2-

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

[VMmatty]

The only load balancing policy that actually load balances across multiple NICs is route based on IP hash. The other two policies (port ID and MAC hash) will pin vNICs to pNICs but won't actually send traffic out different pNICs once the VM is booted. That means that high network utilization won't necessarily be balanced across physical NICs once your VMs are powered on.

To your actual question - I can't think of a reason why you would use MAC hash over either port ID or IP hash. In general I prefer IP hash when possible or port ID in all other cases.

[admin]

Hi,

Route based on source MAC hash

================================

This is actually pretty similar to Port based on the surface. The way this works is when a frame from a vNic comes into the vSwitch the vSwitch reads the source MAC in the frame, hashes it, checks the hash to uplink table for which uplink to use, then flicks the frames out through the selected uplink. AFAIK it distributes the source MACs inround robin fashion - but would love to find clarification on this (beyond the scope of the exam or pretty much anything though.

So what we see is that generally a single vNic will only ever use a single uplink, as the source MAC does not change. So it should also work across redundant pSwitches. Not really any different than Port Based - right? Typically yes, it is normally functionally the same, except it incurs the overhead of having to hash every source MAC and do a lookup to work out which uplink to use. Not a big overhead - but an overhead none the less. I generally would never use this as there is a cost to get the same end result as Port Based. The exception to this rule is where you have vNics sending frames with DIFFERENT srv MACs...

OK - in this example we have 2 vms each only with a single vNic.

vm1 sends some frames out. As we saw, when they hit the vSwitch it hashes the Src Mac, and does a lookup and finds it is going to use vmnic0. Now as vm1 is not spoofing frames (Forged Transmits) every frame has the same MAC so every frame has the same hash value and so every frame goes through the same uplink.

vm2 (aka mr spoofy) DOES spoof frames, so when it sends a frame from its vNic with Src MAC 00:50:56:ac:41:54 it goes through vmnic1, and when it sends a frame(through the same vNic) with Src Mac 00:a0:d1:98:3c:86 the switch hashes this, gets a different hash and so uses a different uplink.

As we saw when we talked about the L2 Security, this is a pretty specific use case - so in the vast majority of cases this will not be the case for your vms

if you found my answer to be useful, feel free to mark it as Helpful or Correct.