聚合口为什么看起来正常却不好用
链路聚合把多个物理口合成一个逻辑口，前提是两端协商方式一致并成功建立聚合关系。实际故障大多不是链路断，而是「聚合口状态是 up，但成员口没真正加入聚合」：服务器配置了动态聚合而交换机是静态配置，或反过来，双方各说各话，流量只走一个成员口甚至引发乱序。所以检查的第一件事不是速率，而是协商状态与成员口归属。
基本信息
| 适用平台 | Linux 的 bonding 或 team、交换机侧的链路聚合 |
|---|---|
| 常见模式 | 802.3ad 动态聚合（LACP）、静态聚合、active-backup 主备 |
| 查看入口 | /proc/net/bonding 目录下的聚合接口文件 |
| 关键字段 | 聚合模式、成员口状态、聚合器编号、本端与对端状态 |
| 验速要点 | 单流只走一个成员口，验证带宽必须用多流 |
典型使用场景
- 聚合口跑不满带宽：确认是否单流受限而非聚合失效
- 成员口数量对不上：核对两端实际加入聚合的端口
- 链路改造后偶发丢包：检查两端聚合模式是否一致
- 故障切换验证：拔掉一个成员口，观察流量是否平滑切换
- 上线验收：确认聚合可用带宽与预期一致
Linux Bond 详查
Linux Bond 详查
cat /proc/net/bonding/bond0
# 关注：Bonding Mode（如 802.3ad）、MII Status、Slave Interface、Aggregator ID、Actor 与 Partner 状态
ethtool bond0 | grep -E 'Speed|Duplex' # 聚合口速率
ip -d link show bond0 | head # 链路层细节
cat /sys/class/net/bond0/bonding/slaves # 成员口清单
iperf3 -c 10.0.0.5 -P 4 # 用多流验证聚合带宽静态与动态聚合对照
静态与动态聚合对照
常见错误：服务器配 802.3ad（LACP），交换机端口是静态聚合 → 协商不成功
常见错误：交换机配 LACP，服务器配 balance-rr 或静态 → 哈希不一致造成乱序或单口饱和
Cisco: 接口下 channel-group N mode active|passive|on # active 为动态
华为: 接口下加入 eth-trunk 并设置 mode lacp-static 或 mode manual现象与归因
| 现象 | 可能原因 | 验证方式 |
|---|---|---|
| 聚合口 up 但吞吐等于单口 | 成员口未真正加入或单流哈希 | 查成员口状态并用多流测试 |
| 成员口状态为备用 | 协商未完成或模式不匹配 | 核对两端聚合模式与端口配置 |
| 流量分布严重倾斜 | 成员口速率不一致或哈希单一 | 核对成员口速率与哈希算法 |
| 偶发乱序与重传 | 两端聚合模式不一致 | 对比两端配置与哈希策略 |
| 拔口后业务中断 | 实际是主备模式而非负载分担 | 确认聚合模式与故障切换行为 |
单流吞吐不提升是正常现象：聚合按流哈希分配，单条 TCP 连接只走一个成员口，验证带宽要用多流并行测试。