nv-l
[Top] [All Lists]

Re: Cisco MIBs

To: nv-l@lists.tivoli.com
Subject: Re: Cisco MIBs
From: Jeanie Cham <yccham@NCS.COM.SG>
Date: Mon, 4 Oct 1999 17:08:02 +0800
Hi Sergio,

I'll try loading the CISCO-TC-NO-U32.my mib instead of CISCO-TC.my.  I think my 
problem may most
probably be due to that.

Thanks for your help.

cheers,
Jeanie

Sergio Cardona F wrote:

> Hi Jeanie:
>
> See the attached file it could help you.
>
> Regards,
>
> Sergio Cardona.
>
> Jeanie Cham wrote:
> >
> > Hi,
> >
> > I read some Cisco documentation on loading Cisco MIBs into Netview.
> > There's a sequence to be followed:
> >   SNMPv2-SMI.my
> >   SNMPv2-TC.my
> >   SNMPv2-MIB.my
> >   RFC1213-MIB.my
> >   IF-MIB.my
> >   CISCO-SMI.my
> >   CISCO-PRODUCTS-MIB.my
> >   CISCO-TC.my
> >
> > I tried to follow the sequence, but failed in loading SNMPv2-TC.my,
> > SNMPv2-MIB.my, CISCO-TC.my.  My ultimate goal is to load
> > CISCO-STACK-MIB.my but failed as well.  I think it may be because of the
> > failure to load the prerequisites mentioned.  Or is it that I've missed
> > any other MIBs?
> >
> > Has anyone loaded CISCO-STACK-MI.my successfully?  I need help
> > urgently....
> >
> > Thank you.
> >
> > regards,
> > Jeanie
>
>   ------------------------------------------------------------------------
> this text was extracted from:
> http://207.82.250.251/cgi-bin/linkrd?http://www.cisco.com/public/mibs/app_notes/mib-compilers
> Fecha: enero 13/99
> -----------------------------------------------------------------------
>
> MIB compilers ...  What are they?  Why do you care?  What issues might
> you encounter and how can you workaround those issues?
>
> Most Network Management Systems (NMSs) provide a way for the user to
> "load" MIBs.  Loading a MIB is a way that an NMS can learn about new
> MIB objects - what their names are, what their object identifiers are,
> what kind of datatype (e.g. Counter) they are, etc, etc.
>
> Somewhere along the way, these loaded MIBs will need to be parsed.
> This may happen at the same time a MIB is loaded.  It may happen later,
> e.g. when an NMS application runs.  The software that performs the
> parsing is typically referred to as a "MIB compiler".
>
> In a perfect world, any syntactically correct MIB could be
> successfully parsed by any vendor's MIB compiler.  Unfortunately we
> do not live in a perfect world.  Different MIB compilers may exhibit
> different "quirks".
>
> Cisco makes continuous efforts to ensure that the MIBs published to
> customers are syntactically correct.  Cisco also attempts to avoid
> certain MIB constructs which may be legal, but have proven to be
> problematic in some of the more popular NMS products.  Despite these
> efforts it is not possible to satisfy the "quirks" one might find in
> all of the MIB compilers in the field - at least not with one set of
> MIB files.
>
> Below are some of the more common problems and how you might work
> around them.  It should be noted that if you encounter any of these
> problems with your vendor's MIB compiler (with the exception of the
> RFC 14xx vs RFC 19xx issue) it is due to a deficiency in that MIB
> compiler.  It is suggested that you urge your vendor(s) to fix their
> compiler(s).
>
> 1) Mismatches on datatype definitions
>
>    For example:
>         MIB mumble defines
>                 SomeDatatype ::= INTEGER(0..100)
>         MIB bumble defines
>                 SomeDatatype ::= INTEGER(1..50)
>
>    or:
>         MIB mumble defines
>                 SomeDatatype ::= DisplayString
>         MIB bumble defines
>                 SomeDatatype ::= OCTET STRING (SIZE(0..255))
>
>    While this should (hopefully) never be the case for any Cisco MIBs,
>    these situations have been observed in several standard RFC MIBs.
>
>    Many times the former example is considered to be a trivial error
>    and the MIB will load successfully with a warning message.
>
>    Many times the latter example is considered to be a non-trivial
>    error (even though the two definitions are essentially equivalent)
>    and the MIB will not be successfully parsed
>
>    If your mib compiler treats these as an error and/or you wish to
>    get rid of the warning messages, pick one of the definitions and
>    edit the other MIBs that define this same datatype so that their
>    definition matches.
>
> 2) Object Identifier redefinitions
>
>    You will likely encounter this is you load OLD-CISCO-CPU-MIB.my,
>    OLD-CISCO-ENV-MIB.my, OLD-CISCO-MEMORY-MIB.my and
>    OLD-CISCO-SYSTEM-MIB.my.  Although there certainly may be other
>    instances which cause this error.
>
>    The problem is that, for example:
>         OLD-CISCO-CPU-MIB.my defines
>                 lcpu    OBJECT IDENTIFIER ::= { local 1 }
>         OLD-CISCO-ENV-MIB.my defines
>                 lenv    OBJECT IDENTIFIER ::= { local 1 }
>
>    When loading these two MIBs, the MIB compiler may complain about
>    the lcpu OBJECT IDENTIFIER being redefined with a new name: lenv.
>    The OLD-CISCO-MEMORY-MIB.my and OLD-CISCO-SYSTEM-MIB.my similiarly
>    give new names to { local 1 }.
>
>    Often this is treated as a trivial error and the MIB will load
>    successfully with a warning message.
>
>    If the MIB will not load successfully, or you wish to get rid of
>    the warning message, pick one of the names and edit the other MIBs
>    so that all of the MIBs are using the same name.
>
> 3) Definitions of built-in datatypes
>
>    Many MIB compilers have some built-in knowledge of some datatypes -
>    e.g. DisplayString.  Some of these compilers will complain if they
>    see a definition for these datatypes in a MIB - e.g. DisplayString
>    is defined in SNMPv2-TC.
>
>    The workaround is to remove or comment out the offending definition
>    in the MIB file.
>
> 4) Alternate SIZEs
>
>    The following is a perfectly valid (syntactically) example:
>         MyDatatype ::= OCTET STRING (SIZE(0 | 5 | 20))
>    indicating that a value of type MyDatatype will either be 0, 5 or
>    20 octets in length.
>
>    Some MIB compilers do not like this syntax.  Usually a sufficient
>    workaround is to pick one of the sizes and remove the others.  It
>    is suggested that you keep the largest size.  For example, the
>    above example would be changed to:
>         MyDatatype ::= OCTET STRING (SIZE(20))
>
> 5) "Odd" OBJECT IDENTIFIERs
>
>    I refer to these as "odd" because they do not refer to a node in
>    the SMI (like most OBJECT IDENTIFIERs do).  however they are
>    perfectly valid (syntactically).  A common example is the "null
>    object identifier" - i.e. "{ 0 0 }".  Some MIB compilers do not
>    care for OBJECT IDENTIFIERS which do not correspond to a node in
>    the SMI.  The following are examples of MIB syntax which could
>    cause problems for these compilers:
>
>         zeroDotZero OBJECT IDENTIFIER ::= { 0 0 }
>
>         myMIBObject OBJECT-TYPE
>             DEFVAL { {0 0} }
>
>    The workaround is to remove or comment out these types of
>    references in the MIB file.
>
> 6) Trap definitions
>
>    In SNMPv1 MIBs, traps are defined via the TRAP-TYPE macro.  In
>    SNMPv2 MIBs, traps are defined via the NOTIFICATION-TYPE macro.
>
>    Some MIB compilers don't like to see these definitions in the MIB
>    files they are parsing (i.e. they do not support these macros).
>
>    If this is the case, you can remove the offending trap definitions,
>    or comment out the offending definitions (i.e. put the MIB comment
>    delimiter '--' at the beginning of the offensive lines).
>
> 7) RFC 14xx based compilers vs RFC 19xx based compilers
>
>    RFCs 1442-52 define the "party-based SNMPv2".  These RFCs are
>    obsoleted by the newer Draft Standard RFCs 1902-08.
>    MIB-syntax-wise there are very few differences between these two
>    versions of SNMPv2.  However, there are some differences.
>
>    Cisco's MIBs are currently using the RFC 14xx rules.  It is
>    expected that the move to RFC 19xx will be made in the
>    not-too-distant future.
>
>    If your MIB compiler supports SNMPv2-style MIBs, it probably
>    supports one of these two versions of SNMPv2.  You should not have
>    any problems if your compiler is RFC 14xx based, however there is a
>    known problem with CISCO-TC.my if your compiler is RFC 19xx based.
>
>    If you don't know which version of SNMPv2 your compiler is based
>    on, try to load the CISCO-TC.my MIB.  If it loads successfully,
>    then you're fine.  If your compiler is RFC 19xx based it might
>    complain about the following line:
>
>         Unsigned32 ::= TEXTUAL-CONVENTION
>
>    Unsigned32 is a predefined datatype in RFC 19xx.  For this reason,
>    we provide an alternate version of CISCO-TC.my - namely
>    CISCO-TC-NO-U32.my, which, as the name implies, does not include a
>    definition for Unsigned32 (since the compiler already knows about
>    this datatype).  Load this MIB instead of CISCO-TC.my.
>
>    We now also have a PNNI-MIB-NO-U32.my. This is the same as
>    PNNI-MIB.my except that it does not include a definition for
>    Unsigned32. If you need the PNNI-MIB and are using an RFC 19xx
>    based compiler, load the NO-U32 version of this MIB.
>
> 8) Load ordering
>
>    Many MIBs use definitions that are defined in other MIBs.  These
>    definitions are listed in the IMPORTS clause near the top of the
>    MIB.
>
>    If MIB mumble imports a definition from MIB bumble, some MIB
>    compilers require you to load MIB bumble prior to loading MIB
>    mumble.  If you get the load order wrong, the compiler will
>    probably complain about the things that were imported - claiming
>    that they are "undefined".
>
>    The following is a list of MIBs that many other MIBs import from,
>    and the order that these MIBs should be loaded.  This will probably
>    take care of 95% of your load order issues (i.e. most of the other
>    MIBs can be loaded in any order).
>
>         SNMPv2-SMI.my
>         SNMPv2-TC.my
>         SNMPv2-MIB.my
>         RFC1213-MIB.my
>         IF-MIB.my
>         CISCO-SMI.my
>         CISCO-PRODUCTS-MIB.my
>         CISCO-TC.my
>
>    NOTE: If you are loading the v1 versions of these MIBs, the MIB
>    filename will actually look like "IF-MIB-V1SMI.my" - i.e. a
>    "-V1SMI" is added to the name of MIBs that have been converted from
>    v2 to v1.  The exception to this is the RFC1213-MIB.my MIB, which
>    only exists as a v1 version (i.e. there is no
>    RFC1213-MIB-V1SMI.my).
>
>    If you attempt to load some other MIB and get complaints about
>    "undefined" items, look at what MIBs this MIB is importing from.
>    make sure that you have loaded all of these other MIBs first.


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

Archive operated by Skills 1st Ltd

See also: The NetView Web