[mrtg] Re: FW: missed snmp poll problem?

Wed Feb 27 13:27:32 MET 2002

never mind this post. Found out that someone changed the config file and
added a minus in front of the OID with a space - 1:public at .... instead
of -1:public at ....

So the problem are the spikes on some interfaces now and then.

-----Original Message-----
From: mrtg-bounce at list.ee.ethz.ch [mailto:mrtg-bounce at list.ee.ethz.ch]On
Behalf Of Haspers
Sent: woensdag 27 februari 2002 11:34
To: mrtg at list.ee.ethz.ch
Subject: [mrtg] Re: FW: missed snmp poll problem?

I suddenly have another strange thing since this morning: on one of my
interfaces (cisco 2924XL) I'm getting negative counters?? I thought that
this wasn't possible (as these counters are "The ``incoming bytes counter''
value").

Below is an part of the logfile:

1014804342 -712293593 -356068787
1014804342 0 719177 0 719177
1014804044 0 719177 0 719177
1014804000 0 719177 0 719177
1014803700 0 719177 0 719177
1014803400 1336842 719177 1432331 719177
1014803100 1432331 719177 1432331 719177
1014802800 1432331 719177 1432331 719177
1014802500 1432331 719177 1432331 719177
1014802200 1432331 719177 1432331 719177
1014801900 1432331 719177 1432331 719177
1014801600 1432331 719177 1432331 719177
1014801300 1432331 719177 1432331 719177
1014801000 1432331 719177 1432331 719177
1014800700 1432331 719177 1432331 719177
1014800400 1432331 719177 1432331 719177
1014800100 1432331 719177 1432331 719177
1014799800 1432331 719177 1432331 719177
1014799500 1432331 719177 1432331 719177
1014799200 1432331 719177 1432331 719177
1014798900 1432331 719177 1432331 719177
1014798600 988308 496680 1432331 719177
1014798300 0 1446 0 1446
1014798000 0 1446 0 1446

As you can see, it goes from zero to 1432331 / 719177 / 1432331 / 719177 and
suddenly drops to 0 / 719177 / 0 / 71977 with negative counters. How is this
possible. Never had problems with MRTG before, but since upgrading to
v2.9.18pre1 (from 2.8.x) I'm having strange results. At the same time, some
of the interfaces have a really strange spike (around 60 Mbps), while other
interfaces haven't. This is a very irritating thing, causing me to change
the logfile myself.
I'm planning on downgrading back to an older good-working version.

Rolph

-----Original Message-----
From: mrtg-bounce at list.ee.ethz.ch [mailto:mrtg-bounce at list.ee.ethz.ch]On
Behalf Of Haspers
Sent: dinsdag 26 februari 2002 17:55
To: mrtg at list.ee.ethz.ch
Subject: [mrtg] FW: missed snmp poll problem?

Hi,

we are also seeing some spikes (up to 80.0 Mbps!!) on some interfaces. We
are monitoring these interfaces with an older version of MRTG as well to
monitor these interfaces and no spikes occur on these graphs. We know for
sure that there wasn't that much traffic, cause the other end of the same
line (interface line is connected to), doesn't show these spikes. This
currently looks like occuring only at one Catalyst 2924XL, and sometimes
occurs twice a day.
This won't be a 32bit counter rollover as fat as we can see, also because
traffic on these interfaces isn't much.

Maybe there is a minor bug in v2.9.18pre1? Running on Win2K btw.

Rolph
-----Original Message-----
From: mrtg-bounce at list.ee.ethz.ch [mailto:mrtg-bounce at list.ee.ethz.ch]On
Behalf Of Rich Adamson
Sent: dinsdag 26 februari 2002 16:56
To: mrtg-developers
Subject: [mrtg] missed snmp poll problem?

Stock mrtg v2.9.18pre1, RedHat Linux

We've been seeing a problem with interface usage statistics when mrtg
misses an snmp poll/response.

Example: I'm polling a remote Cisco 7206, 2621 and Catalyst 2924. We lost
power to our local router (mrtg running on Linux stayed up) for about
30 seconds plus the reboot time. Mrtg attempted to poll the remote boxes
but didn't get a response.  Approx 5 minutes later (next poll), mrtg did
in fact get a response, however the calculation of Octets In/Out was far
above the maximum speed of the interface (no where near realistic). The
remote devices were not rebooted and the snmp counters were not reset.

The chart reflected a one-time value of say 8,000,000 b/s when the
interface is a T1 (max 1,544,000 b/s). Same thing has happened on various
other interfaces including 10baseT and 100baseT's.

I'm not absolutely sure the issue is simply a missed poll, or maybe a
combination of a missed poll plus an snmp 32-bit counter rollover.

On the surface it would appear that code should be added to compare the
currently calculated bits/second to the MaxBytes value, and if exceeded,
discard the value. The current snmp counter values would still need to be
written to the log file, but not the five-number summary entry.

Anyone have any thoughts on this?

Rich

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi