• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

10508X-V+端口队列2丢包

1小时前提问
  • 0关注
  • 0收藏,20浏览
粉丝:0人 关注:1人

问题描述:

 

 .1.3.6.1.2.1.192.1.2.1.2.192921 = INTEGER: 23   .1.3.6.1.2.1.192.1.2.1.3.192921 = INTEGER: 4    .1.3.6.1.2.1.192.1.2.1.4.192921 = Gauge32: 1     .1.3.6.1.2.1.192.1.2.1.5.192921 = Hex-STRING: 07 EA 07 11 0A 0A 27 00 00 00 2B 08 00    .1.3.6.1.2.1.192.1.2.1.6.192921 = STRING: "CS01-100Rack"   .1.3.6.1.2.1.192.1.2.1.7.192921 = STRING: "IFNET"        .1.3.6.1.2.1.192.1.2.1.8.192921 = STRING: "-"   .1.3.6.1.2.1.192.1.2.1.9.192921 = STRING: "IF_EGRESS_DROP_RECOVER"      .1.3.6.1.2.1.192.1.2.1.10.192921 = Gauge32: 2   .1.3.6.1.2.1.192.1.2.1.11.192921 = STRING: "Packet loss recovers in queue 2 of GigabitEthernet5/0/5."    .1.3.6.1.2.1.192.1.3.1.4.192921.1.12.83.121.115.76.111.99.64.50.53.53.48.54.4.83.108.111.116 = STRING: "5"      .1.3.6.1.2.1.192.1.3.1.4.192921.2.12.83.121.115.76.111.99.64.50.53.53.48.54.3.77.68.67 = STRING: "1"

这里的队列2是啥意思,看端口下面也没有多大流量,是瞬间的送的报文数量太大导致的丢包吗,怎么排查

3 个回答
粉丝:12人 关注:9人

排查步骤及命令
1. 定位丢包端口:通过OID反查端口,执行display snmp mib ifmib ifindex找到ifIndex=192921对应的物理端口(如Ten-GigabitEthernet X/X/X)。
2. 查看端口队列2统计:display qos queue statistics interface [端口] queue 2,确认队列2的丢包类型(如尾部丢弃、WRED丢包)及丢包数量。
3. 检查队列2配置:display qos queue configuration interface [端口] queue 2,查看队列调度方式(SP/WDRR)、队列长度、WRED参数。
4. 分析端口流量:display interface [端口]查看端口总带宽利用率;display qos flow statistics interface [端口]查看各优先级流量占比,确认队列2承载的流量是否超过队列带宽/缓存。
5. 检查QoS映射:display qos map-table dscp-lp或display qos map-table 8021p-lp,确认业务流量是否被正确映射到队列2。
6. 临时调整验证:若为缓存不足,临时增大队列2缓存qos queue 2 buffer [百分比];若为调度不足,调整队列权重qos wdrr queue 2 weight [权重值],观察丢包是否缓解。
关键说明
零段丢包通常因队列缓存耗尽或调度优先级不足导致,需结合流量模型调整队列配置或优化业务流量映射。

没有配置QOS映射,很多命令不支持,队列2是指的啥, queue-statistics 内容太多,回复在下面

zhiliao_H9EnVh 发表时间:51分钟前 更多>>

没有配置QOS映射,很多命令不支持,队列2是指的啥, queue-statistics 内容太多,回复在下面

zhiliao_H9EnVh 发表时间:51分钟前
zhiliao_H9EnVh 知了小白
粉丝:0人 关注:1人

dis qos queue-statistics interface GigabitEthernet 5/0/5 outbound
Interface: GigabitEthernet5/0/5
Direction: outbound
Forwarded: 2833844554 packets, 3171661322646 bytes
Dropped: 154268 packets, 210715651 bytes
Queue 0
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 1
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 2
Forwarded: 2833381290 packets, 3171626619459 bytes, 10391 pps, 91133744 bps
Dropped: 154268 packets, 210715651 bytes
Current queue length: 5 packets
Queue 3
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 4
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 5
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 6
Forwarded: 24891 packets, 3604196 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 7
Forwarded: 438373 packets, 31098991 bytes, 2 pps, 1888 bps
Dropped: 0 packets, 0 bytes


端口出方向利用率只有10%

粉丝:23人 关注:2人

