S6850 queue 2 IFNET 告警问题

S6850 Queue‑2 出队列丢包告警 IFNET/4/IF_EGRESS_DROP
告警信息：
IFNET/4/IF_EGRESS_DROP:‑Slot=2; Packet loss occurs in queue 2 of GigE2/0/7
IFNET/4/IF_BOARD_EGRESS_DROP 板卡级出口队列丢包；后续有_RECOVER自动恢复。
现象关键点：
监控平台对应时段流量突增；Queue‑2 有 Dropped 计数；当前队列长度 0；
display interface接口统计看不到丢包、错包；
多个接口 slot2 下多个端口同时报 queue2 丢包，之后自动恢复。
1、根因：突发流量，出口队列拥塞（你判断正确）
S6850 QoS 本地队列：
Queue‑0：BE 尽力服务（默认业务）
Queue‑1：AF1
Queue‑2：AF2
Queue‑3：AF3
Queue‑4：AF4
Queue‑5：EF 加速转发（语音）
Queue‑6：CS6（网管协议）
Queue‑7：CS7
Queue2=AF2 队列，一般用于业务重要数据。
告警含义：端口出方向，AF2 队列瞬时突发流量超过调度 / 缓存能力，队列占满，尾部丢弃；突发结束后队列清空，告警恢复。
为什么display interface看不到丢包？
display interface统计的是物理层差错、CRC、冲突等硬件错误丢包；
QoS 队列调度丢弃（WRED / 尾丢弃）属于上层队列逻辑丢弃，不计入 interface 物理接口丢包计数器，只在 queue 子统计和这条 IFNET 告警体现。
这是 H3C 交换机普遍现象，不是 bug。
多端口同时报 queue‑2 丢包：不是端口本身故障，是 slot2 板卡上流量突发，多个端口同时 AF2 队列发生拥塞。Current queue length 为 0，代表告警采集时刻流量已经回落，队列已经排空。
2、对业务会不会产生影响？
取决于进入 Queue‑2 是什么业务：
如果 Queue‑2 承载TCP 业务（数据库、业务访问）：丢包会触发 TCP 重传，表现业务卡顿、时延变大、访问慢，不会直接断业务；突发结束自动恢复。
如果 Queue‑2 承载UDP 业务（视频、实时流）：丢包直接报文丢失，会出现卡顿、花屏。
告警带有_RECOVER，代表拥塞是瞬时突发，不是持续满负载。
只看告警不能直接判定业务受损，需要结合业务系统反馈：业务人员有没有报卡顿慢。如果业务完全无感知，可以短期保持观察，但不能完全放任不管。
3、调整手段（按优先级，从安全到激进）
❗不要上来直接改队列权重，盲目调大 Queue‑2 权重会挤压其他队列，会把丢包转移到其他业务队列，引发新问题。
①第一步：确认哪些流量映射进 Queue‑2
shell
display qos policy interface GigabitEthernet 2/0/7 outbound
display qos map-table dscp
display qos map-table local‑precedence
确认：dscp 值映射到 local‑precedence=2（进入 queue2）的流量是什么业务。
很多现场：业务系统标记 DSCP，把核心业务放入 AF2 (queue2)，突发过来直接拥塞。
方案 A：优化缓存与 WRED（优先推荐，不改动调度权重）
S6850 支持端口出队列 WRED，队列快满的时候做随机提前丢弃，避免队列深度瞬间打满，减少告警风暴。
shell
#进入接口
interface GigabitEthernet 2/0/7
qos wred queue 2
low‑limit 40
high‑limit 70
discard‑percentage 100
含义：队列占用 40% 开始随机丢弃，70% 全部丢弃，避免队列瞬间打满触发硬件告警。
注意：WRED 是提前丢，不是消除丢包，是平滑丢包行为，抑制频繁告警，防止队列深度暴涨。
方案 B：调整队列调度权重（WRR）
S6850 默认 WRR 加权轮询。
查看当前调度：
shell
display qos wrr interface GigabitEthernet 2/0/7
Queue2 权重如果很低，突发流量下分得带宽少，容易丢包。
适度调高 queue‑2 WRR 权重，给 AF2 分配更多输出带宽。
shell
interface GigabitEthernet 2/0/7
qos wrr queue‑group 0
queue 0 weight 25
queue 1 weight 20
queue 2 weight 30 #适度调高，不要设置过大，防止抢占其他业务
queue 3 weight 15
queue 4 weight 10
⚠️风险：调高 queue2 权重，会抢占其他队列的输出带宽，其他队列业务会更容易丢包，全板卡多个端口都出现告警，只改单口没用，需要全局规划。
方案 C：上游入口做流量整形 shaping，限制进入 Queue‑2 的流量
根源解决：在入方向，对标记进入 AF2 的流量做整形，不让过量突发流量进入交换机芯片队列。
出方向缓存始终有限，再大的队列缓存也挡不住无限大的突发流量。
在入接口配置 qos shaping，限制该类业务最大允许带宽，从源头抑制突发。
方案 D：增大队列 buffer（S6850 部分版本支持）
注意：芯片总 buffer 是共享的，给 queue2 加大 buffer，会挤占其他队列缓存，不建议无脑调大。
4、是否可以只保持观察？
✅满足下面全部条件，可以先观察：
告警是瞬时突发，有IF_EGRESS_DROP_RECOVER恢复，不是持续不间断告警；
业务侧没有反馈卡顿、慢、报错；
监控平台流量看是偶发峰值，不是长期打满接口带宽。
⚠️不能只观察的情况：
告警频繁反复，几分钟就报一次；
用户反馈业务慢、数据库访问卡顿；
接口带宽长期利用率 > 70%，属于持续拥塞，不是瞬时突发。
5、补充两个排坑点
多条端口 slot‑2 同时 queue‑2 丢包，优先看该板卡的整体流量，不是单口，是板卡出口共享缓存资源耗尽。
shell
display qos buffer usage slot 2
查看芯片共享缓存占用。
2. 接口display interface看不到丢包是正常现象，QoS 队列丢弃属于逻辑调度丢弃，不属于物理层错误，不要误以为接口没有丢包就是完全没有报文丢失。
操作建议总结
先确认进入 Queue‑2 的是什么业务，确认业务有没有卡顿反馈；业务无异常可以先观察。
优先部署 WRED，平滑队列拥塞，抑制频繁告警，这是改动风险最小的方案。
不要直接粗暴加大 queue2 权重，容易引发其他队列业务受损。
如果峰值流量持续很高，源头入方向做流量整形，根治突发。