[rrd-users] Re: COUNTER to DERIVE

[Gellatly, Laurie]

Just to add a little extra worry here,
I've seen some new Cisco gear we have report the same value
for consecutive IfHC interfaces while the IfxxOctets value for 
those interfaces are reasonable and different. Indeed, the first N ifHC
matched
perfectly with xxxOctets (machine had recently restarted) and then
the next Y interfaces reported the same IfHC value and then the
final Z interfaces were again correct. Buyer beware.


			...Laurie :{)

-----Original Message-----
From: Dave Plonka [mailto:plonka at doit.wisc.edu]
Sent: Saturday, 30 December 2000 4:45
To: rrd-users at list.ee.ethz.ch
Cc: David Koski
Subject: [rrd-users] Re: COUNTER to DERIVE



On Fri, Dec 29, 2000 at 11:36:28AM -0500, David Koski wrote:
> 
> Dave,
> 
> 	Just to clarify...  I'm moving from COUNTER to DERVIE with rrd-min
> set to 0 to remove any spikes that occur in the couter wrap code due to
> huge counter wraps, router reloads, etc.  Since RRD tries to compensate
> for the counter roll instead of just throwing out the data (AKA Concord
> Network Health's way of dealing with a counter roll), I need some way to
> just ignore any spike that could occur in the RRD counter wrap logic.

Thanks for the clairification...

I like that method of just discarding the value when the counter
wraps.  In RRD terms that would mean recording the PDP Status info, but
storing NaN (Tobi's *UNKNOWN*) in the RRA, which sound like what will
happen if you switch to DERIVE with the DS' min set to zero.

> Since folks both here and on the cricket list seem to lean twards the only
> "neat" way to get rid of such a spike occurance is to move to DERIVE with
> an rrd-min of 0 to ignore any negative deltas on the graph (Without having
> to worry about anyones buggy implementation of SNMP), seems about the best
> way I can get around having to constantly explain weird spikes to
> customers :)

Agreed.

Anyway, I think you'll have good luck modifying the RRD files using XML
dump and restore as I mentioned in the previous follow-up.

> Also to clarify my mixture of Gauge and Counter explanation.  Currently
> I'm using 32 bit traffic counters for anything under 12 megs (Cisco
> routers), and anything over 12 megs I'm using Cisco ifloc integers.
> Works for now, but since the ifloc integers are really unsupported and
> Cisco claims they are going to eventually disappear (?), so we will
> eventually move everything possible to a 64-bit ifHC counter, however I'm
> having some strange problems with HUGE spikes occuring on every sub
> interface (ATM, FrameRelay and channelized interfaces) all at the same
> time (AKA Peta bits per second).

Hmmm... I think we're getting mostly good values from our HC counters,
but most of those are on ethernet switch ports rather than router
interfaces, so its very different Cisco hardware and code than on your
routers.  I'll keep your report in mind when we consider using the HC
counters on our WiscNet routers.

> I've not been able to blame anything as
> of yet.  However, I'm not trying to compensate for the 64-bit problem at
> this point only the once in a while occurance of a huge spike in a 32-bit
> graph.  The unfortunate part is I have about a years worth of data stored
> in RRDs at this point and would like to maintain that data that would not
> shift to a 64-bit counter (Non-backbone customer router, I.E. Cisco 2501
> running 11.x)

I'm missing why that's unfortunate, unless you mean that you must
figure out how to preserve your existing data.  (Personally, I think
it'd be more unfortunate if you discarded it!)  If you wish, use
Cricket's "events" to record the point in time at which you switched
from COUNTER to DERIVE.  That will help to explain why your MAX values
before that even are sometimes unreasonably high, and also that the
AVERAGE values may have been skewed by those bad samples.

As an aside, if you haven't come across this already, perhaps you can
avoid the mistake we made by assuming that the presence of the High
Capacity interface counters on a Cisco meant that they actually
worked.  We use a customized Cricket "listInterfaces" script which uses
SNMP v2c to test whether or not the ifHC counters were present and use
them accordingly.  Months later, what we found with some Cisco
equipment (such as the 3500XL switches running IOS 12.0(5)XU) is that
the HC counters are there, but always report zeroes.  Our current
kludge is to test the sysDescr - if it contins "C3500", we disregard
the 64-bit HC counters, and must use the 32-bit counters even on Gb
links.  Ugh.

Dave

-- 
plonka at doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison,
WI

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi


**********************************************************************
This correspondence is for the named person's use only.  It may 
contain confidential or legally privileged information or both. 
No confidentiality or privilege is waived or lost by any 
mistransmission.  If you receive this correspondence in error, please
immediately delete it from your system and notify the sender.  You 
must not disclose, copy or rely on any part of this correspondence 
if you are not the intended recipient. 

Any views expressed in this message are those of the individual sender,
except where the sender expressly, and with authority, states them to
be the views of Vodafone.

This email has been checked for viruses.
**********************************************************************

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi