mode=1是唯一无需交换机配合、驱动兼容性好、故障切换可靠的冗余方案；它通过主备状态机检测链路健康，拔线后300ms内完成切换，不依赖LACP、MAC修改或特定芯片，配置简单且容错逻辑干净。
mode=1是唯一能绕过交换机、驱动兼容性好、故障切换可靠的冗余方案。其他模式要么依赖交换机配置，要么对驱动有硬性要求，一配错就看似正常、实则单卡跑或丢包。
为什么必须用 mode=1(active-backup)
它不靠负载分发，只靠主备状态机做链路健康判断，容错逻辑干净、触发可靠。只要物理网卡通电、驱动加载正常，拔网线后 300ms 内就能切到备卡——不依赖交换机 LACP、不用改 MAC 地址、不挑芯片型号。
-
mode=4(802.3ad) 必须交换机启用LACP，且端口严格配对，否则bond0起得来但只走单卡 -
mode=6(balance-alb) 要求驱动支持ethtool -s eth0修改MAC，老 Realtek 或 VMware 网卡常失败 -
ifconfig bond0显示UP≠ 冗余生效，得看/proc/net/bonding/bond0里是否明确标出Currently Active Slave: eth0和Slave Interface: eth1 (down)
ifcfg 配置三处缺一不可
CentOS/RHEL 7+ 下，ifcfg-bond0 和物理网卡配置必须严格匹配：
-
ifcfg-bond0中必须含TYPE=Bond、BONDING_OPTS="mode=1 miimon=100"（CentOS 7+ 不读/etc/modprobe.d/） -
ifcfg-eth0和ifcfg-eth1中必须同时存在MASTER=bond0和SLAVE=yes，且不能带IPADDR或GATEWAY - 网关只能出现在
ifcfg-bond0，否则系统会生成两条默认路由，导致部分流量走错路径
验证 failover 别用 ifdown eth0
这个命令绕过 bonding 的状态检测逻辑，miimon 无法感知，bond0 仍认为主卡在线，不会切备卡：
- VMware：在虚拟网络编辑器里「断开连接」（不是禁用网卡）
- 响应时间应 ≤ 300ms；超 1s 说明
miimon=100没生效，可能是内核模块没加载或参数拼错 -
MTU不一致是隐形杀手：务必统一执行ip link set dev eth0 mtu 1500、ip link set dev eth1 mtu 1500、ip link set dev bond0 mtu 1500 -
syslog里搜bonding或link status常能抓到"failed to get speed"、"carrier lost"这类底层报错，比ifconfig输出更早暴露硬件或驱动问题
真正决定冗余是否生效的，从来不是配置文件写没写全
而是 /proc/net/bonding/bond0 里那行 Currently Active Slave: 是否实时变化，以及拔线瞬间有没有 carrier lost 日志打出来。MTU 错配、miimon 未生效、物理层 carrier 检测被屏蔽（比如某些虚拟网卡固件），都可能让状态机“看不见”断连。
