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

无

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

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

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去看了，对于多个节点不行的问题，那更应该倾向于性能不足，收集一下softcar、coscar、display udp verbose就差不多可以确认是不是有拥塞了。