Hi,
How does the algorithm figure out whether the counter has wrapped once or
twice or N times between polls?
I thought the IETF recommendation was to use SMI v2 64 bit counters for
high speed interfaces, as in RFC 2863.
At 06:14 PM 30-11-00 -0500, you wrote:
>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
>chart@ups.com
>
>_________________________________________________________________________
|