嘿，这是我在思科论坛上提出的一个问题的转发，但从未得到有用的答复。
嘿，我正在尝试将工作中的 FreeBSD 服务器从常规千兆位链路转换为双千兆延迟链路。我们的生产服务器在 3560 上。我在 3550 上有一个小型测试环境。我已经实现了故障转移，但在实现速度提升方面遇到了麻烦。所有服务器都运行千兆英特尔 (em) 卡。服务器的配置如下：
BSD服务器:
#!/bin/sh
#bring up both interfaces
ifconfig em0 up media 1000baseTX mediaopt full-duplex
ifconfig em1 up media 1000baseTX mediaopt full-duplex
#create the lagg interface
ifconfig lagg0 create
#set lagg0's protocol to lacp, add both cards to the interface,
#and assign it em1's ip/netmask
ifconfig lagg0 laggproto lacp laggport em0 laggport em1 ***.***.***.*** netmask 255.255.255.0
交换机配置如下：
#clear out old junk
no int Po1
default int range GigabitEthernet 0/15 - 16
# config ports
interface range GigabitEthernet 0/15 - 16
description lagg-test
switchport
duplex full
speed 1000
switchport access vlan 192
spanning-tree portfast
channel-group 1 mode active
channel-protocol lacp
**** switchport trunk encapsulation dot1q ****
no shutdown
exit
interface Port-channel 1
description lagginterface
switchport access vlan 192
exit
port-channel load-balance src-mac
end
显然，将 3550 的配置中的 1000 更改为 100，将千兆以太网更改为快速以太网，因为该交换机具有 100Mbit 速度端口。
使用此配置在 3550 上，我同时在两条链路上实现了故障转移和 92Mbits/sec 的速度，连接到 2 台主机。（使用 iperf 测试）成功。但是，这仅适用于“switchport trunk encapsulation dot1q”行。
首先，我不明白为什么我需要这个，我以为它只是用于连接交换机。这个设置是否还有其他可以打开并真正提高速度的设置？其次，
此配置在 3560 上不起作用。我实现了故障转移，但速度没有提高。当我同时与服务器建立 2 个连接（无论是否使用封装线路）时，速度从 gig/sec 降至 500Mbit/sec。我应该提到，两个交换机都使用源 mac 负载平衡。
在我的测试中，我使用的是 Iperf。我将服务器（lagg box）设置为服务器（iperf -s），客户端计算机是客户端（iperf -c server-ip-address），因此两个连接的源 mac（和 IP）不同。
任何想法/更正/问题都会有帮助，因为我真正需要的是 gig 交换机上的 lagg 链接。如果您需要更多信息，请询问。
答案1
+1 感谢 James Cape。大多数用于提高速度的以太网绑定仅影响多个连接。单个套接字通常不会分布在多个接口上。
请注意“通常”的用法，因为我不是链接绑定专家。
答案2
802.3ad 链路聚合（以及许多其他多路径技术）通常按流而不是按数据包将流量拆分到多个链路上 — 原因很简单：每个链路上的传输延迟总会有细微差别。也许一个接口有更高效的驱动程序，或者更高的中断优先级，或者电缆稍短一些，因此电子可以更快地到达那里（真的）。无论哪种情况，数据包以与发送顺序不同的顺序到达目的地的情况非常常见。
大量无序数据包通常是一件坏事，因为 TCP 仅确认收到的最后一个数据包为了无序数据包将导致 TCP 发送重复的 ACK，TCP 会将其解释为拥塞指示，从而促使 TCP 减慢速度（或者如果触发 TCP 快速重传，甚至不必要地重传）。
当然，如果每个对话都局限于一个链接，那么这些都不是问题。没有人关心一个对话的数据包是否与另一个对话的数据包重新排序。
因此，大多数多路径实现通过对几个报头字段执行哈希算法来选择传出的物理链路。通常，所查看的报头字段将是以下组合：
- src-ip
- src-port (or possibly another identifier if not TCP/UDP)
- dst-ip
- dst-port (or possibly another identifier if not TCP/UDP)
- ip-proto
- vlan-id
因此，对于每个数据包，每个字段的值都会被哈希处理，结果决定从哪个接口发送数据包。平均而言，如果有很多不同的流，则每个链接上都会有类似数量的流量。如果只有一个流，那么每个数据包的所有这些字段都将相同，因此每个数据包最终都会到达同一个链接。
如果您有两个流，那么您基本上是在赌这两个流将位于不同的链路上，而这正是您所看到的。如果您运气不好，您可以通过更改哈希函数考虑的任何变量来再次掷骰子：例如，尝试不同的端口。事实上，通过打开 802.1q 标记，您将 vlan-id 引入到组合中，这显然会改变哈希的结果。
此外，没有执行哈希的标准方法，这意味着如果您连接来自不同供应商的系统（甚至是来自同一供应商的不同版本的软件），则每一方可能以不同的方式执行哈希，因此两个特定的流可能最终从服务器到交换机的链接不同，但从交换机到服务器的链接相同。
底线是，802.3ad 和其他数据包级多路径技术必然是基于流的，如果您有许多不同的流，它们会很好地工作，但不太适合少量大流。