根据一年前的一个问题（多路复用 1 Gbps 以太网？），我去为一家新的 ISP 设置了一个新机架，并在各处都设置了 LACP 链路。我们需要这样做，因为我们有单独的服务器（一个应用程序，一个 IP）为整个互联网上的数千台客户端计算机提供服务，累计超过 1Gbps。
这种 LACP 理念应该可以让我们突破 1Gbps 障碍，而无需在 10GoE 交换机和 NIC 上花费大量资金。不幸的是，我遇到了一些与出站流量分配有关的问题。（尽管 Kevin Kuphal 在上述链接问题中提出了警告。）
ISP 的路由器是某种 Cisco 路由器。（我从 MAC 地址推断出这一点。）我的交换机是 HP ProCurve 2510G-24。服务器是运行 Debian Lenny 的 HP DL 380 G5。一台服务器是热备用。我们的应用程序无法集群。这是一个简化的网络图，其中包括所有相关的网络节点以及 IP、MAC 和接口。
虽然它包含了所有细节，但使用起来和描述我的问题有点困难。因此，为了简单起见，这里是简化到节点和物理链路的网络图。
于是我出发，在新机架上安装了套件，并从他们的路由器连接了 ISP 的电缆。两台服务器都与我的交换机建立了 LACP 链路，而交换机与 ISP 路由器建立了 LACP 链路。从一开始我就意识到我的 LACP 配置不正确：测试显示，每台服务器的所有流量都通过服务器到交换机和交换机到路由器之间的一条物理 GoE 链路传输。
经过一些谷歌搜索和大量关于 Linux NIC 绑定的 RTMF 时间，我发现我可以通过修改/etc/modules
# /etc/modules: kernel modules to load at boot time.
# mode=4 is for lacp
# xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2
bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1
loop
这使得流量通过两个 NIC 离开我的服务器，正如预期的那样。但流量仅通过一条物理链路从交换机移动到路由器，仍然。
我们需要流量通过两个物理链路。在反复阅读 2510G-24 的管理和配置指南， 我发现：
[LACP 使用] 源-目标地址对 (SA/DA) 来分配中继链路上的出站流量。SA/DA（源地址/目标地址）使交换机根据源/目标地址对将出站流量分配到中继组内的链路。也就是说，交换机通过相同的中继链路将来自相同源地址的流量发送到相同的目标地址，并通过不同的链路将来自相同源地址的流量发送到不同的目标地址，具体取决于中继中链路之间的路径分配循环。
似乎绑定链路仅呈现一个 MAC 地址，因此我的服务器到路由器路径将始终通过从交换机到路由器的一条路径，因为交换机只看到一个 MAC（而不是两个 - 每个端口一个）对于两个 LACP 链路。
明白了。但是我想要的是：
更昂贵的 HP ProCurve 交换机是 2910al，它在哈希中使用 3 级源地址和目标地址。从 ProCurve 2910al 的“跨中继链路的出站流量分配”部分管理和配置指南：
流量通过中继的实际分布取决于使用源地址和目标地址的位进行计算。当 IP 地址可用时，计算包括 IP 源地址和 IP 目标地址的最后五位，否则使用 MAC 地址。
好的。因此，为了让它按我想要的方式工作，目标地址是关键，因为我的源地址是固定的。这引出了我的问题：
第 3 层 LACP 散列具体如何工作？
我需要知道使用了哪个目标地址：
- 客户端的 IP，最终目的地是？
- 或者路由器的 IP，下一个物理链路传输目的地。
我们还没有去买一个替换的交换机。请帮我准确了解第 3 层 LACP 目标地址哈希是否是我需要的。再买一个没用的交换机不是一个选择。
答案1
你要找的东西通常被称为“传输哈希策略”或“传输哈希算法”。它控制从一组聚合端口中选择一个端口来传输帧。
获得 802.3ad 标准对我来说非常困难，因为我不愿意花钱。话虽如此，我还是从一个半官方来源收集了一些信息，这些信息可以让你了解你正在寻找什么。这是 2007 年渥太华 IEEE 高速研究组会议的演讲802.3ad 标准没有规定“帧分发器”的特定算法：
本标准不强制要求任何特定的分发算法；但是，任何分发算法都应确保，当帧收集器按照 43.2.3 中的规定接收帧时，该算法不会导致 a) 任何给定对话的帧排序错误，或 b) 帧重复。通过确保组成给定对话的所有帧按照 MAC 客户端生成的顺序在单个链路上传输，可以满足上述保持帧排序的要求；因此，此要求不涉及向 MAC 帧添加（或修改）任何信息，也不涉及相应帧收集器为了重新排序帧而进行的任何缓冲或处理。
因此，无论交换机/NIC 驱动程序使用何种算法来分配传输的帧，都必须遵守该演示文稿中所述的要求（大概是引用标准）。没有指定特定的算法，只定义了兼容的行为。
即使没有指定算法，我们也可以查看特定的实现，以了解这种算法的工作原理。例如，Linux 内核“bonding”驱动程序具有一个符合 802.3ad 的传输哈希策略，该策略应用了该函数（请参阅内核源代码的 Documentation\networking 目录中的 bonds.txt）：
Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF)
XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>
这会导致源和目标 IP 地址以及源和目标 MAC 地址影响端口选择。
这种哈希算法中使用的目标 IP 地址将是帧中存在的地址。花点时间考虑一下。路由器的 IP 地址位于从您的服务器到互联网的以太网帧头中，不会封装在这种帧的任何地方。路由器的MAC地址存在于此类帧的标头中，但路由器的 IP 地址不存在。封装在帧有效负载中的目标 IP 地址将是向您的服务器发出请求的 Internet 客户端的地址。
假设您拥有种类繁多的客户端池，那么同时考虑源 IP 地址和目标 IP 地址的传输哈希策略应该对您非常有效。一般而言，当使用基于第 3 层的传输哈希策略时，在这种聚合基础设施中流动的流量中，源 IP 地址和/或目标 IP 地址种类越多，聚合就越高效。
您的图表显示请求直接从互联网发送到服务器，但值得指出的是代理可能会对这种情况产生什么影响。如果您将客户端请求代理到您的服务器，那么克里斯在他的回答中谈到那么就可能造成瓶颈。如果该代理从其自己的源 IP 地址发出请求，而不是从 Internet 客户端的 IP 地址发出请求，那么在严格基于第 3 层的传输哈希策略中，可能的“流量”就会减少。
传输哈希策略也可以考虑第 4 层信息（TCP/UDP 端口号），只要它符合 802.3ad 标准中的要求即可。正如您在问题中提到的那样，这种算法位于 Linux 内核中。请注意，该算法的文档警告说，由于碎片化，流量可能不一定沿着相同的路径流动，因此该算法不严格符合 802.3ad 标准。
答案2
非常令人惊讶的是，几天前我们的测试表明 xmit_hash_policy=layer3+4 在两个直接连接的 Linux 服务器之间不会产生任何影响，所有流量都将使用一个端口。两者都运行 xen，并使用 1 个桥接器，该桥接器以绑定设备为成员。最明显的是，桥接器可能会导致问题，只是考虑到将使用基于 ip+端口的散列，这根本没有意义。
我知道有些人实际上设法通过绑定链接推送 180MB+（即 ceph 用户），所以它通常有效。可能需要查看以下事项：- 我们使用的是旧版 CentOS 5.4 - OP 示例意味着第二个 LACP“取消哈希”连接 - 这有意义吗？
此线程和文档阅读等向我展示了：
- 一般情况下，每个人都对此了解很多，擅长背诵bonding howto甚至IEEE标准中的理论，但实际经验却几乎没有。
- RHEL 文档充其量是不完整的。
- 粘合文件是 2001 年的，不够新
- centos 中显然没有 layer2+3 模式（它没有显示在 modinfo 中，在我们的测试中，启用后它会丢弃所有流量）
- SUSE（BONDING_MODULE_OPTS）、Debian（-o bondXX）和 RedHat（BONDING_OPTS）都有不同的方式来指定每个 Bond 模式设置，但这并没有帮助
- CentOS/RHEL5 内核模块是“SMP 安全的”，但不是“SMP 可支持的”（参见 Facebook 高性能讨论）——它不能扩展到超过一个 CPU，因此绑定更高的 CPU 时钟 > 许多核心
如果任何人最终实现了一个高性能的绑定设置，或者他们真的知道他们在说什么，如果他们花半个小时写一篇新的小指南，记录一个使用 LACP 的工作示例，没有奇怪的东西和带宽>一个链接，那就太棒了
答案3
如果您的交换机看到真正的 L3 目的地，它可以对其进行哈希处理。基本上，如果您有 2 个链接，请认为链接 1 用于奇数目的地，链接 2 用于偶数目的地。我认为除非配置为这样做，否则它们永远不会使用下一跳 IP，但这与使用目标的 MAC 地址几乎相同。
您将遇到的问题是，根据您的流量，目的地将始终是单个服务器的单个 IP 地址，因此您永远不会使用其他链接。如果目标是互联网上的远程系统，您将获得均匀分布，但如果它是 Web 服务器之类的东西，您的系统是目标地址，交换机将始终只通过其中一个可用链接发送流量。
如果其中某处有负载平衡器，情况会更糟，因为“远程”IP 始终是负载平衡器的 IP 或服务器。您可以通过在负载平衡器和服务器上使用大量 IP 地址来解决这个问题，但这是一种黑客行为。
您可能需要稍微扩大供应商范围。其他供应商（例如 Extreme Networks）可以处理以下事项：
L3_L4 算法 - 第 3 层和第 4 层，源和目标 IP 地址以及源和目标 TCP 和 UDP 端口号的组合。适用于 SummitStack 和 Summit X250e、X450a、X450e 和 X650 系列交换机。
因此基本上只要客户端的源端口（通常会发生很大变化）发生变化，您就会均匀地分配流量。我相信其他供应商也有类似的功能。
只要您没有混合负载均衡器，即使对源和目标 IP 进行散列也足以避免热点。
答案4
因为我刚刚回到这里，所以我现在学到了一些东西：为了避免白发，你需要一个支持第 3+4 层策略的像样的交换机，在 Linux 中也一样。
在很多情况下，违反标准的喷灯（称为 ALB/SLB（模式 6））可能效果更好。但操作起来很糟糕。
我自己尽可能尝试使用 3+4，因为我经常需要在两个相邻系统之间使用该带宽。
我也尝试过使用 OpenVSwitch，有一次它中断了流量（每个第一个数据包都丢失了……我不知道）