Skip to main content

MIBs

Management Information Base (MIB) files are virtual databases of variables describing the conditions at each SNMP device. MIBs provide a hierarchical structure of uniquely identify managed objects and their individual object identifiers (OIDs) that can be read and used by the Trapd LAM.

The Trapd LAM is shipped with a base set of MIBs in the $MOOGSOFT_HOME/etc/mibs directory. These contain all of the basic imports that complex MIBs require. If custom MIBs are required these must be parsed using the Mibparser utility. See Parse MIBs for Trap Integration for more information.

MIB Best Practice

Moogsoft cannot provide enterprise-specific MIBs as part of the distribution. Customers are responsible for supplying their own vendor- or enterprise-specific MIBs that are current to the devices sending the traps. Traps are processed incorrectly if these MIBs are out-of-date or missing.

If there is no MIB for a trap, you can write a basic MIB to cover the required translation and OID-to-name conversion. If you do not have any specific MIBs you have to create trap processing modules manually.

MIB Loading Sanity Checks

The Trapd LAM is strict with OID definitions in MIBs and performs a number of sanity checks on the them. Some of the scenarios and logging warnings you can expect in these checks include:

MIB name already in use

If there are two or more MIBs with the same name, the Trapd LAM uses the last read MIB and ignores any previous versions. It is important to ensure that there are no discrepancies like this as you could have undesired behavior in trap resolution.

Imported MIB not found

If a MIB imports and references another MIB that cannot be found in $MOOGSOFT_HOME/etc/mibs, any definitions using that reference are not resolvable. In this scenario, the Trapd LAM logs the following warning message :

WARN: Import [SNMPv2-SMI] not found for Mib [NET-SNMP-MIB]

Conflicting names in MIB

If the same name is used to identify two or more different OIDs, only the first entry is accepted. For example, if internet is defined twice in two different OIDs, the Trapd LAM only considers the first to be part of the MIB:

internet OBJECT IDENTIFIER ::= { dod 1 }
internet OBJECT IDENTIFIER ::= { dod 2 }
directory OBJECT IDENTIFIER ::= { internet 1 }

In this example, directory is considered to be {dod 1 internet 1}.

Conflicting OIDs in MIB:

If a MIB maps the same OID to two or more different names, only the first definition is accepted. The Trapd LAM logs subsequent definitions with a warning message such as:

netSnmpModuleIDs OBJECT IDENTIFIER ::= { netSnmpEnumerations 1 }
snmpDomainsConflict OBJECT IDENTIFIER ::= { netSnmpEnumerations 1 }

In this example, { netSnmpEnumerations 1 } is defined twice under two different names so only the latest occurrence of { netSnmpEnumerations } is considered part of the MIB. Here is an example of an OID conflict warning log message:

WARN : OID Conflict: Full OID [1.3.6.1.4.1.8072.3.1] has conflicting names, Mib [NET-SNMP-MIB -> snmpDomainsConflict] & Mib [NET-SNMP-MIB -> netSnmpModuleIDs]

Conflicting names between two or more MIBs

If the same OID is mapped to multiple names between two or more MIBs, the Trapd LAM only accepts the first definition. The Trapd LAM logs any subsequent definitions with a warning message:

WARN: OID Conflict: Full OID [1.3.6.1.4.1.42.1.1] has conflicting names, Mib [MIB-1 -> deviceTemperature] & Mib [MIB-2 -> deviceTemp]

Object extends unknown parent

If an object definition references a parent which is not defined or imported in the MIB, then that object is not resolvable. The Trapd LAM logs a warning message such as:

snmpDomainsConflict OBJECT IDENTIFIER ::= { snmpv3 1 }

In this example, snmpv3 has not been defined or imported, so snmpDomainsConflict cannot be resolved and Trapd LAM displays a log warning message:

WARN: Mib [NET-SNMP-MIB]:Unable to resolve and find SINGLE parent for Mib Object [snmpDomainsConflict ::= { snmpv3 1 }]

Hex String Output values

MIBs are used to define SNMP OIDs (Object Identifiers) and their attributes, so the agent know how to interpret a trap message. When you define an object in the MIBs, you can give it optional attributes such as:

  • DISPLAY-HINT: Used to indicate to the agent how to display a value of this object.

  • DEFVAL: Tells the agent the default value for the object and the input type (string, hex, integer).

The Trapd LAM uses these definitions in MIBs to determine when a value should be outputted as a hexadecimal string (hex). If they are not used, the Trapd LAM attempts to output the value in human-readable ASCII format, which may not be as intended. For example, if a hex format is not specified, an object with the value 4D4F4F47 is outputted as the ASCII string MOOG when the intended output is 4D4F4F47.

