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

S12508X-AF出现snmp节点长时间超时问题

2020-05-25 发表
  • 0关注 ,697浏览
粉丝:2人 关注:2人

组网及说明

问题描述

客户网管平台监控网络设备出入流量,有两台S125(分别是10.50.8.110.50.8.2)出现多个断点,一条线表示一个接口,图中乱线应该是一段时间没有收到response,客户在服务器抓包发现有一些request会有没有响应的情况,在抓包期间,客户ping测试都是正常的,说明网络连通性没问题。


从客户监控来看,是49日下午出现的问题,当时客户动作是增加了一个采集器,后来关掉新增采集器也不能恢复。

过程分析

1、从现场抓包来看,确实是我们设备没有回包,但并不是如现场一般长时间没有回包。

 

他们网管侧超时时间是15S,从下面这个流来看,是超过15S没有响应然后就再发一个。


并且看下面这个流,两次都没回应,就没有再request了,看抓包结束时间,应该还有2分多钟,按理说网管平台会继续发,所以推测他们的机制是两次没回应就不继续发了。


2、接下来让一线收集信息,标黄数值没有增长。

 

[GM_NHZ01_M08_R02C06_INT_NE_S12504_ICR_1-probe]debug rxtx coscar show slot 2

Index        RcvPkt           DisPkt           RcvPkt/s     DisPkt/s     PPS

0            7012720          0                0            0            1000 1            97786805         29338            5            0            1000

 

以上标黄没有增长,需要注意的是,看这个是因为,snmp报文和icmp都是走这个队列1,当环境中有较多的icmp报文时,是有可能会影响这个snmp报文的。

 

同时查看softcar,但是并没有超限速丢包的情况。

 

====debug rxtx coscar show chassis 1 slot 6====

 

Index        RcvPkt           DisPkt           RcvPkt/s     DisPkt/s     PPS

0            322504           0                0            0            1000

1            748495337        2525             75           0            1000

 

====debug rxtx coscar show chassis 1 slot 8====

 

Index        RcvPkt           DisPkt           RcvPkt/s     DisPkt/s     PPS

0            262038           0                0            0            1000

1            1183741921       31140            98           0            1000

 

14号诊断:

------------------------------------------------------------------------------------------------

====debug rxtx coscar show chassis 1 slot 6====

 

Index        RcvPkt           DisPkt           RcvPkt/s     DisPkt/s     PPS

0            325730           0                0            0            1000

1            773006768        2525             74           0            1000

 

====debug rxtx coscar show chassis 1 slot 8====

 

Index        RcvPkt           DisPkt           RcvPkt/s     DisPkt/s     PPS

0            264721           0                0            0            1000

1            1228285052       31140            57           0            1000

 

3、最后查看display udp verbose,发现snmp有拥塞丢包增长的情况。

 

Location: slot 0 cpu 0

Creator: snmpd[3989920]

State: N/A

Options: SO_REUSEPORT

 Error: 0

Receiving buffer(cc/hiwat/lowat/drop/state): 41702 / 42240 / 1 / 351079315 / N/A

Sending buffer(cc/hiwat/lowat/state): 0 / 78 / 57 / N/A

Type: 2

Protocol: 17

Connection info: Src = 0.0.0.0:161, Dst = 0.0.0.0:0

Inpcb flags: INP_RECVDSTADDR INP_REUSEPORT INP_SYNCPCB

 Inpcb extflag: N/A

Inpcb vflag: INP_IPV4

 TTL: 255(minimum TTL: 0)

Send VRF: 0xffff

Receive VRF: 0xffff

 

以上cc代表的是buffer中实时存在的缓存的snmp报文个数,hiwat代表的是当前芯片支持缓存的snmp报文个数,drop代表历史丢包数值,显然,现场已经发生了snmp的拥塞丢包。



1、首先我们要知道snmp从接口收到请求,到处理这个报文的全过程是什么样的:

 

报文进入接口,如果无错包之类的,会经过单板copp限速的限制,但是大多数的问题都不在copp限速这里,然后进入单板的softcar限速,单板softcar,一般核心是500,数据中心是900,最后统一交给主控CPU处理,我们的snmp是单进程处理的也就是一个包一个包逐个处理,当前面的某个特殊节点包耗时较长时,就会影响后面的节点处理,这个问题园区核心有一个特殊节点存在这个情况。

 

到了这一步,如果要看是哪个节点慢,就要开区debug snmp去看了,我们读取节点,有的需要下芯片驱动去读取,有的一些软边直接平台就读取,下芯片的就会慢一些。

 

2、我们snmp处理的瓶颈主要还是在cpu单进程这一块,单板softcar即使可以放过,cpu这里也处理不过来,就比如这次的问题,查看所有接口板的softcar收到的snmp报文,都没有超限速,而且所有接口板的snmp报文加起来,还不到500,因此,从这里可以看出,cpu处理的snmp报文能力还是比较低的。

 

3、客户和一线可能会关注我们cpu处理报文每秒的上限值是多少?是否可以手动调大?这个上限值我们无法给出准确数值,但是buffer大小是固定的,并且这个只和cpu处理能力相关,无法手工调大。

 

解决方法

鉴于此次的故障现象,后续处理相关snmp问题的时候,需要遵循以下几点,客户已帮助快速定位此类问题:

1、多问,要问清楚故障现象,是单个节点不行,还是多个节点不行?是偶尔不行,还是一直不行?是新上线,还是用来一段时间,是刚刚出现,还是早就有?有没有做过什么动作?其他设备有没有这种情况?有几个网管在读取?

 

2、了解到足够信息后,就可以做到心中有数,大概知道问题方向,对于单个节点不行的,处理mib-style的问题,只能debug去看了,对于多个节点不行的问题,那更应该倾向于性能不足,收集一下softcarcoscardisplay udp verbose就差不多可以确认是不是有拥塞了。

0 个评论

该案例暂时没有网友评论

编辑评论

举报

×

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

侵犯我的权益

×

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

泄露了我的隐私

×

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

侵犯了我企业的权益

×

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

抄袭了我的内容

×

原文链接或出处

诽谤我

×

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

对根叔知了社区有害的内容

×

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

不规范转载

×

举报说明

提出建议

    +

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

确定

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