第3层LACP目标地址散列的工作原理是什么？

基于一年多以前的一个问题（多路复用1 Gbps以太网？），我出发并设置了一个新机架，该机架带有一个新的ISP，并具有遍布各地的LACP链接。我们之所以需要这样做，是因为我们有单独的服务器（一个应用程序，一个IP）为Internet上成千上万的客户端计算机提供服务，累计累积速率超过1Gbps。

这个LACP想法应该让我们打破1Gbps的壁垒，而不必花大钱购买10GoE交换机和NIC。不幸的是，我在出站流量分配方面遇到了一些问题。（尽管在上述链接的问题中，凯文·库珀尔（Kevin Kuphal）发出警告，但仍要这样做。）

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

尽管包含所有细节，但要处理和描述我的问题有点困难。因此，为简单起见，这是一个简化为节点和物理链接的网络图。

因此，我出发了，将工具包安装在新机架上，并从他们的路由器连接了ISP的电缆。两台服务器都有到我的交换机的LACP链接，而交换机有到ISP路由器的LACP链接。从一开始，我就意识到我的LACP配置不正确：测试显示，往返于每台服务器的所有流量都完全通过服务器到交换机和交换机到路由器之间的一条物理GoE链路。

通过一些Google搜索和有关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目标地址哈希是不是我所需要的。不能再购买无用的交换机。

您要查找的内容通常称为“传输哈希策略”或“传输哈希算法”。它控制着从一组聚合端口中选择一个端口来传输帧。

事实证明，要实现802.3ad标准非常困难，因为我不愿意花钱。话虽如此，我已经能够从一个半官方的来源中收集一些信息，从而为您所寻找的提供了一些信息。根据2007年安大略省渥太华的演示文稿，满足 802.3ad标准的CA IEEE高速研究小组没有为“帧分配器”强制要求特定的算法：

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

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

即使未指定算法，我们也可以查看特定的实现，以了解这种算法的工作方式。例如，Linux内核“ bonding”驱动程序具有符合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地址和/或目标IP地址将导致更有效的聚合。

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

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

令人惊讶的是，几天前，我们的测试表明xmit_hash_policy = layer3 + 4在两个直接连接的linux服务器之间不会产生任何影响，所有流量都将使用一个端口。两者都通过带有桥接装置的一个桥接器运行xen。最明显的是，网桥可能会导致此问题，只是考虑到将使用基于ip + port的散列，根本没有意义。

我知道有些人实际上设法通过绑定链接（即ceph用户）推送了180MB以上的数据，因此它确实可以正常工作。可能要看的东西：-我们使用的是旧的CentOS 5.4-OP的示例将意味着第二个LACP“消除”连接-有意义吗？

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

• 通常每个人对此都非常了解，擅长从绑定方法甚至IEEE标准中朗读理论，而实践经验却几乎没有。
• RHEL文档充其量是不完整的。
• 绑定文档来自2001年，目前还不够
• layer2 + 3模式显然不在CentOS中（它不在modinfo中显示，并且在我们的测试中，启用后它丢弃了所有流量）
• SUSE（BONDING_MODULE_OPTS），Debian（-o bondXX）和RedHat（BONDING_OPTS）都具有不同的方式来指定每个绑定模式设置，这无济于事
• CentOS / RHEL5内核模块是“ SMP安全的”，但不是“具有SMP功能的”（请参阅​​facebook高性能讨论）-它不能扩展到一个CPU以上，因此绑定更高的CPU时钟>许多内核

如果任何人最终获得了一个好的高性能绑定设置，或者真的知道他们在说什么，那么如果他们花半个小时编写一个新的小方法，使用LACP记录一个工作示例，那将是非常棒的，没有任何奇怪的东西和带宽>一个链接

如果您的交换机看到了真正的L3目的地，则可以对其进行哈希处理。基本上，如果您有2个链接，则认为链接1适用于奇数编号的目的地，链接2适用于偶数编号的目的地。除非经过配置，否则我认为他们永远不会使用下一跳IP，但这与使用目标的MAC地址几乎相同。

您将遇到的问题是，根据您的流量，目的地将始终是单个服务器的单个IP地址，因此您将永远不会使用该其他链接。如果目标是Internet上的远程系统，则将获得平均分配，但是如果它是Web服务器（系统是目标地址），则该交换机将始终仅通过一个可用链接发送流量。

如果那里有负载均衡器，您的状况将更加糟糕，因为“远程” IP始终将是负载均衡器的IP或服务器。您可以通过在负载均衡器和服务器上使用大量IP地址来解决此问题，但这是一个hack。

您可能需要扩大供应商的视野。其他供应商（例如极限网络）可以散列如下内容：

L3_L4算法-第3层和第4层，组合源和目标IP地址以及源和目标TCP和UDP端口号。在SummitStack和Summit X250e，X450a，X450e和X650系列交换机上可用。

因此，基本上只要客户端的源端口（通常会发生很大变化）发生变化，您就可以平均分配流量。我确定其他供应商也有类似的功能。

只要您没有混合使用负载均衡器，即使对源IP和目标IP进行哈希处理也足以避免出现热点。

我猜想它是来自客户端IP，而不是路由器。实际的源IP和目标IP将在数据包中处于固定的偏移量，并且哈希处理将很快进行。散列路由器IP需要基于MAC的查找，对吗？

既然我刚刚回到这里，到现在，我学到了一些东西：为了避免白发，您需要一个像样的开关来支持layer3 + 4策略，在Linux中也是如此。

在很多情况下，称为ALB / SLB（模式6）的标准转换喷灯可能会更好。从操作上来说，它很烂。

我本人尽可能地使用3 + 4，因为我经常想要两个相邻系统之间的带宽。

我也尝试过使用OpenVSwitch，并且曾经有一个实例，其中该实例扰乱了流量（每个第一个数据包都丢失了……我不知道）