w5500网线拔掉检测不到_linux中bond的链路检测

近期的项目中遇到了这样一个问题，引发了笔者对linux bond和lacp协议的一些研究：

如上图所示，server有两张网卡配置了bond0， 工作在mode4负载均衡模式下,  现在从client对server进行持续的ping测试，发现：

插拔server端物理网口的网线时， ping一直正常，无丢包；用ifconfig down enp4s0f0/1 来关闭物理网口时，ping会丢包，且持续1分多钟，之后恢复正常；

这个测试结果实在是非常的令人发指，bond技术的初衷就是为了链路冗余和增加带宽，现在却发现在人为关闭其中一个物理网口后，竟然会造成如此长时间的网络中断，不得不教人对其深究一二了，为了解决这个问题，我们必须搞清楚以下几个问题：

插拔网线时，网络正常，说明bond保证了链路冗余，是如何做到的？

ifconfig down关闭网口时，网络中断，说明bond没有保证链路冗余，为什么？

网络中断后，是怎么自动恢复的？

在bond无法保证链路冗余时，为何中断时间这么长？此处贴上server上的网卡配置文件，注意倒数第2，3行的注释信息，这将是本文讨论的重点内容

# The loopback network interfaceauto loiface lo inet loopback auto enp4s0f0iface enp4s0f0 inet manualbond-master bond0 auto enp4s0f1iface enp4s0f1 inet manualbond-master bond0 # mgmt networkauto bond0iface bond0 inet static  address 172.31.20.22 mtu 1550  netmask 255.255.255.0  gateway 172.31.20.254  dns-nameservers 172.31.20.64  bond-mode 4  bond-miimon 100                 # mii对slave网口的检测周期，为100ms     bond-lacp-rate 1                # lacpud发送周期为1s,配置为0则为30s  bond-slaves enp4s0f0 enp4s0f1

问题1：插拔网线时，网络正常，说明bond保证了链路冗余，是如何做到的？解答：bond为了保证链路高可用，提供了两种链路检测机制，分别是MII检测和ARP检测，上述配置中，`bond-miimon 100`表示bond进行MII检测的周期为100ms，在拔掉网线时，bond的MII检测会发现相应网>口的链路故障，从而将流量引导到健康的网口上，关于MII检测的深入信息，与本文关系不大，可以参考IBM的相关文档。 问题2：既然bond可以检测到链路故障，为何在ifconfig down关闭网口时不能呢？解答：bond的去读取/proc/net/bonding/bond0这个文件，去获取bond相关接口的状态信息，来达到检测的目的，正常情况下，该文件如下， 可以看到(已省去不必要的信息)，bond0以及两个物理网口下，`MII Status: up`：

root@tr02n12:~# cat /proc/net/bonding/bond0Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: IEEE 802.3ad Dynamic link aggregationTransmit Hash Policy: layer2 (0)MII Status: up......Slave Interface: enp4s0f0MII Status: up......Slave Interface: enp4s0f1MII Status: up...

如果拔掉enp4s0f0对应的网口，则会发现，enp4s0f0下会发生改变 `MII Status: down`， bond由此知道了该接口故障，将流量引导到enp4s0f1：

root@tr02n12:~# cat /proc/net/bonding/bond0Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: IEEE 802.3ad Dynamic link aggregationTransmit Hash Policy: layer2 (0)MII Status: up......Slave Interface: enp4s0f0MII Status: down......Slave Interface: enp4s0f1MII Status: up...

那么如果使用命令关闭网口呢，让我们测试一下, 发现该文件中enp4s0f1的相关信息被删去了，因此bond不能获取到enp4s0f1的MII Status，也就无法检测到该条链路故障，也无法保证链路高可用了：

root@tr02n12:~# ifdown enp4s0f1root@tr02n12:~# cat /proc/net/bonding/bond0Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: IEEE 802.3ad Dynamic link aggregationTransmit Hash Policy: layer2 (0)MII Status: up......Slave Interface: enp4s0f0MII Status: up

问题3：网络中断后，是怎么自动恢复的？解答：既然在运行命令关闭网口的情形下，bond无法做到故障检测，那么网络在一段时间后是如何自动恢复的呢？从bond的配置文件中，我们可以看到`bond-mode 4`, 这个模式也叫做802.3ad模式，可基于LACP协议保证链路的高可用，在故障时自动恢复，因此，这个问题的答案就是，网络中断是因为bond没有检测到链路故障，而LACP检测到了链路故障并进行了自动恢复，LACP是如何进行链路恢复的呢，这将在 下一个问题中进行说明。 问题4：在bond无法保证链路冗余时，为何中断时间这么长？解答：LACP链路聚合的两端设备的网口间，通过LACPDU与对端交换信息，首先让我们来看一下LACP报文的格式，其中：

LACP_Timeout：代表链路接收LACPDU报文的周期，有两种，快周期1s和慢周期30s，超时时间为周期的3倍。短超时被编码为1，长超时被编码为0。

这一字段规定了超时时间，如果在超时时间内没有收到对端发送的LACPDU, 则认为链路故障，进行链路切换。在链路两端设备的LACP_Timeout值不一致时，以长的一方为准。鉴于我们的情景中，网络中断的>时间足有1分多钟，有理由怀疑是因为此处超时时间协商为了90s，从配置文件中, `lacp-rate fast`表示server的bond口该字段配置的是短超时，那么问题有可能出现在对端交换机的聚合口配置上，让我们>用tcpdump抓包验证一下(在enp4s0f0上抓取1个二层协议类型为0x8809，即LACP协议的包，并显示详细信息)：

root@tr02n12:~# tcpdump -e ether -i enp4s0f0 proto 0x8809 -vv -c 1tcpdump: listening on enp4s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes17:54:03.486988 ec:0d:9a:9c:99:56 (oui Unknown) > 01:80:c2:00:00:02 (oui Unknown), ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110  Actor Information TLV (0x01), length 20    System ec:0d:9a:9c:99:56 (oui Unknown), System Priority 65535, Key 15, Port 3, Port Priority 255    State Flags [Activity, Timeout, Aggregation, Synchronization, Collecting, Distributing]  Partner Information TLV (0x02), length 20    System 5c:83:8f:4b:eb:c1 (oui Unknown), System Priority 32768, Key 126, Port 283, Port Priority 32768    State Flags [Activity, Aggregation, Synchronization, Collecting, Distributing]  Collector Information TLV (0x03), length 16    Max Delay 0  Terminator TLV (0x00), length 01 packet captured1 packet received by filter

通过对比enp4s0f0的mac地址，可以确定上面这个包为从enp4s0f0发送给对端LACP接口的LACPDU包，按照LACP报文的格式中的信息，可以看出，对端没有置位Timeout位，因此是设置的长超时，也就是90s，因 此链路恢复的时间才会如此长。 要解决该问题，则需要在交换机上对应的聚合端口也配置lacp超时时间为短超时(比如锐捷的配置： lacp short-timeout ) ， 这样的话，在手动关闭网口后的恢复时间应会变成3s左右。 小结本文通过一个手动关闭端口引发的bond口中断故障，进行分析，阐明了bond的链路检测及高可用原理，验证LACP的超时时间参数效果。解释了bond下插拔网线和命令关闭端口造成结果不同的原因。from：https://blog.csdn.net/m0_37904728/article/details/104798846