nv-l
[Top] [All Lists]

RE: Re: snmpCollect counter wrapping

To: nv-l@lists.tivoli.com
Subject: RE: Re: snmpCollect counter wrapping
From: Joe Fernandez <jfernand@kardinia.com>
Date: Fri, 01 Dec 2000 11:15:14 +1100
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
>
>_________________________________________________________________________


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web