1、前言

我们在服务器和交换机对接的场景中，经常接到这样的需求——1、希望服务器和接入交换机之间的链路形成冗余；2、两条链路形成冗余的同时，对两条物理链路的流量进行负载分担，从而形成带宽叠加的效果。因此在这样的需求之下，就需要分别在Linux服务器和接入交换机上配置网口bond（绑定）和链路聚合，然后进行对接，尽管Linux的bond和交换机的链路聚合所满足的需求是相同的，但因为两者存在一定的差异，因此就需要对两者有一个具体的认识，从而避免因为配置错误造成各种网络故障。

2、Linux的bond和交换机链路聚合差异的描述

2.1、交换机链路聚合

交换机链路聚合的模式有两种——手工负载分担模式和LACP模式，无论是何种模式，交换机链路聚合最多支持聚合的网口数量在绝大多数情况下为8个（具体数量取决于交换机底层的交换芯片），这两种模式都分别有对应的HASH算法，通过这个HASH算法来决定将要发送的数据包究竟是从哪个物理接口发出去，相应的HASH算法分别为：目的IP地址异或（dst-ip）、目的mac地址异或（dst-mac）、源目IP地址异或（src-dst-ip）、源目mac地址异或（src-dst-mac）、源IP地址异或（src-ip）、源mac地址异或（src-mac），以华为S3700交换机为例，如下图所示：
在这里插入图片描述
关于交换机链路聚合HASH算法的讲解，具体可以参阅：https://blog.csdn.net/muxia_jhy/article/details/102992810
2.2、Linux服务器网口的bond
Linux服务器配置网口的链路聚合有bond（绑定）和team（组合）两种方式，其中bond可以实现最多2张物理网卡的聚合，而team可以实现最多8张网卡的链路聚合，实际配置时，我们配置bond的时候是相对更多的，而在bond中，可供选择的模式有7种，如下表所示：

模式名称	含义及是否需对端交换机做链路聚合
mode0/(balance-rr) Round-robin policy(平衡轮询策略)	传输数据包顺序是依次按网口顺序传输，直到最后一个传输完毕，要求对端交换机配置链路聚合且须是手工负载分担模式。
mode1/(active-backup) Active-backup policy(活动备份策略)	只有一个设备处于活动状态，若一个宕掉另一个马上由备份转换为主链路，mac 地址外部可见，不需要交换机配置链路聚合，但交换机会产生MAC地址漂移日志记录。
mode2/(balance-xor) XOR policy(平衡策略)	传输根据[(源 MAC 地址 xor 目标 MAC 地址) mod 设备数量]的布尔值选择传输设备，此模式提供负载平衡和容错能力，不需要交换机配置链路聚合。
mode3/(broadcast) Broadcast policy(广播策略)	将所有数据包传输给所有设备，不需要交换机配置链路聚合。
mode4/(802.3ad) IEEE 802.3ad Dynamic link aggregation(IEEE 802.3ad动态链接聚合)	创建共享相同的速度和双工设置的聚合组。此模式提供了容错能力。每个设备需要基于驱动的重新获取速度和全双工支持；需要对端交换机配置链路聚合并选择为LACP模式。
mode5/(balance-tlb) Adaptive transmit load balancing(适配器传输负载均衡)	发出的流量根据当前负载分给每一个设备，由当前设备处理接收，如果接受的设备传不通就用另一个设备接管当前设备正在处理的 mac 地址，不需要交换机做链路聚合。
mode6/(balance-alb) Adaptive load balancing(适配器负载均衡)	包括 mode5，由ARP协商完成接收的负载。bonding 驱动程序截获 ARP 在本地系统发送出的请求，用其中之一的硬件地址覆盖从属设备的原地址。就像是在服务器上不同的人使用不同的硬件地址一样，不需要交换机做链路聚合。

3、在Linux服务器上如何选择bond模式对接交换机更好

3.1、bond模式的选择思路1——根据交换机的配置决定Linux服务器

通常情况下，Linux服务器网口的bond所支持的模式与HASH算法相较于交换机而言更加丰富，因此我们一般都是先将交换机的模式（究竟是手工负载分担模式还是LACP模式）和HASH算法确定下来后，再根据交换机的情况确定Linux服务器bond的模式，不过我们需要在HASH算法上注意以下两点：

无论是Linux服务器还是交换机，HASH算法决定的是数据包从哪个物理成员网口发送出去，不影响各自接收的数据包；
Linux服务器和交换机的HASH算法一般情况下无法做到一致。

