SNMP - Interface Statistics Query Issue for Cisco 6500

[idlepated]

I'm building a replacement Cacti server, and have run into a problem with the SNMP - Interface Statistics not being able to poll some (but not all) Cisco 6500s. I'm running Cacti -0.88a on Ubuntu 13.04 with snmpwalk 5.4.3. The output from the query when it fails is:

+ Running data query [1].
+ Found type = '3' [SNMP Query].
+ Found data query XML file at '/usr/share/cacti/site/resource/snmp_queries/interface.xml'
+ XML file parsed ok.
+ Executing SNMP get for num of indexes @ '.1.3.6.1.2.1.2.1.0' Index Count: 386
+ Executing SNMP walk for list of indexes @ '.1.3.6.1.2.1.2.2.1.1' Index Count: 0
+ No SNMP data returned [/size][/size]

The system query at the top left of the device page is successful. On 6500s where the query fails, I can snmpwalk successfully from the OS. In particular, I can snmpwalk .1.3.6.1.2.1.2.1.0 and .1.3.6.1.2.1.2.2.1.1 without getting an error and without seeing unexpected results.

The query runs normally for most of the 6500s in the network. The issue affects boxes with supervisor 32s but not ones with supervisor 720s

I've tried setting the host template to "cisco router" "cisco - 6500" as well as a generic snmp-enabled device. Same result in any case.

Anybody have an idea of the next troubleshooting step? I've hit a dead end.

[idlepated]

This is what I get when I snmpwalk the problem nodes from the cacti server using the OID that the cacti walk fails on:

cactiadmin@cacti_box:~$ snmpwalk -c mctelro -v 2c x.x.x.x .1.3.6.1.2.1.2.2.1.1
iso.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.1.2 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.1.3 = INTEGER: 3
[...]
iso.3.6.1.2.1.2.2.1.1.388 = INTEGER: 388
iso.3.6.1.2.1.2.2.1.1.389 = INTEGER: 389

[paulgevers]

I suggest reading the debugging documentation, and especially raising the logging level and checking the logs.

[idlepated]

When the affected 6500s were rebooted, the problem went away on its own. Some time earlier, they had been involved in a fairly extensive network event. The event had caused a number of odd, subtle performance issues on anything running a sup32, even though the passed traffic (fairly) normally. The reboot cleared whatever system issues the network event caused.