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