2 的幂次要求因供应商/硬件/软件而异。思科对他们有（有）非常糟糕的污名，因为许多早期的催化剂交换机都支持 10G。问题在于软件如何在端口通道中的多个端口上散列（或“平衡”）数据（这与 PAgP 或 LACP 无关）。

这篇文章在更详细地简化问题方面做得非常出色。这在今天与硬件/软件改进不太相关，但同样，它会有所不同 - 因此只需检查您的硬件要求并确保您没有购买成为此问题受害者的旧硬件。

http://www.packetmischief.ca/2012/07/24/doing-etherchannel-over-3-5-6-and-7-link-bundles/

对 EtherChannel 的 2n 个端口的要求是一项关键要求，还是仅仅是为了确保均衡负载平衡的建议？

大多数供应商没有这样的要求。这是基于负载平衡时三位散列的限制经常讨论的约定。我个人不同意这种立场，但我会在回答你的问题后谈到这一点。

特别是，如果我们设置了一个带有 8 个端口的 EtherChannel 组，但其中一个端口出现故障。剩下的 7 个端口是否仍然可用但负载平衡不均衡，或者 3 个端口是否会被迫独立以确保两个组的功率？

通常，如果您在链路聚合组中有 8 个端口并且其中一个出现故障，则其他七个将保持活动状态。是的，负载在某种意义上会有点不平衡，但同样，我会在一分钟内解决这个问题。

PAgP 和 LACP 的处理方式是否类似？

是的，静态 LAG 组也是如此。

现在我的观点是为什么我个人在链路聚合方面不坚持两个“经验法则”的力量。

首先，您确实需要了解，没有任何链路聚合可以平衡 LAG 中的链路利用率。显然，选择的负载平衡方法存在差异，有些比其他方法更好（尽管没有一种方法在每种情况下都是最好的）。

负载平衡方法不会平衡流量，而是平衡您可以考虑的“流量”。根据平台，您可以选择使用源和/或目标值，其中可能包括 MAC 地址、IP 地址、端口号等。然后对这些值进行哈希处理以确定为特定流选择哪个链接。具有相同值集的帧将始终接收相同的哈希值并分配给相同的链接。

并非所有流量都是平等的，这意味着无法通过这些方式平衡链路利用率。不要剥夺 LAG 的价值，因为它通常也能很好地平衡利用率，但您需要了解其局限性。

这些流中的一个或多个完全有可能利用它们在 LAG 中的整个链路，并使分配给同一链路的其他流处于饥饿状态。同时，其他链接未得到充分利用。

当大多数人查看此博客文章或此 Cisco 文档中的图表时，他们会发现流量不平衡。从某些链接接收的流量比其他链接更多的意义上说，这是正确的。

我对这些表的看法有点不同。首先，即使分布不平衡，当您添加链接时，链接上分配的流量百分比永远不会增加；而在大多数情况下，百分比会下降。换句话说，流访问带宽的机会在任何时候都不会减少，而且在许多情况下，它会有更多的机会。

其次，如果我要查看此图表来决定 LAG 中的两个或三个链接，我认为如下：

• 两条链路- 一条链路被充分利用将影响 50% 的流量，而 50% 不受影响
• 三个链接- 一个链接被充分利用将影响最多 37.5% 的流量，而 62.5% 不受影响；可能低至 25%，而 75% 不受影响

最后，考虑一下如果在 LAG 中丢失链接会发生什么情况。给定两个链接开始，这会将我的 LAG 减少到一个链接。如果我从三个开始，我还会剩下两个。

当然，平衡的流量吸引了我个性中的强迫症部分，但这仍然不能反映平衡的流量。除此之外，无论我怎么看，链接越多越好。

我能回忆起的（纠正我）：

Etherchannel 不是负载均衡，而是负载分配。具有奇数个链接的 EC 不会在链接之间平均分配负载 - 编号较低的链接接收更多流量。如果物理链路中断，流量将继续流动。

流量由目标 mac 地址平衡（默认情况下）。根据您的拓扑，这可能会导致不良的流量模式：

如果您在一台交换机上有一个邮件服务器，交换机之间有一个 EC，则 Etherchannel 另一侧交换机上的所有工作站都将使用相同的链接来到达邮件服务器......如果您的大部分流量是邮件服务器，这不提供负载平衡，邮件服务器只使用 Etherchannel 中的一个链接。

这可能会有所帮助：https : //supportforums.cisco.com/blog/150511/how-do-etherchannel-hash-algorithm-works-and-load-distribution-happen