第3层LACP目标地址散列工作到底有多精确？
基于一年前的一个更早的问题（ 多路复用的1 Gbps以太网？ ），我去了一个新的机架，并在全新的地方安装了一个带有LACP链路的ISP。 我们需要这一点，因为我们有单独的服务器（一个应用程序，一个IP），在整个互联网上提供数以千计的客户端计算机，累计超过1Gbps。
这个LACP的想法是要让我们打破1Gbps的障碍，而不用花10GoE交换机和NIC的财富。 不幸的是，我遇到了与出站stream量分配有关的一些问题。 （尽pipeKevin Kuphal在上面的链接问题中提出了警告）。
ISP的路由器是某种思科。 （我从MAC地址推断出来的）。我的交换机是HP ProCurve 2510G-24。 而服务器是运行Debian Lenny的HP DL 380 G5。 一台服务器是热备份。 我们的应用程序不能被聚集。 这是一个简化的networking图，其中包括所有与IP，MAC和接口相关的相关networking节点。
虽然它具有所有的细节，但是要处理和描述我的问题有点困难。 所以，为了简单起见，下面是一个简化为节点和物理链路的networking图。
于是我离开，在新的机架上安装了我的套件，并将ISP的电缆从他们的路由器上连接起来。 两台服务器都有一个到我的交换机的LACP链路，交换机有一个到ISP路由器的LACP链路。 从一开始我就意识到我的LACPconfiguration是不正确的：testing显示，每台服务器的所有stream量都是通过服务器到交换机和交换机到路由器之间的一条物理GoE链路。
随着一些谷歌search和大量RTMF时间有关的Linux网卡绑定，我发现我可以通过修改/etc/modules来控制NIC绑定
# /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
如预期的那样，这使stream量从两个NIC上离开我的服务器。 但是，交换机仅仅通过一条物理链路从交换机转移到路由器。
我们需要stream量通过两个物理链路。 阅读并重新阅读“2510G-24的pipe理和configuration指南”后 ，我发现：
[LACP使用]源 – 目的地址对（SA / DA）通过集群链路分发出站stream量。 SA / DA（源地址/目的地址）使交换机根据源/目的地址对将出站stream量分配给中继线群组内的链路。 也就是说，交换机通过同一个中继链路将相同源地址的stream量发送到同一个目的地址，并根据不同的链路将stream量从同一个源地址发送到不同的目的地址，具体取决于在干线的链接。
似乎一个绑定的链路只提供一个MAC地址，因此，我的服务器到路由器的path总是要从交换机到路由器的一条path上，因为交换机只能看到一个MAC（而不是两个每个端口）都用于LACP的链接。
得到它了。 但是这是我想要的：
更昂贵的HP ProCurve交换机是2910al在其散列中使用级别3的源和目标地址。 从“ProCurve 2910al pipe理和configuration指南 ”中“通过集群链路的出站stream量分布”部分：
通过干线的stream量的实际分配取决于使用来自源地址和目标地址的位的计算。 当IP地址可用时，计算包括IP源地址和IP目的地址的最后五位，否则使用MAC地址。
好。 所以，为了达到我想要的目的，我的源地址是固定的，因此目标地址是关键。 这导致我的问题：
第3层LACP散列工作到底有多精确？
我需要知道使用哪个目标地址：
- 客户的IP ，最终目的地？
- 或者路由器的IP ，下一个物理链路传输目的地。
我们还没有离开，还买了一个replace开关。 请帮助我了解第3层LACP目标地址散列是否是我需要的。 购买另一个无用的开关不是一个选项。
你正在寻找的是通常被称为“传输哈希策略”或“传输哈希algorithm”。 它控制从一组聚合端口中select一个端口来传输帧。
事实certificate，使用802.3ad标准是困难的，因为我不愿意花钱。 说了这么多，我已经能够从一个半官方的源头收集一些信息，这些信息可以帮助您了解您正在寻找的东西。 根据2007年在加拿大安大略省渥太华举行的演示文稿，IEEE符合 802.3ad标准的IEEE高速研究组没有要求“帧分发器”的特定algorithm：
本标准不要求任何特定的分配algorithm; 然而，任何分配algorithm都应确保当帧收集器按照43.2.3的规定接收帧时，algorithm不应引起a）任何给定会话的帧的错误sorting，或b）帧的重复。 通过确保构成给定会话的所有帧按照由MAC客户端生成的顺序在单个链路上传送，满足上述维持帧sorting的要求; 因此，此要求不涉及对MAC帧的任何信息的添加（或修改），也不涉及对相应帧收集器的任何缓冲或处理以重新sorting帧。
所以，无论采用什么algorithm，交换机/ NIC驱动程序用来分发传输帧都必须遵守该演示文稿（大概是从标准中引用）中所述的要求。 没有指定特定的algorithm，只定义了一个兼容的行为。
即使没有指定algorithm，我们也可以查看一个特定的实现，以了解这种algorithm是如何工作的。 例如，Linux内核“bonding”驱动程序具有符合802.3ad标准的传输哈希策略，该策略应用该函数（请参阅内核源文档\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地址影响端口select。
在这种哈希中使用的目标IP地址将是帧中存在的地址。 花点时间考虑一下。 在远离服务器到Internet的以太网帧头中，路由器的IP地址不会封装在这种帧中的任何位置。 路由器的MAC地址出现在这个帧的头部，但路由器的IP地址不是。 封装在帧有效负载中的目标IP地址将成为请求到服务器的Internet客户端的地址。
考虑到源IP地址和目标IP地址的传输哈希策略，假设您拥有广泛的客户端池，应该为您做得很好。 通常，当使用基于层3的发送散列策略时，stream经这样的聚合基础设施的业务中更广泛多样的源和/或目的地IP地址将导致更有效的聚合。
你的图表显示的请求直接从互联网上的服务器，但值得指出的代理可能会做的情况。 如果你代理客户端请求到你的服务器，那么，正如克里斯在他的回答中所说的那样，你可能会造成瓶颈。 如果代理从自己的源IP地址发出请求，而不是从Internet客户端的IP地址发出请求，那么在严格的基于3层的传输哈希策略中，可能会有更less的“stream量”。
只要符合802.3ad标准的要求，传输哈希策略也可以考虑第4层信息（TCP / UDP端口号）。 这个algorithm在Linux内核中，就像你在你的问题中引用的一样。 请注意，该algorithm的文档警告说，由于分段，stream量可能不一定沿着相同的pathstream动，因此algorithm不严格遵循802.3ad标准。
非常令人惊讶的是，前几天我们的testing显示，xmit_hash_policy = layer3 + 4在两个直接连接的linux服务器之间不会有任何影响，所有的stream量都将使用一个端口。 两个运行xen与1个桥梁，作为一个成员的键合设备。 最明显的是，这座桥可能会导致这个问题，只是考虑到使用基于IP +端口的散列而没有任何意义。
我知道有些人实际上设法将180MB以上的连结（即ceph用户）推向180MB +，所以它一般工作。 可能的事情要看： – 我们使用旧的CentOS 5.4 – OP的例子将意味着第二个LACP“连接”连接 – 是否有意义呢？
这个线程和文档的阅读等等都给了我看：
- 一般人都知道这个很多，善于从理论上诠释理论，甚至是IEEE的标准，而实际的经验几乎没有。
- RHEL文档最多是不完整的。
- 结合的文件是从2001年，不够stream行
- layer2 + 3模式显然不在CentOS中（它不显示在modinfo中，而在我们的testing中，启用时会丢弃所有的stream量）
- SUSE（BONDING_MODULE_OPTS），Debian（-o bondXX）和RedHat（BONDING_OPTS）都有不同的方式来指定每个绑定模式的设置
- CentOS / RHEL5内核模块是“SMP安全”，但不是“SMP能力”（请参阅Facebook高性能通话） – 它不会扩展到一个CPU以上，所以键合更高的CPU时钟>多核
如果任何人结束了一个好的高性能的绑定设置，或者真的知道他们在说什么，如果他们花了半个小时写一个新的小的howto文件，使用LACP的一个工作示例，没有奇怪的东西和带宽>一个链接
如果您的交换机看到真正的L3目的地，它可以对此进行散列。 基本上如果你有2个链接，认为链接1是针对奇数编号的目的地，链接2是针对偶数编号的目的地。 我不认为他们曾经使用下一跳的IP，除非这样做，但是这与使用目标的MAC地址非常相似。
您将要遇到的问题是，根据您的stream量，目标将始终是单个服务器的单个IP地址，因此您将永远不会使用其他链接。 如果目的地是互联网上的远程系统，那么你将得到均匀的分布，但是如果它是一个类似于Web服务器的地方，那么你的系统就是目的地址，交换机将总是只通过其中一个可用链路发送stream量。
如果在那里有一个负载均衡器，那么你将会变得更糟糕，因为那么“远程”IP将永远是负载均衡器的IP或服务器。 你可以通过在负载平衡器和服务器上使用大量的IP地址来解决这个问题，但这是一个破解。
您可能想要扩大供应商的视野。 其他供应商，如极端networking，可以散列如下内容：
L3_L4algorithm – 第3层和第4层，组合的源和目标IP地址以及源和目标TCP和UDP端口号。 适用于SummitStack和Summit X250e，X450a，X450e和X650系列交换机。
所以基本上只要客户端的源端口（通常会改变很多）发生变化，就会平均分配stream量。 我相信其他厂商也有类似的function。
即使散列源IP和目的IP也足以避免热点，只要你没有负载平衡器。
我会猜测它是closures的客户端IP，而不是路由器。 真正的源IP和目的IP将在数据包中处于一个固定的偏移量，并且这将很快进行散列。 散列路由器IP需要基于MAC的查找，对吧？
由于我刚刚回到这里，我现在学到了一些东西：为了避免灰白的头发，你需要一个支持layer3 + 4策略的体面的交换机，在Linux中也一样。
在很多情况下，称为ALB / SLB（模式6）的标准变形喷灯可能效果更好。 虽然在操作上很糟糕。
我自己我尽量使用3 + 4，因为我经常需要两个相邻系统之间的带宽。
我也尝试过使用OpenVSwitch，并曾经有一个实例中断了stream量stream（每个第一个数据包丢失了…我不知道）