Is the requirement of 2n number of ports for EtherChannel a critical
requirement or just a recommendation to ensure, perhaps, an even load
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:
- Two links - a single link being fully utilized will affect 50% of the traffic flows leaving 50% unaffected
- Three links - a single link being fully utilized will affect at most 37.5% of the traffic flows leaving 62.5% unaffected; possibly as little as 25% leaving 75% unaffected
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.