DISPLAY-HINT Guidelines

The DISPLAY-HINT clause instructs Trapd LAM how to display the hex string using the format: [digits]x[delimiter].

  • [digits] represent the number of bytes to group before delimiting

  • [delimiter] is a single character which is used as the delimiter.

For example, an object with DISPLAY-HINT "1x_" for value of 9e3f4242 outputs as follows: 9E_3F_42_42

An object with DISPLAY-HINT "2x-" clause for the same value outputs as a string: 9E3F-4242.

A varbind with DISPLAY-HINT "1x:" and a value of 5cf9388e7dd4 outputs 5C:F9:38:8E:7D:D4.This is the expected output for a MAC address.

DEFVAL Guidelines

The DEFVAL definitions specify a hex type and also result in Trapd LAM outputting values as hex strings. The default format is 1x.

A DEFVAL definition specifies a hex type in the following format, normally followed by an upper or lower case 'h':

DEFVAL { '0000-ffff'h }
DEFVAL { ''H }

If both DISPLAY-HINT and DEFVAL define recognisable hex formats, the DISPLAY-HINT format is used. If neither DISPLAY-HINT or DEFVAL definition is correctly specified, the octet string values use the following logic:

  • If the value contains only printable ASCII characters (a range of 0x20 to 0x7E, and \t \n \v \f \r) then the value is output as a human readable ASCII String.

  • If the value does not contain the above specified printable characters then the value is outputted as a Hex String in the default format of 1x.

If a Hex DISPLAY-HINT or a Hex type DEFVAL is supplied for a MIB object then the Trapd LAM outputs these values as hex strings, regardless of any syntax definitions. The Trapd LAM does not resolve or associate syntax definitions.

Base Set of MIBs:

The base set of MIBs that is shipped in the $MOOGSOFT_HOME/etc/mibs directory contains the following:

AGENTX-MIB.txt
IPV6-UDP-MIB.txt
SNMP-MPD-MIB.txt
BRIDGE-MIB.txt
LM-SENSORS-MIB.txt
SNMP-NOTIFICATION-MIB.txt
DISMAN-EVENT-MIB.txt
MTA-MIB.txt
SNMP-PROXY-MIB.txt
DISMAN-SCHEDULE-MIB.txt
MoogTraps.txt
SNMP-TARGET-MIB.txt
DISMAN-SCRIPT-MIB.txt
NET-SNMP-AGENT-MIB.txt
SNMP-USER-BASED-SM-MIB.txt
EtherLike-MIB.txt
NET-SNMP-EXAMPLES-MIB.txt
SNMP-USM-AES-MIB.txt
HCNUM-TC.txt
NET-SNMP-EXTEND-MIB.txt
SNMP-USM-DH-OBJECTS-MIB.txt
HOST-RESOURCES-MIB.txt
NET-SNMP-MIB.txt
SNMP-VIEW-BASED-ACM-MIB.txt
HOST-RESOURCES-TYPES.txt
NET-SNMP-PASS-MIB.txt
SNMPv2-CONF.txt
IANA-ADDRESS-FAMILY-NUMBERS-MIB.txt
NET-SNMP-TC.txt
SNMPv2-MIB.txt
IANA-LANGUAGE-MIB.txt
NET-SNMP-VACM-MIB.txt
SNMPv2-SMI.txt
IANA-RTPROTO-MIB.txt
NETWORK-SERVICES-MIB.txt
SNMPv2-TC.txt
IANAifType-MIB.txt
NOTIFICATION-LOG-MIB.txt
SNMPv2-TM.txt
IF-INVERTED-STACK-MIB.txt
RFC-1212.txt
TCP-MIB.txt
IF-MIB.txt
RFC-1215.txt
TRANSPORT-ADDRESS-MIB.txt
INET-ADDRESS-MIB.txt
RFC1155-SMI.txt
UCD-DEMO-MIB.txt
IP-FORWARD-MIB.txt
RFC1213-MIB.txt
UCD-DISKIO-MIB.txt
IP-MIB.txt
RMON-MIB.txt
UCD-DLMOD-MIB.txt
IPV6-ICMP-MIB.txt
SCTP-MIB.txt
UCD-IPFWACC-MIB.txt
IPV6-MIB.txt
SMUX-MIB.txt
UCD-SNMP-MIB.txt
IPV6-TC.txt
SNMP-COMMUNITY-MIB.txt
UDP-MIB.txt
IPV6-TCP-MIB.txt
SNMP-FRAMEWORK-MIB.txt