Linux双网口绑定后网络中断如何排查？

Question

在配置Linux双网口绑定（bonding）后出现网络中断，常见问题是绑定模式选择不当或配置参数错误。例如，误将无需交换机支持的mode=0（balance-rr）用于不支持链路聚合的交换机，导致数据包转发异常。同时，网卡未正确加入bond0、MII检测间隔过长或主备网卡状态切换失败，也会引发通信中断。如何排查并确定是绑定模式不匹配还是底层网卡驱动问题？

Answer 1

一、初步排查：确认bonding接口状态与成员网卡绑定情况

当配置Linux双网口绑定（bonding）后出现网络中断，首先应检查bond0接口是否正常创建且物理网卡已正确加入。可通过以下命令查看：

cat /proc/net/bonding/bond0

该文件输出将显示当前bonding模式、MII监控间隔、主备关系以及各slave网卡的状态。若输出中未列出预期的eth0和eth1，则说明网卡未成功绑定。

进一步使用ip命令验证接口状态：

ip link show bond0
ip addr show

若bond0处于DOWN状态，需检查是否执行了ifup操作或NetworkManager服务是否干扰配置。

此外，确认网卡驱动已加载：

ethtool -i eth0
ethtool -i eth1

确保驱动名称一致且为活动状态，避免因驱动缺失导致无法参与bonding。

此阶段主要目标是排除配置遗漏问题，如未加载模块、未添加到bond组等基础错误。

二、深入分析：识别bonding模式与交换机兼容性

Linux bonding支持多种模式，不同模式对交换机支持要求各异。常见模式如下表所示：

Bonding Mode	Description	Switch Support Required	Common Issues
mode=0 (balance-rr)	轮询负载均衡	必须配置静态LAG或LACP	交换机未聚合→数据包乱序/丢包
mode=1 (active-backup)	主备冗余	无需特殊配置	MII检测延迟→切换不及时
mode=4 (802.3ad/LACP)	动态链路聚合	必须启用LACP	LACP协商失败→端口阻塞
mode=5 (balance-tlb)	适配器传输负载平衡	无	接收负载不均
mode=6 (balance-alb)	双向负载平衡	无	ARP协商异常

若误用mode=0于不支持链路聚合的交换机，会导致交换机视两接口为独立设备，可能触发环路保护或MAC漂移，造成通信中断。

此时应优先切换至mode=1（active-backup），因其仅依赖单路径通信，无需交换机配合，适合快速验证环境兼容性。

修改配置示例（/etc/modprobe.d/bonding.conf）：

options bonding mode=1 miimon=100

然后重新加载模块并重建bond0接口。

三、故障定位流程图：判断问题是源于模式不匹配还是驱动缺陷

graph TD A[网络中断] --> B{bond0是否存在?} B -- 否 --> C[检查modprobe bonding] B -- 是 --> D[查看/proc/net/bonding/bond0] D --> E{Slave状态正常?} E -- 否 --> F[检查网卡驱动加载] E -- 是 --> G[确认bonding mode] G --> H{是否为mode=0或mode=4?} H -- 是 --> I[检查交换机是否启用LAG/LACP] H -- 否 --> J[测试mode=1能否恢复] I -- 否 --> K[调整交换机配置或更换mode] J -- 能 --> L[原模式不兼容] J -- 不能 --> M[怀疑底层驱动或硬件问题]

通过上述流程可系统化区分问题是出在协议层配置不当，还是底层驱动未能正确处理数据帧转发。

四、高级诊断：利用ethtool与tcpdump进行链路级验证

在确定配置无误后，需从链路层抓包分析流量走向。使用tcpdump监听bond0及各slave接口：

tcpdump -i bond0 icmp -n
tcpdump -i eth0 arp -e

观察ARP请求是否由正确接口发出，特别是在active-backup模式下，仅active网卡应发送流量。

同时使用ethtool检测链路状态变化响应速度：

ethtool eth0 | grep "Link detected"
ethtool -S eth0 | grep errors

若发现大量rx_crc_errors或tx_dropped，可能是驱动对高速切换处理不佳。

还可通过手动模拟断线测试failover能力：

ip link set eth0 down
sleep 5; ping -c 3 gateway_ip

观察是否能在miimon设定时间内完成切换。

若切换失败且dmesg显示“bonding: link status down for interface”，则可能涉及内核bonding模块bug或驱动不兼容。

五、驱动与内核层面排查：确认硬件抽象层支持完整性

某些老旧或定制网卡驱动存在对NETDEV_CHANGE事件处理缺陷，导致bonding模块无法感知链路状态变更。

检查内核日志以发现潜在驱动问题：

dmesg | grep -i "bond\|error\|failed"

重点关注类似“bonding: slave eth0 failed to get link speed/duplex”信息。

升级网卡驱动至官方推荐版本，或尝试更换ixgbe、igb等主流开源驱动进行对比测试。

对于SR-IOV或虚拟化场景，还需确认VF驱动与PF驱动协同工作正常。

可临时禁用NMI watchdog以排除其对网络中断处理的干扰：

echo 0 > /proc/sys/kernel/nmi_watchdog

最终可通过编译带调试符号的bonding模块，启用详细日志跟踪事件流。