Counter returns signed integer

[imro]

I am trying to put together a template for Doubletake replication software. One of the values I am trying to poll is defined in the MIB as a counter. It represents data transfered. The problem is it graphs for a little while, then quits. After some research I have found that it returns signed integer and thus stops graphing after it wraps.

Here is what I get when I run snmpget:

Code: Select all

snmpget -c public -v 1 192.168.11.80 .1.3.6.1.4.1.2592.3.6.2.1.12.1
SNMPv2-SMI::enterprises.2592.3.6.2.1.12.1 = INTEGER: -1952468508

It does not matter if I use v1 or v2 of SNMP, I get the same.

Is there any way around this issue?

If not and if this means Doubletake's SNMP implementation is not complaint with standard, can somebody point me to a specification that addresses this? I would like to send it to Doubletake so they can fix it.

I am not sure if it makes any difference but it is a Windows box Doubletake is running on.

[BSOD2600]

Looks like their counter value is wrapping and they're not properly handling it in code. If they properly implemented SNMPv2c, which can use 64bit values, then this wouldn't likely be a problem. You can google for a snmpv2c RFC(s).

Do they provide a snmp tool that displays the data?

[imro]

Looks like their counter value is wrapping and they're not properly handling it in code. If they properly implemented SNMPv2c, which can use 64bit values, then this wouldn't likely be a problem. You can google for a snmpv2c RFC(s).

Ok I have found these (just in case anybody else wanted to know):

http://gim.org.pl/rfcs/rfc1155.html

3.2.3.3. Counter

This application-wide type represents a non-negative integer which

monotonically increases until it reaches a maximum value, when it
wraps around and starts increasing again from zero. This memo
specifies a maximum value of 2^32-1 (4294967295 decimal) for
counters.

http://gim.org.pl/rfcs/rfc1212.html

7.1.6. Counter32

The Counter32 type represents a non-negative integer which
monotonically increases until it reaches a maximum value of 2^32-1
(4294967295 decimal), when it wraps around and starts increasing
again from zero.

Do they provide a snmp tool that displays the data?

None that I know of. They provide MIB in which it clearly states that it should be a counter.

[imro]

OK, now that we know it is not in compliance, is there any way to work around this in cacti? I doubt they are going to fix it over night ...

[BSOD2600]

Maybe there is a way to work around it. Since it appears the counter32 is rolling over, one might be able to do some math to fix/fudge it. They really should implement a Counter64.

Inside the application, do you have any way to get the 'real' values of what you're trying to poll? If not, this math stuff won't work, since we can't verify the result. Just a WAG, but maybe 4294967295 - 1952468508 = 234249878, the real number.

[imro]

I probably could come up with the math, the question is where to implement it in cacti so it happens in between snmp polling and writing into rrd?.

[BSOD2600]

I probably could come up with the math, the question is where to implement it in cacti so it happens in between snmp polling and writing into rrd?.

You would have to use a script which did the SNMP query, did the math, then spit it out to cacti.

[AaronT]

Is there any solution to this yet???

I'm having same issue, here is snmpwalk output

DTMIB::dtMirOpsGenerated.0 = Wrong Type (should be Counter32): INTEGER: 4959
DTMIB::dtMirBytesGenerated.0 = Wrong Type (should be Counter32): INTEGER: 1184047
DTMIB::dtRepOpsGenerated.0 = Wrong Type (should be Counter32): INTEGER: 157381
DTMIB::dtRepBytesGenerated.0 = Wrong Type (should be Counter32): INTEGER: -1985925943
DTMIB::dtFailedMirrorCount.0 = Wrong Type (should be Counter32): INTEGER: 0