Leslie,
I agree with you Paul, there is an algorithm to figure out what the value
should be. My question was " Is snmpCollect supposed to figure out what the
wrapped values are?" On most of our ports I could live with a gap/null value
once every few days but on uplinks and high bandwidth ports I'm getting
gaps in my data more frequently.
I suggest a patch be implemented to fix this issue as soon as possible...
Many Netview/Network Admins will benefit from the addition of a few lines
of code to figure out the wrapped data value.
Thanks
CoolC
> From: "Paul Maine Jr." <paulm@msicc.com>
> To: "'IBM NetView Discussion'" <nv-l@tkg.com>
> Subject: RE: [NV-L] Re: snmpCollect counter wrapping (was Better Graphing
> tools for Netview)
> Date: Thu, 30 Nov 2000 16:23:05 -0600
> MIME-Version: 1.0
> X-Sorted: Bulk
>
> Why does Netview discard the wrap. There is a straight forward algorithm to
> make the proper count adjustment once a wrap has been detected and thus not
> lose any valid data. The counter size is limited to 32 bits, therefore the
> upper limit is known and factored into the wrap calculations. This is
> becoming more of an issue since many networks are using gigabit technology
> and the 32 bit counters will wrap very quickly.
>
> -----Original Message-----
> From: Leslie Clark [mailto:lclark@US.IBM.COM]
> Sent: Thursday, November 30, 2000 4:06 PM
> To: IBM NetView Discussion
> Subject: [NV-L] Re: snmpCollect counter wrapping (was Better Graphing
> tools for Netview)
>
> All it is doing, as I understand it, is noting that the current value is
> less than
> the last value, therefore it must have wrapped, OR been reset by the
> operator.
> 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
> from
> what you are seeing, or did I misunderstand your situation?
>
> Cordially,
>
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
> Detroit
>
>
> Clarence Hart <rti1clh@ismd.ups.com>@tkg.com on 11/30/2000 04:11:45 PM
>
> Please respond to IBM NetView Discussion <nv-l@tkg.com>
>
> Sent by: owner-nv-l@tkg.com
>
>
> To: nv-l@tkg.com
> cc:
> Subject: Re: Antwort: Re: Antwort: Re: [NV-L] Better Graphing tools for
> Netview
>
>
>
>
> 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
> init/wrap
> Wed Nov 29 18:26:34 2000 : ifInOctets.24 Counter wrapped on switch1234
> (4036900444->129311686) Waiting
> until next collection to compute
> Wed Nov 29 18:26:34 2000 : SNMPget(switch1234 ifInOctets.24): counter
> init/wrap
> 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
> 32-bit number.
>
>
> 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
> for
> "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
> amount ?
> 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.
>
>
> Thank You!!
>
> CoolC
>
>
>
>
> > From: Jochen.Friedrich@genorz.de
> > Subject: Antwort: Re: Antwort: Re: [NV-L] Better Graphing tools for
> Netview
> > To: IBM NetView Discussion <nv-l@tkg.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
> issues.
> >
> > This might be a possibility. The standard interface statistics (under
> > mibII.if) seem to be handled correctly.
> >
> > Cheers,
> > Jochen
> >
> > _________________________________________________________________________
> > NV-L List information and Archives: http://www.tkg.com/nv-l
>
> Clarence Hart
> UPS
> Office: 410-560-4182
> Fax: 410-560-4329
> chart@ups.com
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
>
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
Clarence Hart
UPS
Office: 410-560-4182
Fax: 410-560-4329
|