第 3 层 LACP 目标地址哈希究竟是如何工作的？

Question

基于一年多以前的一个问题（多路复用 1 Gbps 以太网？），我离开并使用新的 ISP 设置了一个新机架，并在整个地方都有 LACP 链接。我们需要这样做，因为我们有单独的服务器（一个应用程序，一个 IP）为互联网上的数千台客户端计算机提供服务，累积速度超过 1Gbps。

这个 LACP 想法应该让我们打破 1Gbps 的障碍，而无需在 10GoE 交换机和 NIC 上花费大量资金。不幸的是，我遇到了一些关于出站流量分配的问题。（尽管凯文·库法尔在上述链接问题中发出了警告。）

ISP 的路由器是某种 Cisco。（我是从 MAC 地址推断出来的。）我的交换机是 HP ProCurve 2510G-24。服务器是运行 Debian Lenny 的 HP DL 380 G5。一台服务器为热备。我们的应用程序不能集群。这是一个简化的网络图，其中包括具有 IP、MAC 和接口的所有相关网络节点。

虽然它具有所有细节，但很难处理和描述我的问题。因此，为简单起见，这里是一个简化为节点和物理链接的网络图。

所以我离开并在新机架上安装了我的工具包，并从他们的路由器连接了我的 ISP 电缆。两台服务器都有到我的交换机的 LACP 链接，而交换机有到 ISP 路由器的 LACP 链接。从一开始我就意识到我的 LACP 配置是不正确的：测试显示进出每台服务器的所有流量都通过一个物理 GoE 链路专门在服务器到交换机和交换机到路由器之间进行。

通过一些谷歌搜索和大量关于 linux NIC 绑定的 RTMF 时间，我发现我可以通过修改来控制 NIC 绑定 /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 目标地址散列是否是我需要的。购买另一个无用的开关不是一种选择。

Answer 1

您正在寻找的通常称为“传输散列策略”或“传输散列算法”。它控制从一组聚合端口中选择一个端口来传输帧。

事实证明，使用 802.3ad 标准很困难，因为我不愿意在上面花钱。话虽如此，我已经能够从半官方来源收集一些信息，这些信息对您正在寻找的内容有所了解。根据2007 年加拿大安大略省渥太华 IEEE 高速研究组的介绍，满足802.3ad 标准的不要求“帧分配器”使用特定算法：

本标准不强制要求任何特定的分发算法；然而，任何分发算法都应确保，当帧被 43.2.3 中规定的帧收集器接收时，该算法不应导致 a) 属于任何给定会话的帧的错误排序，或 b) 帧的重复. 通过确保构成给定对话的所有帧按照 MAC 客户端生成的顺序在单个链路上传输，可以满足上述保持帧顺序的要求；因此，此要求不涉及向 MAC 帧添加（或修改）任何信息，也不涉及相应帧收集器部分的任何缓冲或处理以重新排序帧。

因此，无论交换机 / NIC 驱动程序使用何种算法来分发传输的帧，都必须遵守该演示文稿中所述的要求（大概是从标准中引用的）。没有指定特定的算法，仅定义了合规行为。

即使没有指定算法，我们也可以查看一个特定的实现来了解这种算法的工作原理。例如，Linux 内核“绑定”驱动程序具有应用该函数的符合 802.3ad 的传输哈希策略（请参阅内核源代码的 Documentation\networking 目录中的bonding.txt）：

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

这会导致源 IP 地址和目标 IP 地址以及源 MAC 地址和目标 MAC 地址影响端口选择。

在这种类型的散列中使用的目标 IP 地址将是帧中存在的地址。花点时间考虑一下。路由器的 IP 地址位于远离您的服务器到 Internet 的以太网帧标头中，并未封装在此类帧中的任何位置。路由器的MAC 地址存在于此类帧的标头中，但路由器的 IP 地址不存在。封装在帧有效载荷中的目标 IP 地址将是向您的服务器发出请求的 Internet 客户端的地址。

考虑到源 IP 地址和目标 IP 地址的传输散列策略（假设您有广泛多样的客户端池）应该非常适合您。一般而言，当使用基于第 3 层的传输哈希策略时，流经此类聚合基础设施的流量中更广泛变化的源和/或目标 IP 地址将导致更有效的聚合。

您的图表显示了从 Internet 直接到达服务器的请求，但值得指出代理可能对这种情况做些什么。如果您将客户端请求代理到您的服务器，那么正如克里斯在他的回答中所说的那样，您可能会导致瓶颈。如果该代理从其自己的源 IP 地址发出请求，而不是从 Internet 客户端的 IP 地址发出请求，则在严格基于第 3 层的传输哈希策略中，您将拥有更少的可能“流”。

传输哈希策略也可以考虑第 4 层信息（TCP / UDP 端口号），只要它符合 802.3ad 标准中的要求。正如您在问题中所引用的那样，这样的算法在 Linux 内核中。请注意，该算法的文档警告说，由于碎片化，流量可能不一定沿着相同的路径流动，因此，该算法并不严格符合 802.3ad。

Answer 2

很奇怪，前几天我们的测试表明 xmit_hash_policy=layer3+4 在两台直连的linux服务器之间不会有任何影响，所有的流量都将使用一个端口。两者都使用 1 个具有绑定设备作为成员的桥运行 xen。最明显的是，网桥可能会导致问题，只是考虑到将使用基于 ip+port 的散列，这完全没有意义。

我知道有些人实际上设法通过绑定链接（即 ceph 用户）推送 180MB+，所以它通常可以工作。可能需要考虑的事情： - 我们使用旧的 CentOS 5.4 - OP 示例意味着第二个 LACP 对连接进行“解散” - 这是否有意义，曾经吗？

该线程和文档阅读等向我展示了什么：

• 一般大家都知道很多，擅长背诵bonding howto甚至IEEE标准中的理论，而实践经验则几乎没有。
• RHEL 文档充其量是不完整的。
• 绑定文档是 2001 年的，不够最新
• layer2+3 模式显然不在 CentOS 中（它没有显示在 modinfo 中，在我们的测试中，它在启用时丢弃了所有流量）
• SUSE (BONDING_MODULE_OPTS)、Debian (-o bondXX) 和 RedHat (BONDING_OPTS) 都有不同的方式来指定 per-bond 模式设置，这无济于事
• CentOS/RHEL5 内核模块是“SMP 安全的”，但不是“SMP 能力的”（请参阅​​ facebook 高性能演讲）-它不会扩展到一个 CPU 以上，因此绑定更高的 CPU 时钟 > 多个内核

如果有人最终获得了良好的高性能绑定设置，或者真的知道他们在谈论什么，那么如果他们花半个小时编写一个新的小教程来记录一个使用 LACP 的工作示例，没有奇怪的东西和带宽，那就太棒了> 一个链接