Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
Is the requirement of 2n number of ports for EtherChannel a critical requirement or just a recommendation to ensure, perhaps, an even load balancing?
Particularly, if we setup an EtherChannel group with 8 ports but one of them went down. Would the remaining 7 ports still be functional but with uneven load balance, or would 3 ports be forced into standalone to ensure a power of two group?
Is it dealt with similarly for both PAgP and LACP?
The power of 2 requirement varies per vendor/hardware/software. Cisco had (has) a pretty bad stigma against them with a lot of the earlier catalyst switches capable of 10G. The problem comes with how the software hashes (or "balances") data over the multiple ports in the port-channel (this is agnostic of PAgP or LACP).
This post does an excellent job of simplifying the problem in finer detail. This is less relevant today with hardware/software improvements, but again, it varies - so just check your hardware requirements and make sure you're not buying older hardware that falls victim to this problem.
http://www.packetmischief.ca/2012/07/24/doing-etherchannel-over-3-5-6-and-7-link-bundles/
Is the requirement of 2n number of ports for EtherChannel a critical requirement or just a recommendation to ensure, perhaps, an even load balancing?
Most vendors don't have such a requirement. This is a convention often discussed based on the limitations of a three bit hash when load balancing. I personally disagree with this stance, but I will get to that after answering your questions.
Particularly, if we setup an EtherChannel group with 8 ports but one of them went down. Would the remaining 7 ports still be functional but with uneven load balance, or would 3 ports be forced into standalone to ensure a power of two group?
Typically, if you have 8 ports in a link aggregation group and one goes down, the other seven will remain active. Yes, the load will be a bit unbalanced in a sense, but again, I will get to that in a minute.
Is it dealt with similarly for both PAgP and LACP?
Yes, and the same with a static LAG group.
Now to my view point as to why I don't personally hold to the power of two "rule of thumb" when it comes to link aggregation.
To start, you really need to understand that no link aggregation ever balances link utilization across the LAG. Clearly there are differences in the load balancing method chosen, and some are better than others (although no single one is best in every circumstance).
The load balancing method does not balance the traffic, rather it balances what you can consider "flows." Based on the platform, you have options to use source and/or destination values which may include MAC address, IP addresses, port numbers, etc. These values are then hashed to determine which link is selected for that particular flow. Frames with the same set of values will always receive the same hash and be assigned to the same link.
Not all flows are equal and this means that it is not possible to balance the link utilization by these means. Not to take away from the value of LAG, as it often does do a pretty good job of balancing the utilization as well, but you need to understand the limitations.
It is entirely possible for one or more of these flows to utilize their entire link in the LAG and starve other flows assigned to the same link. Meanwhile the other links are under utilized.
When most people looks at charts like those in this blog post or this Cisco document, they see that the traffic is unbalanced. In the sense that some links receive more flows than others, this is true.
My view of these tables is a little different. First, even with the unbalanced distribution, as you add links there is never any point where the percentage of assigned flows on a link increases; rather in the majority of cases the percentage decreases. Put another way, at no time is there less opportunity for a flow to have access to bandwidth, and in many cases, it will have more opportunity.
Second, if I were to look at this chart to decide between two or three links in an LAG, in my mind I see this as follows:
Finally, consider what happens if you lose a link in the LAG. Given two links to start, this would reduce my LAG to one link. If I start with three, I will still have two left.
Sure, balanced flows appeal to the obsessive compulsive parts of my personality, but this still doesn't reflect balanced traffic. Aside from that, more links is better any way I look at it.
What I can recall (correct me):
Etherchannel does not load balance per say, it is load distribution. An EC with an odd number of links will not distribute the load between the links evenly - the lower numbered links receive more traffic. Traffic will continue to flow if the physical links are broken.
Traffic is balanced by destination mac address (by default). Depending on your topology, this may result in undesirable traffic patterns:
If you have a mail server on one switch with an EC between switches, all the workstations on the switch on the other side of the Etherchannel will use the same link to reach the mail server....if the majority of your traffic is to the mail server, this provides no load balancing and only a single link in the Etherchannel is used for the mail server.
This may help: https://supportforums.cisco.com/blog/150511/how-do-etherchannel-hash-algorithm-works-and-load-distribution-happen
