聚合链路丢包的两条主线
聚合口丢包的根因基本分两类：一是分布不均——哈希把大部分会话导向同一条成员，这条成员拥塞丢包，其余成员却很闲；二是单成员链路质量差——错包与 CRC 计数持续增长，帧在物理层就已经损坏。两者的现象都是丢包，但证据位置不同：前者看成员流量计数，后者看错包计数。
基本信息
| 观察位置 | 各成员接口的流量计数与错包计数 |
|---|---|
| 分布不均特征 | 丢包与业务时段相关，高峰丢、闲时好 |
| 链路质量特征 | 持续少量丢包，CRC 与错包计数稳定增长 |
| 常用命令 | 华为 display interface / display eth-trunk N verbose；Cisco show interfaces |
| 处理方向 | 分布问题调整哈希因子，质量问题更换光纤或模块 |
典型使用场景
- 业务高峰期卡顿：判断是否为哈希极化造成的单成员拥塞
- 少数服务器访问异常：定位是否落在特定的成员链路上
- 更换光纤模块前后：对比错包计数是否归零
- 扩容验收：确认新增成员后分布是否变均匀
- 跨机房长距离链路：光衰与错包问题的常态化监测
排查命令
排查命令
display interface GigabitEthernet0/0/1 # 成员一：流量与错包计数
display interface GigabitEthernet0/0/2 # 成员二：对比两次读数
display eth-trunk 1 verbose # 成员分布与活动状态
display interface Eth-Trunk 1 # 聚合口整体丢包情况
# Cisco
show interfaces GigabitEthernet1/0/1 | include error
show etherchannel summary # 确认成员是否都在活动状态
# 关键：按时间点采两次计数，看增量比例与错包增长现象与判读
| 现象 | 更可能的原因 | 验证方式 |
|---|---|---|
| 高峰丢、闲时好 | 哈希极化导致单成员拥塞 | 对比各成员流量增量比例 |
| 持续少量丢包 | 链路质量差（光衰、模块劣化） | 查看 CRC 与错包计数增长 |
| 丢包集中在少数连接 | 这些会话哈希到同一成员 | 抽样核对会话与成员对应关系 |
| 聚合口丢包而成员不丢 | 聚合层排队或对端拥塞 | 同时查看两端聚合口计数 |
『高峰丢、闲时好』优先怀疑哈希极化，『持续少量丢』优先怀疑链路质量。先按这个分岔判断，再决定是调哈希因子还是换光纤，能省掉大量无效排查。
只用 ping 测丢包会漏掉真实问题：拥塞丢包往往只出现在大流量时段，必须用业务时段的接口计数增量来验证。
计数采集的规范
把每个成员接口的收发包、错包、CRC 计数按两次时间点采集并做差，差值才是有效信息。单次读数既不能说明趋势，也无法区分是历史残留的累积值还是当前正在发生的问题。