S10506 通过服务器获取snmp信息慢超时中断

无

现场使用snmpwalk –v 2c –c public 172.16.0.2获取交换机的信息，反馈获取信息的刷新比正常慢很多，中途还会因为超时中断。反馈服务器到设备的通信都是正常，也没有丢包和延迟，通过oid也能单独获取。

采用snmpwalk –v 2c –c public 172.16.0.2方式读取信息时，会存在偶尔卡顿的情况。

snmpwalk –v 2c –c public 172.16.0.2是去获取设备获取全部的mib节点。Snmpwalk方式是每次发起请求，读取一个接口信息，设备返回后再发起一个snmp请求。

例如：

*Nov  4 18:59:18:337 2021 AH_JF_C01_WW_CS01 SNMP/7/PACKET_SRC: -MDC=1;    Packet received from 10.20.121.171 via UDP

*Nov  4 18:59:18:338 2021 AH_JF_C01_WW_CS01 SNMP/7/PACKET: -MDC=1;

   Get-next request

   Request ID: 1461496804

   Error status: 0

   Error index: 0

*Nov  4 18:59:18:338 2021 AH_JF_C01_WW_CS01 SNMP/7/VBLIST: -MDC=1;

   ifName.405:

*Nov  4 18:59:18:343 2021 AH_JF_C01_WW_CS01 SNMP/7/PACKET: -MDC=1;

   Response

   Request ID: 1461496804

   Error status: 0

   Error index: 0

*Nov  4 18:59:18:343 2021 AH_JF_C01_WW_CS01 SNMP/7/VBLIST: -MDC=1;

   ifName.406: GigabitEthernet1/4/0/18

*Nov  4 18:59:18:343 2021 AH_JF_C01_WW_CS01 SNMP/7/PACKET_DES: -MDC=1;    Packet sent to 10.20.121.171 via UDP

*Nov  4 18:59:18:391 2021 AH_JF_C01_WW_CS01 SNMP/7/PACKET_SRC: -MDC=1;    Packet received from 10.20.121.171 via UDP

*Nov  4 18:59:18:391 2021 AH_JF_C01_WW_CS01 SNMP/7/PACKET: -MDC=1;

   Get-next request

   Request ID: 1461496805

   Error status: 0

   Error index: 0

*Nov  4 18:59:18:391 2021 AH_JF_C01_WW_CS01 SNMP/7/VBLIST: -MDC=1;

   ifName.406:

*Nov  4 18:59:18:394 2021 AH_JF_C01_WW_CS01 SNMP/7/PACKET: -MDC=1;

   Response

   Request ID: 1461496805

   Error status: 0

   Error index: 0

*Nov  4 18:59:18:395 2021 AH_JF_C01_WW_CS01 SNMP/7/VBLIST: -MDC=1;

   ifName.407: GigabitEthernet1/4/0/19

*Nov  4 18:59:18:395 2021 AH_JF_C01_WW_CS01 SNMP/7/PACKET_DES: -MDC=1;    Packet sent to 10.20.121.171 via UDP

由于设备存在多个网管同时来设备获取信息，而snmp是串行处理的，因此snmpwalk发起一个请求后，接下来设备可能会去处理其它网管发送过来的请求。网管越多，获取的节点约频繁，就会存在snmp消息积压的情况

#设备上确实存在snmp队列积压的情况。

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

Location: chassis 1 slot 6 cpu 0

Creator: snmpd[1708039]

State: N/A

Options: SO_REUSEPORT

 Error: 0

Receiving buffer(cc/hiwat/lowat/drop/state): 1034 / 42240 / 1 / 0 / N/A  ===》CC队列存在计数，表明存在积压

Sending buffer(cc/hiwat/lowat/state): 0 / 1406 / 60 / N/A

Type: 2

Protocol: 17

[AH_JF_C01_WW_CS01-probe]dis udp verbose

Total UDP socket number: 6

snmp队列积压的越多，新进来的snmp请求报文等待处理时长就会越长，这也是snmpwalk方式去读取时候，看到存在偶尔卡顿的原因。如果超过默认超时时间就会超时中断。

另外，从设备上来看，laggd进程有点高，这个是因为网管频繁来获取ifHCOutOctets导致，而laggd CPU高又会影响snmp读取聚合端口流量统计的效率，使得耗时变长。

[AH_JF_C01_WW_CS01-probe]dis process cpu  c 1 s 0 | in laggd

       276      4.8%      3.8%      4.0%    laggd

[AH_JF_C01_WW_CS01-probe]dis process cpu  c 1 s 2 | in laggd

       210     10.1%      7.4%      6.3%    laggd

[AH_JF_C01_WW_CS01-probe]follow process 210 c 1 s 2 c 0

Attaching to process 210 (laggd)

Iteration 1 of 5

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

Thread (LWP 210):

Switch counts: 225410449

User stack:

#0  0x40450890 in syscall+0x20/0x30

#1  0x40074940 in doIOCtl+0x3c/0x48

#2  0x40403b60 in userPhyIoCtl+0x68/0x70

#3  0x40403be4 in IF_GetPhyStatistic+0x7c/0x8c

#4  0x0003eab8 in LAGG_stat_GetIfStatData+0x8c/0x3e70

#5  0x00042b68 in LAGG_stat_GetLocalStatData+0xd4/0x3548

#6  0x000313c4 in ??

#7  0x00047444 in LAGG_syn_ProcMsg+0x208/0x284

#8  0x000474e8 in LAGG_syn_RcvMsg+0x28/0x58

#9  0x000477bc in ??

#10  0x0002f498 in main+0x248/0x30c

#11  0x404845f0 in __uClibc_main+0x278/0x33c

 另外反馈读取其它设备没有问题，是因为没有问题的设备是盒子设备，本身端口就很少。 

建议：

1 建议网管调整下去设备读取节点的频率，例如隔10分钟去读取一次。实际也没有必要每隔几S就来读取一次信息

2如果客户有多个网管同时读取设备信息的需求，可以调整下网管设备，间隔性的来设备读取snmp数据（轮着来）。避免多个网管同时来读取导致消息积压。

3 调整下网管超时时间，例如snmpwalk –v 2c –c public可以加个超时时间的参数，调大超时时间为15s：snmpwalk –v 2c –t 15 –c public，可规避超时退出