[mrtg] Re: Help with 3COM router

Andrew MJ. Pike ampike at emagine.bs
Tue Aug 13 20:47:53 MEST 2002


Thanks for the help. What I did in the end was to add the port feeding
the router to the MRTG site. That confirmed that the router was in fact
giving the right numbers.

The issue was with our upstream provider, their switch was reporting the
bandwidth in bits, and their tech thought it was bytes, so we have been
getting 1/8th of the bandwidth we have been paying for.

Thanks again

Andrew

-----Original Message-----
From: Alex van den Bogaerdt [mailto:alex at ergens.op.HET.NET] 
Sent: Monday, August 12, 2002 6:09 PM
To: Andrew MJ. Pike
Cc: MRTG users
Subject: Re: [mrtg] Help with 3COM router

Andrew MJ. Pike wrote:
> 
> We are using mrtg on a 3Com router. The problem is that we are only
> measuring 480 kbps, where our upstream provider is showing us as using
> between 3-4mbps.
> 
> Any ideas? Could it be a counter issue where the counter is rolling
> over? The unit is set to poll every 5 mins, and it is on a 100mbps
> circuit.

This roll over would happen at 2^32 / 300 = 14,316,557 bytes/second.
Not even close to what the provider is reporting.

In another mail you already said it is not a bits vs. bytes problem.

That leaves (I think) three possibilities:

1) the provider multiplies by 8 two times
2) your router doesn't report correct stats
3) your mrtg configuration doesn't show the stats properly


How I would investigate:

Try to saturate your line.  When the line is fully utilized,
you know what it should transfer.

Now fetch the counters using snmpget / snmputil / whatever other
utility you have around.  The OIDs to monitor are
   1.3.6.1.2.1.2.2.1.10.<instance number>
   1.3.6.1.2.1.2.2.1.16.<instance number>

make sure you're looking at the right instance.  You probably
can do this by looking (once) at 1.3.6.1.2.1.2.2.1.2.<instance>
and comparing the description to what you think it should be.

Suppose your router is on a 5 Mbps link.  Also suppose the right
instance to monitor is 1 and the line is saturated.  When I'd run
the following script ...

    snmpget router public 2.2.1.10.1 2.2.1.16.2
    sleep 60
    snmpget router public 2.2.1.10.1 2.2.1.16.2

... I'd expect an increase of 60*5,000,000/8 = 37,500,000 bytes
(it will be a bit lower probably).

When you can saturate the link for 10 minutes, you can be sure
at least one MRTG interval shows near the maximum capacity.
This helps you determine which side is wrong and if it's your
side, where it goes wrong.

HTH
-- 
   __________________________________________________________________
 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
+----------------------------------------------------------------------+
| Technical questions sent directly to me will be nuked. Use the list. |

+----------------------------------------------------------------------+
| http://faq.mrtg.org/                                                 |
| http://rrdtool.eu.org  --> tutorial                                  |
+----------------------------------------------------------------------+

--
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



More information about the mrtg mailing list