cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8148
Views
13
Helpful
11
Replies

Does EtherChannel actually increase throughput?

w21froster
Level 1
Level 1

Say you are load balancing across the port members of an EtherChannel based on source MACs. Does it actually use multiple interfaces at the same time? Or does it treat it all as one port and pick an interface to use for each frame? 

2 Accepted Solutions

Accepted Solutions

You mean does it act as though it is a single interface or does it in effect see all the individual interfaces in the port channel ?  

 

My understanding is that if there are multiple flows it can indeed use multiple links at the same time but for a single flow it can only use one of the links. 

 

I have always viewed etherchannel as more about redundancy than throughput to be honest but it does do that as well. 

 

Jon

View solution in original post

The most throughput you can obtain for any one flow is the capacity of any one link.
What Etherchannel might do, if multiple flows are distributed across multiple links, your multi flow overall bandwidth will be greater than one link's capacity.
For example, if you have two flows, one might use link 1 and one might use link 2, then your overall throughput is twice what one single link might offer.
Unfortunately, even just two flows might be hashed to the same link and they your overall throughput, for two links, is the same as if you only had one link (although, as you noted, you have a redundant link in that case).
Since, even with best hashing, Etherchannel does not use link loading to determine link usage, and since flows can hash to the same link, your expected aggregate isn't x times number of links.
For example, start with two flows. First flow hashes to link 1. Second flow has a fifty/fifty chance of hashing to link 1 or 2. So, expected improvement is 150%, not 200%.

View solution in original post

11 Replies 11

Mark Malone
VIP Alumni
VIP Alumni

Hi

You can end up with traffic all on one link using mac lb, you need to test the etherchannel when you create it check the flow of traffic on the individual members with the test etherchannel command , i find best LB is src-dst-port in our envirnoment anyway using equal links like 2 or 4 ,not 3

It definitly doesnt just work link to link like that , you need to check it fully when setup and test it whats working best for you

 

It can also vary on switch to switch how exactly it works

https://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html

 

There is some good docs on this forum written on just the oload balancing

https://supportforums.cisco.com/t5/network-infrastructure-documents/quot-etherchannel-loadbalancing-on-catalyst-switches-quot/ta-p/3107786

https://supportforums.cisco.com/t5/network-infrastructure-documents/how-to-configure-a-giga-etherchannel-with-the-xor-algorithm-on-a/ta-p/3130447

eekman
Level 1
Level 1

"EtherChannel frame distribution uses a Cisco-proprietary hashing algorithm. The algorithm is deterministic; if you use the same addresses and session information, you always hash to the same port in the channel. This method prevents out-of-order packet delivery."

 

"For example, if the traffic on a channel only goes to a single MAC address, use of the destination MAC address results in the choice of the same link in the channel each time. Use of source addresses or IP addresses can result in a better load balance."

 

Quotes from the first link provided by Mark. Thought I put it here, I think it's a key topic that all should know about. I usually go with load balancing by IP since there usually is a default gateway in the network.

"EtherChannel frame distribution uses a Cisco-proprietary hashing algorithm. The algorithm is deterministic; if you use the same addresses and session information, you always hash to the same port in the channel. This method prevents out-of-order packet delivery."

 

So I get that concept. The concept I am talking about is if the port members are all handling frames at the exact same time. (I forgot the term for this.. virtual circuits?) 

Untitled.pngThose calculator things are hosts, lol. Basically the idea that if the switch isn't flooding frames, it can facilitate multiple unicast conversations at the same time. My question is if the switch views the entire EtherChannel bundle as one port, can it hold multiple unicast conversations on it's port members at the same time? Or does it just hash a frame, figure out the corresponding port member, send the frame, rinse and repeat? If the latter is the case, then I can't possibly see how it increases throughput. It would only be useful for redundant links.

You mean does it act as though it is a single interface or does it in effect see all the individual interfaces in the port channel ?  

 

My understanding is that if there are multiple flows it can indeed use multiple links at the same time but for a single flow it can only use one of the links. 

 

I have always viewed etherchannel as more about redundancy than throughput to be honest but it does do that as well. 

 

Jon

"You mean does it act as though it is a single interface or does it in effect see all the individual interfaces in the port channel ? "

Exactly.

"My understanding is that if there safe multiple flows it can make indeed use multiple links at the same time but for a single flow that can only use one of the links. "

That is what I needed to know! Thank you for clarifying. It would be cool to see a NetFlow for an EtherChannel bundle to see if it actually achieves higher throughput.

That is what I needed to know! Thank you for clarifying. It would be cool to see a NetFlow for an EtherChannel bundle to see if it actually achieves higher throughput.

 

Might be able to get you that my core campus is VSS core/dist collapsed  design with etherchannels back to every other access switch there monitored too and i think i have filers still in other regions that are dual link lacp to 6500 cores and being monitored too through netflow that havent been migrated to DC nexus kit yet , im back in office Monday il take a look

Etherchannel works a bit differently under VSS. Traffic on a physical VSS member does not egress on the other VSS member's Etherchannel links, unless there are no Etherchannel links on the local VSS member. (This to avoid using VSL unless that's the only path. This also applies to equal cost routed ports.)

The most throughput you can obtain for any one flow is the capacity of any one link.
What Etherchannel might do, if multiple flows are distributed across multiple links, your multi flow overall bandwidth will be greater than one link's capacity.
For example, if you have two flows, one might use link 1 and one might use link 2, then your overall throughput is twice what one single link might offer.
Unfortunately, even just two flows might be hashed to the same link and they your overall throughput, for two links, is the same as if you only had one link (although, as you noted, you have a redundant link in that case).
Since, even with best hashing, Etherchannel does not use link loading to determine link usage, and since flows can hash to the same link, your expected aggregate isn't x times number of links.
For example, start with two flows. First flow hashes to link 1. Second flow has a fifty/fifty chance of hashing to link 1 or 2. So, expected improvement is 150%, not 200%.

Great explanation! I'm assuming it doesn't use round robin load balancing because if packets arrived out of order it would place the burden on the endpoint processing those packets to assemble them correctly (which could net worse performance).

Round robin is avoided, not so much to avoid additional end-point loading, but because TCP might consider it as packets have been lost and some traffic types will discard out-of-order packets, e.g. VoIP.

Joseph W. Doherty
Hall of Fame
Hall of Fame
"Say you are load balancing across the port members of an EtherChannel based on source MACs. Does it actually use multiple interfaces at the same time?"
It may. It will "hash" a source MAC to a link, and send all those frame to that link. As multiple source MAC might hash to the same link, it's possible even if you have two concurrent flows, both might be directed to the same link.
"Or does it treat it all as one port and pick an interface to use for each frame?"
No, each frame (or packet) will be hashed using the attributes you select, and if they are the same, the frame (or packet) will be directed to the same link. I.e. it doesn't round robin frames (or packets). This to insure all of a flow's frames/packets are not re-sequenced because of multiple links.