mode=1（active-backup）是冗余首选，因其不依赖交换机、驱动兼容性好、故障切换可靠；需正确配置bonding_opts、master/slave参数，验证须查/proc/net/bonding/bond0状态并物理拔线测试。
mode=1 是最稳妥的选择，只要物理网卡能通电、驱动正常，不依赖交换机配置，就能实现秒级故障切换。其他模式要么要配交换机，要么对驱动有硬性要求，一配错就看似正常、实则流量只走单卡甚至丢包。
为什么 mode=1（active-backup）是冗余首选
它不靠负载分发，只靠主备状态机做链路健康判断，所以容错逻辑干净、触发可靠。
常见错误是以为“bond0 up 就代表冗余生效”，其实得看 /proc/net/bonding/bond0 里是否明确标出 Currently Active Slave: eth0 和 Slave Interface: eth1 (down) 这类状态行。
若两块卡都显示 Up 但只有一个是 Currently Active Slave，说明冗余机制已就位；如果两个都是 Active 或都 Down，那配置肯定有问题。
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：在虚拟网络编辑器里「断开连接」（不是关机或禁用网卡）
• 检查切换是否发生：watch -n1 'cat /proc/net/bonding/bond0 | grep "Currently Active Slave:"'
• 正常响应时间应在 300ms 内，延迟超过 1s 说明 miimon=100 没生效，可能是内核模块没加载或参数拼错
容易被忽略的 MTU 和 syslog 诊断点
很多人调通后遇到间歇性超时或大文件传输失败，最后发现是 ifconfig bond0 显示的 MTU 比 eth0 和 eth1 小——这会导致 TCP 分片异常。
务必统一：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 输出更早暴露硬件或驱动问题
