SNMP results not valid

[psterk]

I have this exact same issue on CentOS 5.5 Final with Cacti 0.8.7g. Was it ever resolved? I think it is preventing the creation of the rrd files for me.

[gandalf]

I have exactly the same problem. "SNMP get timout" whereas the command line works well.

The command line from previous thread did neither define a timeout nor a retry count. Please use the same as cacti does or incraese cacti timeout and retry.
Another issue might be a high load on the target machine, e.g. if it suffers from too many snmp requests. This is known to happen e.g. on some small and weak network devices
R.

[bourneww]

I have the same problem.

CMDPHP: Poller[0] WARNING: SNMP Get Timeout for Host:'192.28.1.102', and OID:'.1.3.6.1.2.1.25.2.3.1.6.4'

This appeared in my log this morning. Nothing was changed at the device side.

When I do the snmpget, the result is fine.

snmpget -v 2c -c gmonitor 192.28.1.102 .1.3.6.1.2.1.25.2.3.1.6.4
HOST-RESOURCES-MIB::hrStorageUsed.4 = INTEGER: 6392303

However, the graphs for this device are all ok. There are no broken polls and etc. Seems normal. So the question is why cacti is getting timeout while still updating the data into rrd.

[Spechal]

Similar issue:

04/17/2012 10:15:01 AM - CMDPHP: Poller[0] WARNING: SNMP Get Timeout for Host:'10.2.180.122', and OID:'.1.3.6.1.2.1.25.2.2'
04/17/2012 10:15:01 AM - CMDPHP: Poller[0] Host[2] DS[59] WARNING: Result from SNMP not valid. Partial Result: U
04/17/2012 10:15:01 AM - SYSTEM STATS: Time:0.1908 Method:cmd.php Processes:1 Threads:N/A Hosts:6 HostsPerProcess:6 DataSources:4 RRDsProcessed:4
04/17/2012 10:15:01 AM - SYSTEM THOLD STATS: Time:0.0038 Tholds:0 DownHosts:0

>$ snmpwalk -v1 -c intsnmp 10.2.180.122 .1.3.6.1.2.1.25.2.2
HOST-RESOURCES-MIB::hrMemorySize.0 = INTEGER: 4043792 KBytes

Created the graph with SNMP - Generic OID Template and added the OID

Using Cacti 0.8.8 (downloaded yesterday) and the PHP poller

Any assistance would be appreciated.

*** EDIT ***
Just realized I was using snmpwalk and I need to use snmpget (which fails on the OID) ... I updated the OID with a RAM one that works with snmpget and am waiting for a few jobs to run to see if the data is available.

[Spechal]

Using an OID that works with snmpget resolved the issue.

[jocvtrhythgd]

but when I do a verbose query of a device I get results, or if I do a manual snmpwalk from that server it is able to return values.

[Grandalf00]

I know, it's 5 years old topic but I have the same problem.

Ubuntu: 16.04
PHP: 7.0.8-0ubuntu0.16.04.3
Cacti: 0.8.8h
RRDtool 1.5.5

I increase next value:
SNMP Timeout: 1000
Maximum OID's Per Get Request: 12
SNMP Retries: 5

but the problem still exist:

01/03/2017 12:37:09 PM - CMDPHP: Poller[0] WARNING: SNMP Get Timeout for Host:'10.202.0.19', and OID:'.1.3.6.1.2.1.2.2.1.10.29'
01/03/2017 12:37:09 PM - CMDPHP: Poller[0] Host[24] DS[627] WARNING: Result from SNMP not valid. Partial Result: U

This problem was started from day to day, nothing was changed.
More interesting is:

01/03/2017 12:37:09 PM - CMDPHP: Poller[0] WARNING: SNMP Get Timeout for Host:'10.202.0.19', and OID:'.1.3.6.1.2.1.2.2.1.10.29'
01/03/2017 12:37:09 PM - CMDPHP: Poller[0] Host[24] DS[627] WARNING: Result from SNMP not valid. Partial Result: U
01/03/2017 12:37:09 PM - CMDPHP: Poller[0] Host[24] DS[627] SNMP: v2: 10.202.0.19, dsname: traffic_in, oid: .1.3.6.1.2.1.2.2.1.10.29, output: U
01/03/2017 12:37:09 PM - CMDPHP: Poller[0] Host[24] DS[627] SNMP: v2: 10.202.0.19, dsname: traffic_out, oid: .1.3.6.1.2.1.2.2.1.16.29, output: 1530724339

