接口与链路73 条

两端成员数不一致的影响与处理

一端 4 成员、一端 2 成员（或对端被动拼成 2 条）时，聚合仍可能 up：容量按较小端算、流量分布不均衡；发现后应尽快补齐或调整。

两端成员数不一致是什么

一端 4 条成员、另一端 2 条（或对端被动拼成更少成员）时，聚合口仍然可能正常 up：容量按成员较少的一端生效，两端各按自己的哈希基数分担流量，比例完全对不上。静态聚合尤其不会有任何告警。这种状态在割接中途、扩容只做了一半、或者对端是非受控设备时最常见，表现为带宽不达预期、单成员负载偏高。

适用平台	全部聚合场景（静态与动态都可能出现）
典型成因	扩容只做一端、割接中途、对端成员被动减少
直接影响	容量按小端计算，流量分担比例不对称
排查命令	display eth-trunk / show etherchannel summary / display link-aggregation verbose
处理原则	两端逐口对账，而不是只看数量

<Huawei> display eth-trunk 1
# 导出后与对端逐口核对成员列表，而不是只比数量

SW-A# show etherchannel summary
# 对端侧同步执行，比对 (P) 成员数量与端口编号
# 数量不一致时，实际容量按成员较少的一端生效

<H3C> display link-aggregation verbose
# 逐成员核对两端 Selected 集合，注意端口对应关系

成员数不一致通常不会有任何告警，静态聚合尤其安静。可靠做法是把两端成员对账变成例行动作：记录每端 Selected 成员列表与数量，上线前后各做一次，任何变更后立即更新基线，把对账单当作资产而不是临时截图。

还有一种更隐蔽的情况：两端数量相同但成员不同，或一端是跨设备聚合、另一端是单设备聚合。数量对账漏掉这类差异，单设备故障的影响面就会被低估。

‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