[mrtg-developers] Re: cfgmaker reports wrong Max Speed with SNMPv2 (2.10.15)

[Larry Fahnoe]

I agree that it is important not to gratuitously break something in an
effort to fix something else, and that fixing the problem at the
source rather than patching downstream is a good rule of thumb to live
by.

What I'm seeing on these cisco routers is that both ifSpeed (bits/sec)
and ifHighSpeed (Mbits/sec) are being populated.  cfgmaker looks to
see if there is a value in ifHighSpeed, and if so, scales it up and
then uses it.  If ifHighSpeed doesn't contain a value, ifSpeed is
used.  In the case of the T1 interfaces, ifSpeed contains 1544000 and
ifHighSpeed contains 2 thus cfgmaker uses 2000000.

Upon reading the if-mib's definition of ifSpeed I see that it says:

     "If the bandwidth of the interface is greater than the maximum
     value reportable by this object then this object should report
     its maximum value (4,294,967,295) and ifHighSpeed must be used
     to report the interface's speed.  For a sub-layer which has no 
     concept of bandwidth, this object should be zero."

So, if SNMPv2 queries are being used, it seems reasonable for cfgmaker
to consider the values of both objects and decide the speed via logic
similar to the following:

    if ( ifSpeed < 4,294,967,295) {
        speed = ifSpeed
    } elsif ( ifHighSpeed > 0) {
        speed = ifHighSpeed * 10^6
    } else {
        speed = 0
    }

The primary rationale is to avoid using the rounded value from
ifHighSpeed when there is a more precise value in ifSpeed.  Comments?

--Larry

On Tue, Nov 23, 2004 at 04:31:28PM +0100, Alex van den Bogaerdt wrote:
> On Tue, Nov 23, 2004 at 07:50:57AM -0600, Larry Fahnoe wrote:
> 
> > I pointed out what I was observing and where I thought the problem
> > was.  As I see it, when using SNMPv2 against a bunch of cisco routers
> > here, some interface speeds are being reported incorrectly by mrtg,
> > and yes, I consider this a bug.  I see that cfgmaker seeks to make a
> > bunch of decisions about what the correct values should be, and I see
> > that there is some attempt in the code to adjust to improper values.
> 
> Suppose cfgmaker would make the other decision and use what is, in your
> case, the correct value.  Don't you agree that there's a not so slim
> chance that others will have problems?
> 
> > Given the number of cisco routers out there, what is your opinion of
> > the problem that I've reported?  Are my observations and judgment off
> > base?
> 
> IMHO problems should be fixed at the root.  Patching at the wrong place
> will introduce problems.
> 
> cfgmaker tries to help.  
> 
> ..."to try and wrestle some better information from willing
>     livingston and cisco routers ... (may not work)"...
> 
> It may not work.
> 
> (Perhaps I'm not looking at the most recent cfgmaker.  No problem,
> my comment still holds.)
> 
> Alex
> 

-- 
Larry Fahnoe, Fahnoe Technology Consulting, fahnoe at FahnoeTech.com
952/925-0744      Minneapolis, Minnesota       www.FahnoeTech.com 

--
Unsubscribe mailto:mrtg-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:mrtg-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/mrtg-developers