Managing NerveCenter - Managing Management Information Bases (MIBs) - Troubleshooting: Managing Management Information Bases (MIBs) -
Configuring NerveCenter to Use the New MIB      A MIB won't load

Troubleshooting: Managing Management Information Bases (MIBs)

The following list contains some common problems that users encounter when updating the NerveCenter MIBs.

As mentioned in Adding or Removing MIB Definitions, MIB modules are dependant on information in other MIB modules. Although a MIB module may compile by itself, there may be problems with dependencies with other MIB modules. This section gives suggestions on how to solve compilation errors.

---

   If MibComp finds a dependency or definition error, it will repeat the error for each MIB module encountered.
To find where the problem begins, run MibComp with the -clean and -trace arguments and note when the problem first occurs.

---

A MIB won't compile

Problem: The vendor ASN1 definitions that you added are not formatted correctly.

Solution: Check for spelling and format.

See Troubleshooting ASN.1 files on page 223.

Problem: The mibcomp.txt file is not formatted correctly.

Solution: Check to make sure the appropriate lines are included in the file and are not commented out.

See Adding or Removing MIB Definitions.

Problem: The ASN1 file does not exist in the directory referenced in the mibcomp.txt file.

Solution: Move the file to the specified directory or correct the path in the mibcomp.txt file.

Problem: You must run the command from the mib directory (mibs on UNIX).

Solution: Change to the correct directory and run the mibcomp command again.

See Compiling the NerveCenter MIB.

Problem: User or file permissions are not set correctly, so mibcomp cannot create or update the MIB file.

Solution: Check user or file permissions and correct them, if necessary. See your operating system documentation.

Problem: Redefinitions of MIB entity enumerations across SNMPv1, v2c, and v3.

Example: WARNING: enumeration conflicts during merge for ifType (continuing)

Solution: These warnings can be safely ignored. Some values, such as ifType or ifOperStatus, have been redefined for different SNMP versions.

Problem: More than one MIB module has defined entities with the same name.

Example: /opt/OSInc/bin/mgrtool: check_names: Duplicate name with different OIDs: ds1 OID1: 1.3.6.1.2.1.10.18, OID2: 1.3.6.1.3.2 continuing (since -i option was used)

Solution: First, find which MIB modules are defining the duplicated name. When MibComp finds a second defintion, it creates an error message similar to the above example. Next, you must research the MIB modules to see if either module has been replaced with a compliant MIB module.

Problem: A MIB module depends upon a definition form another MIB module.

Example: find_type(): unknown type: SnmpAdminString
mibcomp: unable to compile and resolve standard-v3/v3-tgt.my

Solution: Look at the IMPORTS clause of the module that produced the error. In the example, v3-tgt.my declares that SnmpAdminString is to be imported from SNMP-FRAMEWORK-MIB. A search of the modules shows that SNMP-FRAMEWORK-MIB is defined in v3-arch.my. Therefore, you must name v3-arch.my before v3-tgt.my.

Problem: More than one MIB module provides a name for an OID.

Example: /opt/OSInc/bin/mgrtool: Warning: Duplicate OIDs with different names.
The first name will appear before the second name.
OID: 1.3.1.4.1.9.7.99999.2, First name: cwRsrcPartCapabilityRpmV2R0160,
Second name: ciscoWanModuleCapabilityV2R00

Solution: Often this is not a problem but should be investigated. In the example, two different Cisco MIB modules state two different names for the same OID. Which device and version of IOS is encountered at run-time will likely resolve which way the OID will be handled. Check which devices you are currently running and whether you need to have the MIB modules with the duplicate names mibcomp.txt. A review of your Cisco devices may show that the MIB module that names the first occurrance is not needed.