Linux bonding / teaming 的 active-backup vs 802.3ad 链路聚合场景划分

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 做三层探测，但代价是增加网关负担