Specifying SNMP OIDs in Custom Probes
Intermapper supports two kinds of OIDs: numeric and symbolic. Symbolic OIDs are available when a MIB is imported into Intermapper.
In addition, Intermapper supports three kinds of OID expressions: Get-Next, Trap-Conditional, and Index-Derived.
Numeric OIDs
Numeric OIDs contain only numbers separated by periods. Preceding periods are ignored. A trailing period is allowed if there is only one subid.
Examples
.1
1.
1.3.6
Invalid Examples
1 (no period)
1.3.6. (trailing period but with multiple subids)
1.3.6.blah (not numeric)
1.3.6.1.2.1.system.sysUpTime.0 (not numeric)
Unlike Net-SNMP, Intermapper ascribes no special meaning to OIDs that begin with a period; all numeric OIDs are considered absolute.
Errors in numeric OIDs are reported by the system to the event log when the error is in a custom probe. Error messages use the following format:
Syntax error in OID "1.3.6.1..1.2"
Symbolic OIDs
A symbolic OID begins with a letter, after ignoring any preceding periods. Intermapper must be able to locate a MIB file that defines the symbols used. The following are types of symbolic OIDs:
- Simple symbols specify a starting symbol and zero or more trailing subids.
- Relative symbols specify a starting symbol and one of more subid symbols.
- Scoped symbols specify the name of the MIB, the scope operator ::, followed by a simple or relative symbol.
Relative and scoped symbols are handy when a symbol is ambiguous, because the same symbol name is defined differently in two separate MIB files. Fortra recommends using the scoped OID form, when possible.
Symbolic names are case-sensitive.
Examples
Simple: sysUpTime sysUpTime.0 enterprises.9.2.3.4.5
Relative: system.sysUpTime
system.sysUpTime.0
Scoped: SNMPv2-MIB::sysUpTime
SNMPv2-MIB::system.sysUpTime.0
Invalid Examples
Simple: sysUpTiime (misspelled; not found)
sysupTime (wrong case)
sys%pTime (disallowed character %)
sysUpTime.0. (bad; trailing period)
Relative: system.ifIndex (bad; ifIndex isn't under system)
Scoped: SNMPv2-MIB.sysUpTime (bad; must use :: for scoped OID)
IF-MIB::sysUpTime (bad; wrong MIB module for sysUpTime)
Errors in symbolic OIDs are reported by the system to the event log when the error is in a custom probe. Error messages use the following format:
Syntax error in OID "sys%pTime"
OIDs Indexed by Strings
Certain MIBs specify tables that are indexed by strings. The net-snmp documentation at http://www.net-snmp.org/tutorial/tutorial-5/commands/output-options.html describes this.
Use the following to enter OIDs:
NET-SNMP-EXTEND-MIB::nsExtendOutLine."LOG"
and use the following to create an SNMP variable:
outLine, NET-SNMP-EXTEND-MIB::nsExtendOutLine."LOG", DEFAULT, ""
Limitations of Symbolic OIDs
- Symbolic OIDs only work if the necessary MIB file is loaded in Intermapper. If Intermapper cannot resolve the symbolic OID using a MIB file, this is considered a syntax error in the symbolic OID. Currently, there is no way to bundle a MIB file with a probe as one file.
- Two or more MIB files might define the same symbol. When this happens, Intermapper picks the wrong definition. You can avoid this by using the scoped OID format.
Get-Next OID Expressions
Intermapper has a special syntax for Get-Next style OIDs when a plus sign (+) is added to the end of the OID.
Normally, when you specify a variable to query in a custom SNMP probe, you specify the complete OID, including the instance. For example, you might specify sysUpTime.0 or ifInOctets.13. For sysUpTime, the .0 specifies the (only) instance. For ifInOctets, the .13 specifies the value for ifIndex 13.
There are occasions when you want to query a variable using a preceding OID. For example, if you want to query the value of ifInOctets for the first interface, but you cannot assume the ifIndex of the first interface is 1, specify the OID as follows:
ifInOctets+
To retrieve the ifInOctets for the interface where the ifIndex follows 13, specify the OID with a plus sign (+). For example,
ifInOctets.13+
The plus sign (+) must immediately follow the OID. Technically, it is not part of the OID, but considered an operator in Intermapper's OID expression language.
Get-Next OID expressions do not work with custom SNMP probes that specify Get-Request queries.
Trap-Conditional OID Expressions
Trap-conditional OID expressions allow you to assign a variable when it occurs in the varbind list of a certain trap. For example, you can set the value of your probe's sysUpTimeCrashed variable to the sysUpTime.0 variable included in the varbind list of a systemCrashed trap. However, you do not want to set sysUpTimeCrashed when you see the sysUpTime.0 value in any other received trap. To restrict the assignment of sysUpTime.0 to only the systemCrashed trap, specify both the systemCrashed trap OID and the sysUpTime.0 OID using the ?: operator. This combination is called a Trap-Conditional OID, or Trap OID for short.
Examples
systemCrashed?:sysUpTime.0
sysTrapOID?:sysContact
SOMEMIB::sysTrapOID.1?:SMIv2-MIB::sysContact
Supported in version 4.4, the legacy format for trap OIDs is a numeric OID followed by an OID. For example,
1.3.6.1.2.1::sysUpTime.0
The legacy format does not allow you to use a symbolic name for a trap OID; this conflicts with the scoped format above. The use of :: for Trap-conditional OID expressions is deprecated. Use ?: instead.
Index-Derived OID Expressions
When querying tables from SNMP devices, you can assign the value of a variable from a row OID index. This technique works even if the values used to index the row are not accessible.
For more information, see Index-Derived Variables in the <snmp-device-variables-ondemand> Section topic.