|
通过查询centos官方论坛，3.10.0-957.5.1.el7.x86_64版本内核存在bond模块问题。 说明如下：该问题触发的条件是对于工作模式为802.3ad的聚合链路，交Shutdown m-lag端口的某一slave端口后，再次开启（undo shutdown）该slave端口时，会偶发性地促发聚合链路对端的服务器Bond端口的对应slave端口发生异常。引发问题的函数为：drivers/net/bonding/bond_main.c: static int bond_slave_netdev_event(unsigned long event,struct net_device *slave_dev)。在该函数中，当Bond的slave link的NETDEV_UP事件发生时，如果尚不能获取link的正确速率信息，会错误地将该slave link置于BOND_LINK_FAIL状态。因为slave link从BOND_LINK_FAIL恢复为BOND_LINK_UP时，不会引起对slave port的LACP状态修改，导致lave port的LACP状态未被正确设置，进而导致即使slave link已经up，但仍不能被加入聚合链路组的情况。该问题，相当于上图中引入了红线的情况。上述代码问题，由社区patch “bonding/802.3ad: fix link_failure_count tracking”引入。 图解如下： 结合当前现象，问题解释说明如下： 状态说明： BOND_LINK_UP -- 上线状态,潜在的发送数据包的候选者（1号状态） BOND_LINK_FAIL -- 中间态，一般不能捕获，表示网卡出现故障，向状态BOND_LINK_DOWN切换中（2号状态）在其中不包含LACP状态修改 BOND_LINK_DOWN -- 故障状态（3号状态） BOND_LINK_BACK -- 中间态，一般不能捕获，表示网卡恢复，向状态BOND_LINK_UP切换中（4号状态）在其中包含LACP状态修改 场景描述： 在正常的网卡状态为1号3号两个状态（在网卡进行UP与DOWN的命令操作或者链路的抖动会导致状态的变化），2号与4号为两个中间态，同时，正常流程中由1→3，必须要走的流程为1→2→3，不应存在4号状态，由3→1，必须要走的流程为3→4→1，在3与4流程中存在一些对于网卡相关状态的转变信息，如从3到1的过程中在因为错误的指向（图中虚线表示，触发原因：网卡速率未能正常获取），导致了网卡在3号4号状态时，转化到了2号状态，这就导致了本该由4号状态恢复到1号的流程，从2号进行恢复，但是2号状态转化为1号状态导致了本该恢复的LACP状态没有修改，从而导致服务器没有向交换机发送LACP报文的现象。
|