[rrd-users] Re: RRDTOOL and MRTG - Data out of bounds problems

Jason Frisvold Jason.Frisvold at corp.ptd.net
Wed Mar 27 22:32:50 MET 2002

In my case, there were no resets.  Or, rather, there should not have been..  This happened on several routers across the network where noone was logged in..  *shrug*

Jason H. Frisvold
Senior ATM Engineer
Engineering Dept.
CCNA Certified - CSCO10151622
friz at corp.ptd.net
"Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world." -- Albert Einstein [1879-1955]

-----Original Message-----
From: Clifton Royston [mailto:cliftonr at lava.net] 
Sent: Wednesday, March 27, 2002 2:01 PM
To: Luís Marta
Cc: Jason Frisvold; rrd-users at list.ee.ethz.ch
Subject: Re: [rrd-users] Re: RRDTOOL and MRTG - Data out of bounds problems

On Tue, Mar 26, 2002 at 03:16:19PM -0000, Luís Marta wrote:
> I've been having more or less the same odd-spikes problem in RRD-TOOL. And i
> can't figure out why, some graphics have spikes at one time, others at
> another time, even when the data is read from the same router, with no
> pattern whatsoever...
> It's not a reload in the router, it's not the counter that went back to
> zero, ...?

  How have you confirmed this last?

  Many SNMP implementations will clear the counter to zero at
inappropriate times.  For instance, on some Cisco IOS versions, "clear
interface counters" on the command line will clear the underlying SNMP
counters causing a spike, not just clear what is displayed to the
interactive user.  Lately I've seen problems with Cisco tunnel
interfaces showing giant spikes - apparently interfaces are cleared
when the tunnel goes down.  The worse part is that these kind of SNMP
problems seem to get randomly fixed and broken again in different IOS
releases, tracks, hardware platforms, etc. - there's not a steady
improvement in it.

  (And Cisco is in general one of the better SNMP implementers - many
products are much worse!)

> Anyone has ideas?
  The COUNTER type in RRD should work.  *Should*.

  However, so many systems fail to implement it correctly that the
developers for Cricket (which I use) have changed the default in
Cricket to DERIVE with an minimum of 0.  This will throw away valid
data when the counter really wraps, but avoids the pain and problems
with spikes due to invalid resets.  It's one solution, I don't say it's
the right one for all installations.
  -- Clifton

> ----- Original Message -----
> From: "Jason Frisvold" <Jason.Frisvold at corp.ptd.net>
> To: <rrd-users at list.ee.ethz.ch>
> Sent: Tuesday, March 26, 2002 3:06 PM
> Subject: [rrd-users] RRDTOOL and MRTG - Data out of bounds problems
> > We monitor several thousand nodes.  I have it running on a single box,
> > and it seems to keep up quite well.  I've run into a problem, however,
> > and I can't seem to figure out what's happening...  Every once in a
> > while (esp during a network outage) the graphs will spike to ridiculous
> > levels.  While I'd love to have my OC-3 circuits be capable of handling
> > 4+Gb of data, it just isn't possible.  I cannot figure out where these
> > spikes are being sourced from and it's throwing the resolution of the
> > graphs off, not to mention severely skewing the data...

    Clifton Royston  --  LavaNet Systems Architect --  cliftonr at lava.net
"What do we need to make our world come alive?  
   What does it take to make us sing?
 While we're waiting for the next one to arrive..." - Sisters of Mercy

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

More information about the rrd-users mailing list