All it is doing, as I understand it, is noting that the current value is
the last value, therefore it must have wrapped, OR been reset by the
It does not presume to know what the maximum value might have been, and
therefore discards that particular datapoint as unknowable. It resumes with
the delta it gets from two subsequent, increasing values. Is this different
what you are seeing, or did I misunderstand your situation?
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Clarence Hart <rti1clh AT ismd.ups DOT com>@tkg.com on 11/30/2000 04:11:45 PM
Please respond to IBM NetView Discussion <nv-l AT tkg DOT com>
Sent by: owner-nv-l AT tkg DOT com
To: nv-l AT tkg DOT com
Subject: Re: Antwort: Re: Antwort: Re: [NV-L] Better Graphing tools for
Hey , All...
I understand that snmpCollect is supposed to save ifInOctets (for
example) as COUNTER data and
store the info in the respective data files.
I'm wondering is this a bug... Check this out....
snmpCollect grabs data (bugus here of course:)
from snmpColDump -tT
11/29/00 16:49:00 switch1234.com 115546 975530942 975534540
11/29/00 19:26:34 switch1234.com 113586 975540394 975543994
Heres the log entry....
Wed Nov 29 17:26:35 2000 : SNMPget(switch1234 ifInOctets.24): counter
Wed Nov 29 18:26:34 2000 : ifInOctets.24 Counter wrapped on switch1234
until next collection to compute
Wed Nov 29 18:26:34 2000 : SNMPget(switch1234 ifInOctets.24): counter
Wed Nov 29 19:26:34 2000 : SNMPget(switch1234 ifInOctets.24): 113586
As you can see the data looks good until the COUNTER value exceeds the
OK, my question is why does snmpCollect state that it will compute the
value at the
next collection time but it never makes and entry in the inInOctets.24 file
"Nov 29 17:26 or 18:26"? snmpcollect seems to know that the counter
wrapped but it doesnt
do anything about it.
Is snmpCollect supposed to do update the ifInOctets file with the missing
Or is my version of snmpCollect bad?
It seems like snmpCollect should get a value from the device...
Then state the counter wrapped...
Then update the ifInOctets.x file at the next collection time
with 2 values
instead of one.
> From: Jochen.Friedrich AT genorz DOT de
> Subject: Antwort: Re: Antwort: Re: [NV-L] Better Graphing tools for
> To: IBM NetView Discussion <nv-l AT tkg DOT com>
> Date: Wed, 29 Nov 2000 16:06:00 +0100
> X-Priority: 3 (Normal)
> X-MIMETrack: Serialize by Router on
GFSLNT85/Servers/GENO-RZ/GENO/DE(Release 5.0.1b (Intl)|30
September 1999) at 29.11.2000 16:06:17
> MIME-Version: 1.0
> X-Sorted: Bulk
> Hi Clarence,
> > This is what I'm doing;
> > 1) snmpCollect collects and saves all data from OID.#! files.
> > 2) I then read/dump the OID.# data to create the rrd's.
> > 3) webpage displays on-the-fly graphs.
> Sounds familiar ;-)
> > The problem happens during step 1. My network devices have 32bit
> > counters so once or twice a day on busy ports the counters reset or
> > wrap. This causes a gap in the rrd database. Have you run into this
> > problem?
> We currently only use snmpCollect to collect Interface statistics and
> CPU load for all our routers. For the interface statistics, snmpCollect
> already does the conversion from COUNTER to GAUGE type data.
> > Also I'm wondering has anyone change the mib.coerce data file
> > to store GAUGE instead of COUNTER type data to resolve similar
> This might be a possibility. The standard interface statistics (under
> mibII.if) seem to be handled correctly.
> NV-L List information and Archives: http://www.tkg.com/nv-l
chart AT ups DOT com
NV-L List information and Archives: http://www.tkg.com/nv-l