某局点S12508X-AFsnmp读取不到接口数据问题

不涉及

设备：S12508X-AF，：S12508X-AF，使用网管软件读取数据，之前网管可以正常读取设备。最近读取不到接口数据。之后测试采用snmpwalk读取，读取snmp慢，主要读取接口信息，cpu温度等，现场有多块接口板满载光模块。

1、和现场确认如下信息：

   （1）现场读取的节是哪几个？怎么读？

主要读取接口信息，cpu温度等，OID节点如下：

.1.3.6.1.4.1.25506.2.6.1.1.1.1.12.415

.1.3.6.1.2.1.31.1.1.1.6,.1.3.6.1.2.1.31.1.1.1.10

.1.3.6.1.2.1.2.2.1.13,.1.3.6.1.2.1.2.2.1.19     

.1.3.6.1.2.1.2.2.1.14,.1.3.6.1.2.1.2.2.1.20

.1.3.6.1.2.1.2.2.1.11,.1.3.6.1.2.1.2.2.1.17

（2）是读取所有节点都慢，还是只有这几个？

   读取所有节点都慢

    （3）是否存在多个服务器读取同一个节点，如果有多网管的情况下，看看是否可以单网管读下对应节点是否有问题。

                  现场服务器只有一台

    （4）找一个慢的节点取回来一份debug信息，debug看一下 

<H3C.S9810-IRF.F-SERIES>debugging snmp agent packet ?

  header   SNMP packet header debugging                                                                                             

  receive  SNMP received packet debugging                                                                                          

  send     SNMP sent packet debugging        

    2、查看现场配置发现如下问题：

      （1）现场的设备配置有镜像，某端口出方向流量存在拥塞的可能，这样会造成流量出现反压到上行。

      （2）现场读下TC的历史，当前看设备有TC变化 在删MAC的操作，这样会超的L2SH任务高的情况，如果确认有TC变化可以收集下debug l2 slot X chip Y mac/del/show

     TC排查思路：Receive指的是这个设备从对端收到的TC报文个数，send表示从这个接口发送给对端的TC报文个数。在logbuffer中查看TC记录的时候，需要区分两点，  一个是detect，这个就表示是接口自身up/down产生的TC报文，一个是notified，这个就表示是收到对端发过来的。可以按照该表项找到拓扑震荡的源头。

         如果确认有TC变化可以收集下debug l2 slot X chip Y mac/del/show

先把以上两点排除下，然后再收集snmp的debug信息，还有再确认下snmp出问题的前后有没有什么操作在设备上。

  （3）查看TC无变化，最后debug和抓包看一下：

3、   现场抓包发现，每次读取交互6600左右个包，出入方向的报文，单方向的话大概3300个包，耗时40S，读取速度都是毫秒级的，不存在等待几秒钟再发包的情况。

问题定位：

          读取的MIB节点过多导致报错

     设备读取并无问题（每次都是ms级），但一次读取节点过多，导致整个读取周期很长。

网管拉取不到是因为：现场读取接口过多，加起来的读取时间就超过了网管的30S拉取时间。建议修改一下网管的拉取时间或者采用getbulk 来读取。

         1、建议修改一下网管的拉取时间或者采用getbulk 来读取。

         2、升级到1152，对SNMP有优化，但现场读取节点实在过多，时间不一定在30S内。