Etherchannel Load Balancing issues

Unanswered Question
Aug 31st, 2009

Hi Friends,

i am not clear that, how can the load balancing method in etherchannel such as: src-ip|dst-ip|src-mac|dst-mac|src-prt|dst-prt be the better option.. bcoz without even this explicit options.. the normal loadbalancing i.e, per packet per physical link in etherchannel would work effeciently than these option (which i feel) I would be thankful if u convince me with this topic as early as possible.

Thank u


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Peter Paluch Mon, 08/31/2009 - 08:15

Hello Prado,

The round-robin load balancing, while very attractive at first sight, is not implemented on Cisco switches. I am not quite sure what were all the reasons of Cisco to omit this mode but I am aware of one particular problem: If you submit frames within a single conversation (say, a TCP or UDP stream) through various links in a round-robin fashion then the frames could get delayed differently and may reach the destination reordered - not in their original order. TCP does not like that - while it can recover, it also reacts with closing the window and slowing down the transfer. The UDP does not see the reordering by itself (it has no sequence numbers) but the application using the UDP might get either confused or must do extra work to sort the packets back to their original order.

So the one problem, and probably one of the most important, is the risk of frames within a same flow getting reordered. With the per-address load balancing, a flow of frames within a particular destination always uses a single link, thereby avoiding the reordering problem.

Best regards,


Francois Tallet Mon, 08/31/2009 - 08:43

Yes, that the reason. Ethernet guarantees in order delivery of a particular flow. If you provided two different paths for a given flow, you would lose this property. Peter just gave an example of UDP, but considering we're talking about a property of ethernet, many ohter protocols would potentially be impacted.



Joseph W. Doherty Mon, 08/31/2009 - 09:15

"TCP does not like that - while it can recover, it also reacts with closing the window and slowing down the transfer."

Just to clarify Peter's comment, TCP doesn't always have a serious issue with packet resequencing. Actual impact depends on TCP variant and how "badly" received packets are resequenced. Worst case, sender slows transfer rate (as noted by Peter) and successfully already received packets are transmitted again. Best case, although generally not serious, sender and receiver buffers are held longer than truly necessary (necessary because of resequenced packets) and extra ACKs transmitted. I.e., although IP doesn't guarantee packet sequencing, resequencing packets is something to needlessly avoid.

If multiple links are to be combined between devices, when possible, some other technologies (e.g. MLPPP, IMA, etc.) can guarantee packet sequencing is maintained.

Peter Paluch Mon, 08/31/2009 - 09:30

Francois, Joseph,

Thanks very much to both of you for extending my answer!

Best regards,


prado2010 Mon, 08/31/2009 - 20:20

Hi Peter, Francois and Joseph,

Thank u very much for ur valuable responses.



prado2010 Tue, 09/01/2009 - 05:39

Hi Friends,

Could you please explain how exactly the etherchannel load balancing work with src-ip|dst-ip|src-mac|dst-mac|src-prt|dst-prt.

Thank u


Peter Paluch Tue, 09/01/2009 - 13:27

Hello Prado,

I suggest reading this document first:

It also says that the algorithm to achieve load balancing is proprietary. However, just for illustration, you can imagine that if you are using just a single value for the load balancing (source or destination MAC, IP or port), then the output port can be calculated as VALUE MOD N where N is the count of interfaces in the Etherchannel and VALUE is the respective value from the frame being transmitted. If you use multiple values, for example, source and destination MAC, then the output port for a particular frame can be calculated as (SRCMAC XOR DSTMAC) MOD N where N is again the count of interfaces in the Etherchannel.

Note again that this is just an illustration how it could be implemented, however, Cisco might use any other algorithm to map the values to output ports.

Best regards,


prado2010 Wed, 09/02/2009 - 01:55

Hi Peter,

Thanks a lot for ur information, the working of etherchannel load balancing methods are realy easy to understand, provided one must be comfortable in hexadecimal to decimal conversion. Any ways i got to know the working of load balancing methods.

Best Regards


emetesh Fri, 09/11/2009 - 09:39

Hi folks...a question if this thread is active...connecting 2 classrooms with 2 wireless links. Using routers we are sending data from class A down link A to class B and class B is using the other link to send to class A. Could Etherchannel be a better solution? thx

Joseph W. Doherty Fri, 09/11/2009 - 10:16

If the links are routed, CEF equal cost load balancing might be better.


BTW, for best results, you might post your question as its own.


This Discussion