排查bonding故障需分层验证：查物理链路（ethtool、/proc/net/bonding/bond0中link failure count）、看bond0状态（mii status、current slave）、验流量路径（watch /proc/net/dev、ifconfig down模拟切换）、对交换机配置（lacp匹配、lag成员状态、hash策略兼容）。
排查 Bonding 网卡链路故障，不能只看“灯亮”或“ping 通”，关键要分层验证：物理链路是否稳定、绑定逻辑是否生效、主备切换是否正常、交换机协同是否匹配。下面从四个实操角度展开。
查物理链路状态（每块 slave 网卡）
先确认每张物理网卡本身有没有隐性故障：
- 用 ethtool eth0 和 ethtool eth1 分别检查：关注 Link detected: yes、Speed（是否协商到预期速率）、rx_errors/tx_errors（非零需警惕）
- 对比两块网卡的 Link Failure Count：执行 cat /proc/net/bonding/bond0，若某 slave 的该计数持续增长，说明链路反复震荡，但未彻底 down，容易被忽略
- 注意光模块温度、收发光功率（如支持）：部分驱动可通过 ethtool -m eth0 查看，异常值常导致间歇性丢包
看绑定整体状态（bond0 运行时表现）
核心是读取内核暴露的实时绑定信息：
- 运行 cat /proc/net/bonding/bond0：重点看 Bonding Mode 是否符合预期（如 mode=1 应只有一块 active），MII Status 是否均为 up，Current Slave 是否合理切换
- 检查 Slave Interface 下的 Link Failure Count 和 Up Delay/Down Delay：数值过大说明链路抖动频繁，可能源于交换机端口 flapping 或线缆接触不良
- 配合 ip link show bond0 和 cat /sys/class/net/bond0/bonding/slaves，确认 slave 是否真被纳入绑定，而非仅配置文件存在
验流量路径与切换行为
判断绑定是否真正起作用，不能只看状态，要看实际转发：
- 用 watch -n1 'cat /proc/net/dev | grep -E "eth0|eth1|bond0"' 实时观察 RX/TX 流量：在 active-backup 模式下，备用网卡应几乎无流量；在 balance-rr 或 802.3ad 模式下，两块网卡应有相近计数
- 手动模拟故障：ifconfig eth0 down，观察 bond0 是否秒级切换，ping -f 网关 是否中断超过 1 秒（miimon 默认 100ms，超时通常意味着配置延迟参数不合理）
- 抓包验证：在交换机侧或服务器上用 tcpdump -i eth0 icmp 和 tcpdump -i eth1 icmp 对比，确认故障注入后流量是否真实迁移到另一接口
对交换机侧做一致性校验
Linux bonding 不是孤立运行的，必须和交换机配置对齐：
- 确认交换机端口是否启用对应聚合模式：mode=1（active-backup）无需交换机配合；mode=4（802.3ad）必须两端都开 LACP，且系统 ID、key、actor/partner 状态需匹配（cat /proc/net/bonding/bond0 中有详细字段）
- 检查交换机端口聚合组（LAG）成员状态：是否全为 Selected？有无 Standby 或 Unselected 成员？后者常因 speed/duplex 不一致或 LACP timeout 参数不匹配导致
- 核对 HASH 策略：Linux 的 xmit_hash_policy 与交换机的负载分担算法（如 src-dst-ip）是否兼容，否则会出现单边流量倾斜