一、告警报文拆解
1. 关键字段翻译解读
plaintext
IF_EGRESS_DROP_RECOVER
Packet loss recovers in queue 2 of GigabitEthernet5/0/5
EGRESS:出端口方向(端口发送侧队列)
queue 2:交换机硬件 8 个本地优先级队列(0~7),队列 2 对应本地优先级 2(Local-precedence 2)
DROP_RECOVER:队列 2 曾经发生拥塞丢包,现在拥塞缓解、恢复转发;SNMP 上报的是「丢包恢复告警」,说明历史发生过瞬时拥塞丢包
端口:GigabitEthernet 5/0/5
2. 8 队列默认映射关系(S10500V + 全局硬件调度)
S10508X-V+ 每端口 8 个出队列,默认 DSCP→本地优先级(队列号)映射:
表格
硬件队列号 本地优先级 Local-prec 默认承载业务
Queue0 0 低优先级、大文件下载、日志、后台流量
Queue1 1 普通上网、视频浏览
Queue2 2 普通业务、办公内网业务(你丢包队列)
Queue3 3 办公语音、普通交互业务
Queue4 4 视频会议、重要交互业务
Queue5 5 语音电话、实时音频
Queue6 6 重要控制信令、设备管理
Queue7 7 最高优先级,BGP/OSPF/STP 等协议报文
队列 2 属于中等优先级业务队列,内网办公、业务系统流量默认进入该队列。
二、丢包核心成因(你疑惑 “流量不大但丢包”)
1. 瞬时突发流量(最匹配你的现象)
端口平均带宽占用低,但存在毫秒级流量尖峰:
交换机硬件队列缓冲区有限,瞬时报文速率超过端口线速 / 队列调度转发能力,队列瞬间填满触发尾丢弃;
业务表现:平时流量平缓,批量导出数据、数据库同步、文件拷贝、批量业务查询时瞬间打满队列 2。
平均流量看接口统计看不出异常,只有瞬时峰值会触发队列丢包。
2. 调度权重分配不合理
默认队列调度为 WRR 加权轮询,若队列 2 分配的调度带宽权重偏小,同端口高优先级队列抢占转发资源,队列 2 少量突发就会被挤压丢包。
3. 端口缓冲区 buffer 分配不足
单板每端口共享 / 独享缓存资源,多端口同时突发时,队列 2 可用 buffer 被其他端口抢占,瞬时溢出丢包。
4. 业务流量标记错误,大量业务全部涌入队列 2
所有业务报文 DSCP 值统一映射到本地优先级 2,没有分层,流量全部挤在同一个队列,极易拥塞。
三、分步完整排查流程
步骤 1:确认端口实时、历史队列丢包统计
bash
运行
# 查看5/0/5端口所有队列出方向丢弃计数(最核心命令)
display qos queue statistics interface GigabitEthernet 5/0/5

# 查看端口总流量、峰值速率
display interface GigabitEthernet 5/0/5
重点看:Queue 2 Drop 数值是否持续上涨;如果仅少量计数、不再新增,就是瞬时突发导致。
步骤 2:查看报文 DSCP/802.1P 标记,确认哪些流量进队列 2
bash
运行
# 查看全局DSCP→本地优先级映射表
display qos map dscp local-precedence

# 抓包/镜像观察端口入站报文DSCP值
mirroring-group 1 local
mirroring-group 1 mirroring-port GigabitEthernet 5/0/5 inbound both
mirroring-group 1 monitor-port XXXX
如果大量业务报文 DSCP 都映射到 local-prec 2,所有流量挤在队列 2 是丢包主因。
步骤 3:查看队列 WRR 调度权重配置
bash
运行
display current-configuration interface GigabitEthernet 5/0/5 | include qos wrr
display qos wrr interface GigabitEthernet 5/0/5
默认 WRR 权重 1:2:4:8:16:32:64:128(队列 0~7),队列 2 权重仅 4,转发带宽占比低,突发极易丢包。
步骤 4:查看单板缓存资源占用
bash
运行
display buffer usage slot 5
display buffer pool slot 5
若同板卡多个端口同时存在突发,共享 buffer 耗尽会加剧队列 2 瞬时丢包。
步骤 5:定位产生突发的业务源
查看端口 MAC 地址表,确认终端;
配置流量统计 ACL,匹配 DSCP 对应队列 2 的流量,定位业务源 IP:
bash
运行
acl number 4000
rule permit ip dscp X # 映射到队列2的DSCP值
traffic classifier test operator and
if-match acl 4000
traffic behavior test statistic
qos policy test
classifier test behavior test
interface GigabitEthernet 5/0/5
qos apply policy test inbound
display qos policy interface GigabitEthernet 5/0/5
四、优化解决办法(按落地优先级)
方案 1:调大 Queue2 的 WRR 调度权重(推荐,不改动业务标记)
增加队列 2 转发带宽占比,缓解突发挤压丢包:
bash
运行
interface GigabitEthernet 5/0/5
qos wrr queue 2 weight 16
# 全局统一配置(整机所有端口生效)
qos wrr queue 2 weight 16
方案 2:分层流量标记,分流队列 2 压力
修改业务报文 DSCP 标记,把大流量离线业务映射到低优先级队列 0,核心业务保留队列 2,分流拥堵:
终端 / 服务器端修改报文 DSCP;
交换机入端口重标记:
bash
运行
traffic behavior mark0 remark dscp 0
qos policy split
classifier 离线流量ACL behavior mark0
interface GigabitEthernet 5/0/5
qos apply policy split inbound
方案 3:扩大端口队列缓冲区(硬件 buffer 扩容)
bash
运行
# 提升端口单队列最大缓存长度(单位:报文个数)
interface GigabitEthernet 5/0/5
qos queue 2 buffer maximum 10240
方案 4:对离线大流量配置队列 2 尾部丢弃阈值 / 限速
批量备份、文件同步等大流量做端口限速,避免瞬时打满队列:
bash
运行
interface GigabitEthernet 5/0/5
qos carl 1 source-ip-address range 大流量源IP
traffic classifier limit
if-match carl 1
traffic behavior limit
car cir 500000 cbs 100000 ebs 0 red discard
qos policy limit
classifier limit behavior limit
qos apply policy limit inbound
五、补充关键说明
告警IF_EGRESS_DROP_RECOVER是恢复告警,不是实时持续丢包,仅代表曾经发生瞬时拥塞;
接口总带宽使用率低≠无丢包,以太网是脉冲式突发流量,毫秒级峰值是队列丢包最常见诱因;
队列 2 为普通业务承载队列,企业内网数据库、文件传输最容易在此队列产生瞬时峰值丢包。

编辑答案

你正在编辑答案

如果你要对问题或其他回答进行点评或询问,请使用评论功能。

分享扩散:

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作

举报

×

侵犯我的权益 >
对根叔社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明