active-backup模式适合交换机不支持聚合的上行冗余场景，但failover慢、mac变更、arp失效；802.3ad需两端lacp参数严格匹配，否则聚合失败；二者均无法提升单tcp流速，仅支持多连接并发带宽叠加。
active-backup 模式到底适不适合做服务器上行链路冗余
适合，但仅限于交换机不支持或不允许配置聚合的场景。它本质是靠内核判断链路是否 up/down 来切换主备，不依赖对端配合。
常见错误现象：link failure 后 failover 慢（默认 100ms 探测间隔）、bond0 的 MAC 地址在切换时会变，导致部分 ARP 缓存失效、三层设备可能丢包几秒。
- 必须设
miimon=100（不能只靠arp_interval，后者依赖 IP 层，链路断开时可能来不及响应） - 交换机端口必须各自独立配置为 access 或 trunk，**不能**配成静态聚合组，否则可能因 STP 或 LACP 报文冲突导致端口被 block
- 如果业务要求零感知切换（如 VoIP、实时数据库心跳），这个模式扛不住——failover 期间 TCP 连接大概率重置
802.3ad（LACP）为什么一配就 down，或者 load balance 完全不生效
因为两端协商失败或负载策略不匹配。LACP 不是“开了就自动均衡”，它需要交换机侧显式启用、参数对齐、且流量哈希策略一致。
典型错误现象：cat /proc/net/bonding/bond0 显示 LACP partner 为空、Aggregator ID 为 0、所有 slave 状态为 Unselected；或虽显示 Selected，但所有流量只走第一个接口。
- 交换机侧必须开启 LACP，并设为
active模式（不能是passive单边等） - Linux 侧必须用
mode=802.3ad+xmit_hash_policy=layer2+3（默认layer2只看 MAC，所有流量哈希到同一子接口） - 确认交换机 LACP 超时设置（
short对应 3s，long对应 90s），Linux 默认用slow，若交换机设short，需加lacp_rate=1
为什么 active-backup 和 802.3ad 都不能提升单 TCP 流的速度
因为 bonding 层不拆包、不跨接口调度单个 socket 的数据流。每个 TCP 连接绑定到一个 slave 接口，带宽上限就是单口物理速率。
这不是配置错，是设计如此。想突破单流瓶颈，得靠应用层改逻辑（如多连接池）、或上层用 ECMP + 多路径路由，而不是指望 bonding。
-
mode=balance-tlb或balance-alb也做不到——它们只是按连接（connection）分发，不是按包（packet） - 如果你看到某文档说 “bonding 能叠加带宽”，它默认指多客户端并发总吞吐，不是单客户端体验
- 测试时别用
iperf3 -c xxx单流压测，要用-P 4模拟多个并发流，才能看出 aggregate 效果
交换机型号老旧或管理权限受限时，该选哪个模式更稳
选 active-backup。它对交换机零要求，只要物理链路通，就能工作；而 802.3ad 一旦协商失败，整个 bond 就瘫痪。
容易被忽略的点：有些白牌交换机宣称支持 LACP，但实际只实现前几个 TLV 字段，Linux 内核收不到完整 LACPDU，直接放弃聚合——此时 active-backup 反而是唯一能用的冗余方案。
- 检查手段：
tcpdump -i eth0 lacp看有没有双向 LACP 报文；没有的话，别硬调 802.3ad -
active-backup下记得关掉交换机 STP（或至少设为 portfast），否则主备切换时可能触发 STP 收敛延迟 - 如果连
miimon探测都不可靠（比如某些光纤收发器不报 link down），就得上arp_ip_target做三层探测，但代价是增加网关负担
