nv-l
[Top] [All Lists]

Re: unable to collect on ifInOctets

To: nv-l@lists.tivoli.com
Subject: Re: unable to collect on ifInOctets
From: Leslie Clark <lclark@US.IBM.COM>
Date: Thu, 2 Mar 2000 20:30:06 -0500
Remember this one from last week or so? I just ran into it. Mib variables
that were once collectable are now grayed out and not collectable....

In this case, in was on NT, and the error message said that the variable
was
of type Counter32. Netview expect Counter, or Guage, etc, not the 32
version.
This sounded like a problem we had in V4 caused by the automatic loading
of a mib that redefined the MIB II inteface mib variables. I went looking
and
found that the customer had loaded the ciscoif-v1smi.mib (that's what his
copy was called, anyway) which includes entries that say Counter32=INTEGER,
then defines all of our favorite variables as Counter32. Unloading this mib
file made everything nice again, that is, ifInOctets is Counter as Netview
expects.

We had something like this at a certain PTF level in V4, which loaded
rfc1573b.v1mib without the prereq rfc1442v.smi. The workaround was to
unload rfc1573b and anything that depended on it, obtain and load
the rfc1442v.smi, and reload rfc1573b.v1mib. Neither of these are on the
system
I am working with this week, so I cannot look at them to see what the
pattern is.

 Can anyone tell me 1) why I want to load the ciscoif-v1smi.mib, and
2) is there a proper way to do it so that I don't trash rfc1213 (assuming
that is
where the MIB II interface table is).

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web