Compiling MIBs

Now that there is no longer a single monolithic MIB file, it can be tricky to get all desired MIB objects compiled into your NMS.

Getting MIB files to compile or load into your NMS is usually a matter of getting the order correct. First, the basic tree structure and textual conventions need to be loaded. Those may be found in the following two MIB files:

SNMPv2-SMI.my

SNMPv2-TC.my

Both of these files should already be loaded into most popular NMS applications like HPOV. These two files should allow you to load other open standard MIBs (rfc1213 for example). Now you have the basics, but you have not yet defined any Cisco branch. To load any of the Cisco-specific MIB files, you need to define the private Cisco branch and Cisco-specific textual conventions by loading these files:

CISCO-SMI.my

CISCO-TC.my

After that most Cisco-specific MIB files should load. If there are any errors complaining about undefined nodes, please check the imports sections of the MIB file you are attempting to load to make sure you have all the prerequisites already loaded.

There are many other issues you may run into. An excellent application note on mib compilers is

http://www.cisco.com/public/mibs/app_notes/mib-compilers

This paper covers many common issues you might encounter while trying to load any MIBs into your NMS.

Getting Trap Definitions for OV and NV

The most recent version of the more popular NMS applications will load traps in the event management portion when you load those MIBs. This method is by far the easiest. But you can also only load the traps directly into the NMS. In the contrib directory, there are some useful files for loading trap definitions into the more popular NMS platforms. For example, http://www.cisco.com/public/mibs/contrib/trapd.41x

is an HP OpenView Network Node Manager trapd.conf format file that will integrate the definitions of approximately 100 Cisco enterprise traps into Node Manager. A script that does the same thing for NetView 6000 can be found at

http://www.cisco.com/public/mibs/contrib/traps.script

It is important to note that these utilities are from the /contrib directory, which means they are provided as is with no guarantees. They may have the majority of Cisco enterprise traps, but not all, particularly the traps from the most recent MIBs.

Identifying Unknown Traps

On occasion, you may encounter some unformatted trap in your log. You may find some cryptic entry such as the following:

 A Minor Tue Dec 02 19:14:02 nms-5505a NO TRAPD.CONF FMT FOR .1.3.6.1.2.1.17.0.1 ARGS(0): 

The OID of the trap needs to be identified. A handy way to identify such unknowns is to download the entire public/mibs directory to a local server. You may then use standard utilities to match up the above OID.

To determine what trap that is, download the entire public/mibs directory structure files and all to a local server for you. Then you can use the following steps to determine what kind of traps you are receiving:

1. Change directories to your local OID directory and use grep to find which MIB file contains the trap OID:

    % cd oid /home/mibs/oid % grep 1.3.6.1.2.1.17 * BRIDGE-MIB.oid:"dot1dBridge"      "1.3.6.1.2.1.17" . . .    You can also use the Windows find utility (advanced tab) to perform a    similar search on a Windows95 system. 

2. Then, change directories to the v1 directory to check out the traps in the BRIDGE-MIB:

    % cd ../v1 /home/mibs/v1 % grep TRAP-TYPE BRIDGE-MIB.my         TRAP-TYPE   newRoot TRAP-TYPE   topologyChange TRAP-TYPE 

3. Take a look at the definitions for these traps:

    newRoot TRAP-TYPE        ENTERPRISE dot1dBridge        DESCRIPTION            "The newRoot trap indicates that the sending agent            has become the new root of the Spanning Tree; the            trap is sent by a bridge soon after its election            as the new root, e.g., upon expiration of the            Topology Change Timer immediately subsequent to            its election. Implementation of this trap is            optional."        ::= 1      topologyChange TRAP-TYPE        ENTERPRISE dot1dBridge        DESCRIPTION            "A topologyChange trap is sent by a bridge when            any of its configured ports transitions from the            Learning state to the Forwarding state, or from            the Forwarding state to the Blocking state. The            trap is not sent if a newRoot trap is sent for the            same transition. Implementation of this trap is            optional."        ::= 2 

4. The entry from the trap.log file was .1.3.6.1.2.1.17.0.1, where .1.3.6.1.2.1.17 represented the dot1dBridge enterprise and the last digit .1 shows this trap is a newRoot trap. Therefore, to properly format this trap, you should load the BRIDGE-MIB file into your NMS.

With the mibs directories and files on a local server, you can use variations on the previous techniques to identify variable bindings in unformatted traps, find the OIDs of objects you need to poll, and many other handy tricks.

In this appendix, we have covered the structure of the Cisco MIB. We told you where to get the Cisco MIB files and how to load them into your NMS once you got them. We also discussed formatting traps in your NMS and how to use some tricks to identify those unformatted traps your NMS is bound to log at some point. Armed with this knowledge, you should be able to make better use of Cisco MIBs and the public online MIBs area.