Thanks Jon,

Of all the three methods you metioned, which one is most efficient, IF switch supports all of them.

Also is there any other method to make etherChannel work more efficiently as you are aware of? Thank you.

"which one is most efficient"

the answer is it depends eg.

Lets say most of the traffic traversing the etherchannel is destined for devices within the same vlan. mac-address load-balancing would be perfectly adequate.

Now if most of the traffic traversing the etherchannel was destined for L3 interface for that vlan then dst mac-address would not be a good choice because it would always be the same.

Put simply you need to have an idea of which load-balancing method would give you the most variation so that the etherchannel can utilise all it's individual links.

Jon

You just blowed my bind, thanks.

I have layer 2 etherchannel between Catalyst 4500 VSS in two buildings. The 4500 VSS have server farm VLANs that span both 4500 VSSs. Both VSS will also provide layer 2 MEC to access layer 3560 switches within each building.

I want to implement layer 4 hash on the 4500 VSS (port-channel load-balance src-dst-port) as this appears to be the best choice for load balancing traffic between the servers (better utilisation across the uplinks for high volume of server replication traffic between the buildings for example).

The 3560 access switches support layer 3 hash but NOT layer 4 hash so I will use layer 3 hash for the 3560 switches (port-channel load-balance src-dst-ip)

So basically both ends of the MEC will have different hash algorithms.

Is this a valid and/or supported design or do both ends of the link need to have the same load balancing algorithm?

Hello,

I hope Jon won't mind if I answer your question. I do hope, though, he joins the discussion if he is reading this!

Is this a valid and/or supported design or do both ends of the link need to have the same load balancing algorithm?

The design you are proposing is perfectly valid. Each end of an EtherChannel is free to use its own load balancing mechanism and they may freely differ.

Best regards,

Peter

thank you Peter

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

The design you are proposing is perfectly valid. Each end of an EtherChannel is free to use its own load balancing mechanism and they may freely differ.

Not only can both sides freely differ, (for OP) in some situations you may want them to intentionally differ.  As Jon described, "it depends".

The later hash algorithms that support both src and dest attributes in their hash, generally remove the need to select different algorithms per direction.  The later hash algorithms that include more attributes or "higher in the stack" attributes in their hash, in general, often work better.  Again, though, it depends.  For example, you might have a very active host that is consuming most of your bandwidth, and so you might want to select an algorithm that best "randomizes" its traffic vs. all the other host traffic.

BTW, Etherchannels are also more "efficient" when the number of channels is a power of two.  Some newer devices, such as the sup2t, have expanded their hash divisor, so they are better when dealing with non-powers of 2.

PS:

Given a choice, a single path with more bandwidth is almost always better.  First a single flow can take advantage of the extra bandwidth.  Second, Etherchannel doesn't monitor link loading, so, for example, two flows can be directed to the same link while the adjacent link is unused.

Hi Joseph,

A very insightful response - as always. Thank you!

Best regards,

Peter