我们在FreeBSD 9.3服务器1中放置了4端口Intel I340-T4 NIC，并将其配置为在LACP模式下进行链路聚合，以尝试将从主文件服务器将8到16 TiB数据镜像到2所需的时间减少。并行4个克隆。我们原本希望达到4 Gbit / sec的总带宽，但是无论我们尝试什么，它的出现速度都不会比1 Gbit / sec的总带宽快。2
我们正在iperf3用来在静态LAN上进行测试。3第一个实例几乎达到了预期的千兆位，但是当我们并行启动第二个实例时，两个客户端的速度下降到大约½Gbit / sec。添加第三个客户端会将所有三个客户端的速度降低到〜⅓Gbit / sec，依此类推。
我们在设置iperf3测试时非常小心，所有四个测试客户端的流量都会进入不同端口上的中央交换机：
我们已经验证了每台测试计算机都有一条返回机架交换机的独立路径，并且文件服务器，其NIC和交换机都具有通过拆分lagg0组并为每台计算机分配单独的IP地址来实现此目的的带宽。英特尔网卡上的四个接口中的一个。在这种配置下，我们确实实现了〜4 Gbit / sec的总带宽。
当我们沿着这条路走时，我们是使用旧的SMC8024L2网管型交换机执行此操作的。（PDF数据表，1.3 MB。）这不是当时最高端的交换机，但是应该可以做到这一点。我们认为该交换机可能由于年代久远而出现故障，但是升级到功能更强大的HP 2530-24G并没有改变症状。
HP 2530-24G交换机声称确实将四个端口配置为动态LACP中继：
# show trunks
Load Balancing Method: L3-based (default)
Port | Name Type | Group Type
---- + -------------------------------- --------- + ----- --------
1 | Bart trunk 1 100/1000T | Dyn1 LACP
3 | Bart trunk 2 100/1000T | Dyn1 LACP
5 | Bart trunk 3 100/1000T | Dyn1 LACP
7 | Bart trunk 4 100/1000T | Dyn1 LACP
我们已经尝试了被动和主动LACP。
我们已经验证了所有四个NIC端口都通过以下方式在FreeBSD端获得了流量：
$ sudo tshark -n -i igb$n
奇怪的是，tshark表明在只有一个客户端的情况下，交换机会在两个端口上拆分1 Gbit / sec的流，显然在它们之间进行ping-poning。（SMC和HP开关均显示此行为。）
由于客户端的总带宽仅集中在一个地方（在服务器机架中的交换机处），因此仅将该交换机配置为用于LACP。
我们首先启动哪个客户端，或者启动它们的顺序都没有关系。
ifconfig lagg0 在FreeBSD方面说：
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
ether 90:e2:ba:7b:0b:38
inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::92e2:baff:fe7b:b38%lagg0 prefixlen 64 scopeid 0xa
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: active
laggproto lacp lagghash l2,l3,l4
laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
我们已经在FreeBSD网络调整指南中应用了尽可能多的建议，以适应我们的情况。（其中很多都是不相关的，例如关于增加最大FD的内容。）
我们尝试关闭TCP分段卸载，但结果没有变化。
我们没有第二个4端口服务器NIC来设置第二个测试。由于成功通过4个单独的接口进行了测试，因此我们假设硬件没有损坏。3
我们看到了这些前进的道路，但没有一条具有吸引力：
购买更大，更差的交换机，希望SMC的LACP实施会失败，并且新交换机会更好。（升级到HP 2530-24G没有帮助。）凝视FreeBSD的
lagg配置，希望我们错过了一些东西。4无需进行链路聚合，而使用轮询DNS来实现负载平衡。
更换服务器NIC并再次切换，这次用10 GigE的东西，大约是此LACP实验的硬件成本的4倍。
脚注
你问为什么不转向FreeBSD 10？因为FreeBSD 10.0-RELEASE仍然使用ZFS池版本28，并且该服务器已升级到ZFS池5000，这是FreeBSD 9.3的新功能。直到FreeBSD 10.1发行大约一个月后，10. x发行版才能实现。不，从源代码重建到10.0-STABLE的最新优势不是一个选择，因为这是生产服务器。
请不要下结论。问题后面的测试结果将告诉您为什么这不是该问题的重复项。
iperf3是纯网络测试。尽管最终目标是尝试从磁盘填充4 Gbit / sec的聚合管道，但我们尚未涉及磁盘子系统。也许是越野车或设计不佳的，但没有比离开工厂时破碎的多了。
我已经从那做起了。