6800聚合端口对接服务器接口吞吐量上不去

服务器===交换机===服务器    交换机侧4条链路静态聚合，服务器侧bond0绑定

两台服务器彼此相互打流程测试，交换机二层透传vlan 3007的流量始终卡在 500Mbps左右，聚合端口是40Gbps的。  服务器侧为判断问题原因在哪，于是甩开S6800交换机，服务器的4个网卡彼此直接连接。打流测试能跑到24Gbps左右。

打流的时候抓包，看到有大量重传报文

确认是bond模式造成吞吐量下降，下面从两个角度来分析一下交换机链路聚合与服务器对接mode=0模式为什么会造成网络吞吐量下降

一、从理论角度分析

服务器和交换机做链路聚合采用mode=0模式都可能会存在这个问题，因为轮询发包的方式从两个端口发包经过的链路不同，终端收到的包可能就会出现乱序，这时候终端就会发送要求重传的报文的信号。下面是mode=0模式的详细说明， mode0 平衡负载模式：平时两块网卡工作，但需要在服务器本机网卡相连的交换机设备上进行端口聚合来支持绑定技术。

二、从实际情况来分析

下图是在192.168.208.71这台服务器上往192.168.208.29服务器传送文件时抓到的包，从抓到的包来看服务器经过轮询发包的形式发送数据，由于中间链路的的原因确实给网络吞吐量带来了影响

当29收到乱序的包时，会回应一个DUP ACK报文，可以看出frame为79683的报文是79683的DUP ack要求重传报文，在抓到的包里通过搜索tcp.analysis.out_of_order可以看到后到的报文，所以确实有乱序的包

例如服务器1口发出了100号包到交换机1口，服务器2口发出了101号包到交换机2口，终端先收到了交换机4口发来的101号包，后收到了交换机3口发来的100号包，收到101号包的时候发现时序不对就要求重传，然后在wireshark里经过筛选可以看到重传的报文如下图所示，

综上所述，linux服务器网卡聚合mode=0模式与交换机对接会使得网络的吞吐量下降，解决方案：Linux服务器网卡聚合与交换机对接更换为动态链路聚合方式(即mode=4)。

服务器侧更换其他bond模式和交换机对接，调整合适模式参数