[ThierryDV]

Hello,

We are having exactly the same issue since a couple of days.

Our setup:

Debian Jessie
Cacti Version 0.8.8b
Cacti OS unix
SNMP Version NET-SNMP version: 5.7.2.1
RRDTool Version RRDTool 1.4.x
Hosts 155
Graphs 2625

+ spine:

SPINE 0.8.8h Copyright 2002-2016 by The Cacti Group


Since a couple of days, polling fails with the new created hosts.

For example, hosts ID 159 and 165.

What i quite strange is that when I run spine to the two hosts, returned values are not correct:

usr/local/spine/bin/spine -V 5 159 165

01/11/2017 03:40:41 PM - SPINE: Poller[0] Host[159] DEBUG: ICMP Host Alive, Try Count:1, Time:1.0011 ms
01/11/2017 03:40:41 PM - SPINE: Poller[0] Host[165] DEBUG: ICMP Host Alive, Try Count:1, Time:20.8449 ms

01/11/2017 03:40:41 PM - SPINE: Poller[0] Host[159] TH[6] Recache DataQuery[8] OID: .1.3.6.1.2.1.1.3.0, output: U

01/11/2017 03:40:41 PM - SPINE: Poller[0] Host[165] TH[4] Recache DataQuery[1] OID: .1.3.6.1.2.1.1.3.0, output: U
01/11/2017 03:40:41 PM - SPINE: Poller[0] Host[165] TH[4] Recache DataQuery[8] OID: .1.3.6.1.2.1.1.3.0, output: U
01/11/2017 03:40:41 PM - SPINE: Poller[0] Host[165] TH[4] Recache DataQuery[9] OID: .1.3.6.1.2.1.1.3.0, output: U

However, if I run spine with only one host, it's ok:

/usr/local/spine/bin/spine -V 5 159 159
01/11/2017 04:05:36 PM - SPINE: Poller[0] Host[159] TH[3] Recache DataQuery[8] OID: .1.3.6.1.2.1.1.3.0, output: 26831359

/usr/local/spine/bin/spine -V 5 165 165
01/11/2017 04:06:00 PM - SPINE: Poller[0] Host[165] TH[3] Recache DataQuery[1] OID: .1.3.6.1.2.1.1.3.0, output: 10434566

What makes that difference?

From the cacti server, I can do snmpget or snmwalk to these hosts without any issues.

We are using SNMPv3 with DES and SHA to poll the hosts.

I have already tried:

- To do a fresh install of the latest version of CACTI on Debian and CentOS.
- To change the snmp timeout, ping timeout, spine process, max OIDs.
- To uses different versions of spine.
- To uses different versions of php5-snmp.

but I always encounter the same behaviour.

Another info: If I switch to SNMPv2, then it works like a charm.

Could you please help me?

Thanks.

[ThierryDV]

Hello,

As no changes were made on CACTI, I have looked at what can have changed on the server itself. I can see that an update was pushed on Debian repos.

On 2016-12-19, following packages were upgraded:

Start-Date: 2016-12-19 09:24:20
Upgrade: libapache2-mod-php5:amd64 (5.6.28+dfsg-0+deb8u1, 5.6.29+dfsg-0+deb8u1), php5-mysql:amd64 (5.6.28+dfsg-0+deb8u1, 5.6.29+dfsg-0+deb8u1), php5-ldap:amd64 (5.6.28+dfsg-0+deb8u1, 5.6.29+dfsg-0+deb8u1), php5-common:amd64 (5.6.28+dfsg-0+deb8u1, 5.6.29+dfsg-0+deb8u1), php5-curl:amd64 (5.6.28+dfsg-0+deb8u1, 5.6.29+dfsg-0+deb8u1), php5-readline:amd64 (5.6.28+dfsg-0+deb8u1, 5.6.29+dfsg-0+deb8u1), php5:amd64 (5.6.28+dfsg-0+deb8u1, 5.6.29+dfsg-0+deb8u1), php5-snmp:amd64 (5.6.28+dfsg-0+deb8u1, 5.6.29+dfsg-0+deb8u1), php5-cli:amd64 (5.6.28+dfsg-0+deb8u1, 5.6.29+dfsg-0+deb8u1)
End-Date: 2016-12-19 09:24:34

Maybe the issue with new hosts started after this upgrades?

Additional info: it occurs only with new hosts. The hosts created weeks ago can be polled without any issues in SNMPv3.

Could you please help us to resolve this issue?

Thanks.