原因分析：
1. 配置变更（最常见）： 软件升级后，IRF物理端口的配置可能丢失或未自动转换为聚合模式。旧版可能是静态聚合，新版可能默认是动态聚合或配置未生效，导致两条链路只有一条被选中（Selected），另一条被阻塞（Unselected）。
2. 转发机制变化： 新版本可能修改了IRF的负载分担算法（Hash算法），或者由之前的“本地优先”变成了必须跨设备转发。
3. 端口自协商： 升级后端口可能因光模块或线缆原因协商速率不匹配，被迫退回到单链路。
排查步骤：
1. 查看IRF链路状态：
display irf link
display irf topology
*检查是否所有堆叠物理口都在UP状态。*
2. 查看聚合组状态（关键）：
display link-aggregation verbose
*检查逻辑聚合口（如Bridge-Aggregation 1/2）下的成员端口是否都处于 S (Selected) 状态。如果一个是 S 一个是 U (Unselected)，则确认是聚合问题。*
3. 查看流量统计：
display counters rate interface
*监控是否只有一个端口在跑流量。*
解决建议：
1. 重新绑定聚合： 检查IRF物理端口配置，确保两条链路都正确加入了同一个聚合组。
2. 检查配置一致性： 确保IRF域内两台设备的IRF端口配置（特别是优先级、端口索引）严格对应。
3. 如果是IRF专用线缆/光模块，尝试插拔重启端口。
暂无评论
升级后 IRF 堆叠从原来两条链路分担流量，变成只有单条堆叠链路跑满、另外一条几乎无流量，进而出现拥塞丢包，这是 S7506 (E) 升级版本后很容易碰到的现象，主要是版本升级 IRF 链路缺省 hash 分担算法发生变化，出现 hash 极化，少数情况是堆叠成员端口状态异常。
第一步先确认硬件链路状态
display irf topology
display irf configuration
display interface 堆叠物理口
1、确认两条堆叠物理口都是 UP，都已经正确绑定进 irf‑port，没有端口处于 down、faulty。
如果其中一个物理口实际异常，自然只有一条跑流量，优先排查光模块、光纤。
第二步查看 IRF 堆叠链路当前的分担模式（重点！升级版本经常变更缺省 hash 因子）
display irf‑port load‑sharing mode
老版本和新版本 Comware7 IRF 缺省分担因子不一样，升级完配置没改，但系统默认 hash 策略变了。现网业务流特征如果比较单一（少数大流量长流），就会出现所有流量全部 hash 选到其中一条堆叠链路，另一条空闲，也就是 hash 极化，单条堆叠口直接跑满拥塞丢包H3C。
看堆叠口实际流量确认现象：
display counters rate inbound interface 堆叠物理口
display counters rate outbound interface 堆叠物理口
一条带宽打满，另外一条速率很低，就是分担不均。
解决方法，调整 IRF 堆叠链路 hash 分担因子
系统视图下修改 IRF 全局负载分担，根据业务调整 hash 因子，把源目 IP、源目端口都带上，打散大流量，避免全部打到一条链路上H3C。
system‑view
irf‑port global load‑sharing mode source‑ip destination‑ip source‑port destination‑port
修改完不需要重启 IRF，即时生效；改完再看
display counters rate，观察两条堆叠口流量是否逐步分摊开。
注意：IRF‑port 视图下也可以单独针对某一组堆叠口配置
irf‑port load‑sharing mode，优先级高于全局。
其他排查点
1、确认有没有开启link‑aggregation load‑sharing mode local‑first本地优先转发。跨框聚合 / ECMP 本地优先转发会大量增加 IRF 堆叠链路的转发压力，升级后部分版本缺省行为变化，会把更多业务流量推到 IRF 堆叠链路上，造成堆叠带宽暴涨跑满，业务丢包H3C。
display link‑aggregation load‑sharing mode
2、检查升级过程 IRF 是否完整合并，有没有发生 IRF 分裂后合并异常：
display mad verbose
display irf
3、看接口是否存在拥塞丢包计数：
display interface 堆叠物理口 | include drop
如果堆叠口有 output‑drop，就确认是单条链路带宽占满溢出丢包。
补充踩坑
1、IRF 是逐流 hash 分担，不是逐包，如果业务是少数几条超大流，无论怎么调 hash，都有可能全部落在同一条链路，这是 IRF 堆叠本身机制限制；
2、修改 IRF 分担模式不会影响业务，不需要割接重启；
3、如果调整 hash 后还是严重不均，收集display diagnostic‑information全套信息，联系 400，核对该版本是否有 IRF 分担相关已知 bug。
简单排查顺序小结
- 确认两条堆叠物理端口都是 UP，都绑定进 IRF‑port；
- 看堆叠口速率，确认确实单口跑满；
- 查看
display irf‑port load‑sharing mode确认分担因子； - 修改
irf‑port global load‑sharing mode增加 hash 因子打散流量； - 观察堆叠口流量分布，确认丢包是否消失。
暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论