jskfan
asked on
Understanding Etherchannel Load Balancing
I have done some reading in order to understand Etherchannel Load balancing but to no avail.
If someone can explain it in a simple and clear way, it will be very helpful
Thank you
If someone can explain it in a simple and clear way, it will be very helpful
Thank you
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
In that case you can change default load balance method
List of all methods :
src-ip source IP
dst-ip destination IP
src-dst-ip source and destination IP (XOR) --- (DEFAULT METHOD)
src-mac source MAC
dst-mac destination MAC
src-dst-mac source and destination MAC (XOR)
src-port source port
dst-port destination port
src-dst-port source and destination port (XOR)
You can change load balance method, and adopt it to scenario, to source and destination port (bold) and you can get load balance in scenario you created (scenarios that include port (probably not destination port) will give you load balancing in this scenario, better or worse). And just to mention, not all switches support all methods.
Destination port is most likely always the same, but source post, and combination of source and destination port is most likely to give equally distributed bandwidth per port.
List of all methods :
src-ip source IP
dst-ip destination IP
src-dst-ip source and destination IP (XOR) --- (DEFAULT METHOD)
src-mac source MAC
dst-mac destination MAC
src-dst-mac source and destination MAC (XOR)
src-port source port
dst-port destination port
src-dst-port source and destination port (XOR)
You can change load balance method, and adopt it to scenario, to source and destination port (bold) and you can get load balance in scenario you created (scenarios that include port (probably not destination port) will give you load balancing in this scenario, better or worse). And just to mention, not all switches support all methods.
Destination port is most likely always the same, but source post, and combination of source and destination port is most likely to give equally distributed bandwidth per port.
if Server1 sends 2GB of Data to Server2 , then only one link of the Eight in SW1 will receive the Data, and will forward the first 1GB to SW2 and the other 1 GB will be resent next time on the same link.That is correct. This assumes that the traffic is a single flow. Which means between the same two MAC, IP and L4 ports (i.e. an FTP transfer). One of the most common misconceptions about etherchannel is that it will increase the bandwidth for traffic between two devices.
Now in your example, if the traffic between Server1 and Server2 were two separate FTP transfers, then it's possible the second transfer could be sent over a different link. But this is only if the load distribution method used was Source-Dest port number... which isn't supported on all platforms.
ASKER
Why are FTP transfers different than other traffic ?
They aren't. I was using that as an example.
ASKER
I do not mean to stretch the Thread, but there is still gray area..
for instance , if the method use is:
src-dst-port source and destination port (XOR)
Will server1 send first packet to server 2 through Link1, second packet to link2, etc....? (I said link1 then link2, but it can be randomly..)
for instance , if the method use is:
src-dst-port source and destination port (XOR)
Will server1 send first packet to server 2 through Link1, second packet to link2, etc....? (I said link1 then link2, but it can be randomly..)
No. All traffic in a flow will always use the same link.
ASKER
So there is no Load Balancing
Not really. Although it would depend on your definition of "load balancing". I prefer to use "load distribution". :-)
On a two-link etherchannel group it is entirely possible to have 75% of the traffic use one link and 25% use the other. In my mind, that's not "balanced". But it is using the both links which you wouldn't get with spanning-tree unless you got a little creative with per-VLAN STP or MST.
On a two-link etherchannel group it is entirely possible to have 75% of the traffic use one link and 25% use the other. In my mind, that's not "balanced". But it is using the both links which you wouldn't get with spanning-tree unless you got a little creative with per-VLAN STP or MST.
ASKER
The only "Load Distribution" I see is in the scenario where more than one server is sending to server 2
for instance Server1 and Server5 are connected to Switch1 which is (etherchannel linked) to Switch2, and Server2 is connected to Switch 2
That way Server1 might send its traffic through one Link to Server2 and Server5 might send its traffic through a separate link to Server 2
I picture it as highway, a Semi, regardless of how many trailers is hauling will still use only one lane, but other cars can use separate lanes
for instance Server1 and Server5 are connected to Switch1 which is (etherchannel linked) to Switch2, and Server2 is connected to Switch 2
That way Server1 might send its traffic through one Link to Server2 and Server5 might send its traffic through a separate link to Server 2
I picture it as highway, a Semi, regardless of how many trailers is hauling will still use only one lane, but other cars can use separate lanes
The only "Load Distribution" I see is in the scenario where more than one server is sending to server 2That is exactly correct. The more devices (or more precisely, the more flows), the better chance at an even distribution of traffic over the links.
I picture it as highway, a Semi, regardless of how many trailers is hauling will still use only one lane, but other cars can use separate lanesExcellent analogy!
ASKER
But why Cisco bothers coming with a list of methods:
src-ip source IP
dst-ip destination IP
src-dst-ip source and destination IP (XOR) --- (DEFAULT METHOD)
src-mac source MAC
dst-mac destination MAC
src-dst-mac source and destination MAC (XOR)
src-port source port
dst-port destination port
src-dst-port source and destination port (XOR)
src-ip source IP
dst-ip destination IP
src-dst-ip source and destination IP (XOR) --- (DEFAULT METHOD)
src-mac source MAC
dst-mac destination MAC
src-dst-mac source and destination MAC (XOR)
src-port source port
dst-port destination port
src-dst-port source and destination port (XOR)
Not sure I understand your question.
This is not "Cisco". Many vendors support Etherchannel (although they may have a different name for it. The choices are to allow the network admin to select a distribution method which offers the best opportunity for an equal distribution of the traffic. And destination-source IP is only the default on some platforms.
This is not "Cisco". Many vendors support Etherchannel (although they may have a different name for it. The choices are to allow the network admin to select a distribution method which offers the best opportunity for an equal distribution of the traffic. And destination-source IP is only the default on some platforms.
ASKER
<<The choices are to allow the network admin to select a distribution method which offers the best opportunity for an equal distribution of the traffic>>
Those choices (Load distribution)will still have effect only when multiple servers are sending to one or multiple servers...
if one server is sending then those choices will have no effects....I mean still only one link will be used
Those choices (Load distribution)will still have effect only when multiple servers are sending to one or multiple servers...
if one server is sending then those choices will have no effects....I mean still only one link will be used
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Excellent!!
ASKER
For instance, let 's say we have 8GB Etherchannel (8 *1GB physical interfaces)
if Server1 sends 2GB of Data to Server2 , then only one link of the Eight in SW1 will receive the Data, and will forward the first 1GB to SW2 and the other 1 GB will be resent next time on the same link.