基于以上两点，决定Linux服务器的bond采用何种模式的，是交换机一侧的模式而非HASH算法，所以需要搞清楚交换机一侧是采用的手工负载分担模式还是LACP模式。
在一般场景中，为了便于网络维护，客户或者运维人员通常都会在交换机上配置链路聚合，因为如果服务器采用不需要交换机配置链路聚合的mode方案，交换机上的arp表项将相对变得复杂，相对增加了网络排错复杂度。

3.2、bond模式的选择思路2——根据是否有带宽叠加需求决定

虽然链路聚合必定会产生的效果是物理链路冗余，但是否会产生带宽叠加的效果则取决于具体的场景，例如“Linux服务器mode4的bond+交换机LACP”这样的组合则不会产生带宽叠加效果，原因在于LACP（或802.3ad）存在M:N模式，即“M条活动链路+N条备份链路”组合为链路聚合。备份链路不会传输业务数据流量，其中代表M的活动链路数量上限阈值可以通过配置进行修改，而代表N的备份链路数量至少都会存在一条，加之bond最多只能支持两条链路聚合，所以“服务器mode4的bond+交换机LACP”这样的组合方式，链路始终都是一主一备的状态，流量无法负载分担，因而无法带宽叠加。
在这里插入图片描述

3.3、建议配置的“Linux服务器bond+交换机链路聚合”组合

针对一般服务器和接入交换机对接之场景，可以有以下组合供配置参考，当然可以根据实际需求进行实际分析和组合：

Linux服务器mode0+交换机手工负载分担链路聚合
Linux服务器mode4+交换机LACP链路聚合

4、链路聚合故障排查思路举例

4.1、问题现象

某项目工程师反馈，项目现场某OA服务器出现用户访问业务缓慢的情况，经过OA工程师排查，业务层面不存在问题，且将两条已经做好bond的网线链路拔除一根后，访问速度恢复正常，重新插入后，访问速度又变的非常缓慢，要求我们对操作系统的bond配置进行排查。

4.2、问题分析与定位

通过现场查看系统配置后，结合相关的机房和网络环境，分析如下：

系统bond配置不存在任何问题；
系统bond是基于Linux的NetworkManager服务，在Linux中NetworkManager是非常成熟的服务，一般不存在适配上的问题；
需要排查的点需要从两个方面入手——网络设备配置和硬件网卡；

综上所述，首先排查网络设备的配置，如果网络设备配置正常，则需要排查硬件网卡。
通过勘察现场环境，发现Linux服务器对端的交换机并不在同一个机柜内，由于现场工程师也不清楚对端交换机在什么位置，因此无法实际查看到交换机，相关现场环境大体如下图所示：
在这里插入图片描述
查看服务器网口指示灯，发现两个网口指示灯都是闪烁状态，说明和交换机之间不存在物理层面上的断开，此时需要弄明白的是交换机配置是否正确、插入交换机的网口是否插错以及服务器和交换机之间是否经过了其他网络设备。当然此时的职责不在是系统运维工程师的范围内，需要网络工程师介入。
由于现场工程师找不到交换机，因此无法通过查看实际的设备找到服务器的两个bond网口对应交换机的哪两个网口，由于现场可以通过ssh的方式登录到交换机，因此可以开启交换机日志信息弹出命令（华为/H3C系交换机命令和思科系交换机命令均为“terminal monitor”），然后在服务端进行网线的插拔，交换机上就可以看到物理接口的up与down的日志弹出提示，示例如下：
在这里插入图片描述
随后查看交换机的链路聚合（Eth-Trunk）成员接口配置，发现链路聚合的物理成员接口并不是0/0/1和0/0/2接口，而是0/0/1和0/0/3接口，因此原因找到，是交换机一侧链路聚合的物理成员接口配置错误，如下图所示：
在这里插入图片描述

4.3、此案例网络传输质量变差的分析

通过上述分析来看，交换机一侧的网线插错网口的情况。通常在网口对应关系没有错误的情况下，如果链路聚合的成员链路被down掉，即其中的网口指示灯直接不亮，虽网络带宽不再翻倍，但实际的网络传输质量也不会差于聚合前的网络传输质量，而此案例之所以网络质量比聚合前更差，正是因为交换机插错网口导致。其中的一条链路是错误的链路，但网口指示灯仍旧闪烁处于up的状态。加上服务器一侧的bond配置为mode0这样的轮询模式，这将导致一半的数据包从错误的网口上发送出去，因为OA系统涉及到了大量的TCP和HTTP这样的可靠连接，所以当数据包丢失的情况出现时，会伴随大量的数据包重传，然而重传的数据包仍旧会有一半会被丢失，如此会一直循环下去，严重降低网络传输质量。