Reviving an old post.....
Does anyone know if NetView 7.1 addresses the below
mentioned question?
Thanks,
Eric
-----Original Message-----
64 bit counters are the only practical way to go but
Netview doesn't support SNMPv2c collections which
include support for 64 bit counters.
Paul
-----Original Message-----
From: Joe Fernandez [mailto:jfernand AT kardinia DOT com]
Sent: Thursday, November 30, 2000 6:15 PM
To: IBM NetView Discussion
Subject: RE: [NV-L] Re: snmpCollect counter wrapping
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 AT msicc DOT com>
>> To: "'IBM NetView Discussion'" <nv-l AT tkg DOT 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 AT US.IBM DOT 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 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
>> 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 AT genorz DOT de
>> > Subject: Antwort: Re: Antwort: Re: [NV-L] Better
Graphing tools for
>> Netview
>> > 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
>> 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 AT ups DOT 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 AT ups DOT 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
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
|
