验证聚合流量是否真的分担
聚合把多条物理链路合成一条逻辑链路，但流量走不走得开取决于哈希算法：同一条数据流（固定源目 IP 与端口）永远走同一条成员，只有多条不同的流才会分散。因此「配了聚合」和「带宽翻倍」是两件事。验证方法是多次采样各成员的实时速率与包数增量，看它们是否大致均衡。
基本信息
| 适用平台 | 全部设备（华为 VRP、思科 IOS、H3C Comware） |
|---|---|
| 查看方式 | 逐成员查看接口速率（5 分钟速率 / 300 秒速率） |
| 哈希依据 | 常见为源目 MAC、源目 IP、源目端口组合，各平台可选模式不同 |
| 单流特性 | 单条流只走一个成员，单流测试无法验证分担 |
| 判读标准 | 多个不同流并发时各成员速率应大致接近 |
典型使用场景
- 扩容验收：新增成员后确认带宽是否真的提升
- 性能异常定位：业务速率上不去，怀疑流量挤在同一个成员上
- 大文件传输：单流场景下的速率瓶颈解释与预期管理
- 哈希模式调整：更换哈希依据后重新验证分担效果
- 定期巡检：把成员流量分布纳入巡检项，提前发现严重倾斜
华为 VRP
华为 VRP
<Huawei> display interface GigabitEthernet 0/0/1 | include rate
<Huawei> display interface GigabitEthernet 0/0/2 | include rate
# 多执行几次，对比各成员口 Last 300 seconds 速率是否接近
<Huawei> display eth-trunk 1 verbose # 结合成员的选中状态与流量信息
! 严重倾斜时检查哈希模式：display eth-trunk 1 相关配置思科 IOS
思科 IOS
SW-A# show interfaces GigabitEthernet1/0/1 | include rate
SW-A# show interfaces GigabitEthernet1/0/2 | include rate
SW-A# show etherchannel load-balance # 查看当前哈希依据与算法
SW-A# show etherchannel summary # 成员选中状态
! 修改模式：port-channel load-balance <模式>H3C Comware
H3C Comware
<H3C> display interface GigabitEthernet 1/0/1 | include rate
<H3C> display interface GigabitEthernet 1/0/2 | include rate
<H3C> display link-aggregation verbose # 成员状态与聚合信息
<H3C> display link-aggregation load-sharing mode # 查看当前分担模式
! 改模式：link-aggregation load-sharing mode 相关命令判读方法
| 观察 | 判读 | 可能原因 |
|---|---|---|
| 各成员速率接近 | 分担正常 | 无需处理 |
| 一条接近满载、其余接近空闲 | 严重倾斜 | 业务流量本身单一，或哈希依据不合适 |
| 多次采样后比例稳定 | 负载特征性分布 | 取决于流数量与哈希算法，属正常现象 |
| 成员速率均为 0 | 流量没走这条聚合 | 生成树阻塞或路由未指向 |
验证必须要有多条不同的流才有参考价值：用多台客户端同时向多台服务器传输，或使用多源多目的的压力测试工具。单条大流测试时发现「带宽只有一条成员的量」，这是哈希机制的必然结果，不是配置错误。