SNMP Object ID Format for a Specific SNMPv1 Trap

NNMi requires that SNMPv1 traps have object identifiers. The object IDs are created according to the specifications in RFC 2576: Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework.

When using SNMPv1 format, you can specify either generic or vendor specific traps. SNMPv1 generic traps are standard traps that are commonly used across vendors. The SNMPv1 enterprise specific traps are those traps that are generated by a particular vendor's device. The vendor is also known as the entrprise. Both include a vendor name as part of the set of information stored with each trap.

When specifying the SNMP object ID for an SNMPv1 specific trap, include the SNMP object ID for the vendor name and for the trap that you want to see in the console incident views.

The value you enter must be in the format:

<VendorEnterprise>.0.<SpecificTrapNumber>

The <VendorEnterprise> is the object identifier for the vendor that is included in the SNMPv1 trap. The <SpecificTrapNumber> is the SNMPv1 specific trap identification number that is provided by the vendor.

For example, for an SNMPv1 vendor object id 1.3.6.1.3.1.12.9 and specific trap number 12234, the SNMP object ID would be:

1.3.6.1.3.1.12.9.0.12234

When using the wildcard (*) character in the SNMP Object ID (OID) attribute, note the following:

• The OID must be unique.
• Only one wildcard character is permitted within the SNMP OID attribute.
• The wildcard must appear at the end of an OID. For example .1.3.6.1.4.1.* is valid; however, .1.3.6.1.4.*.2 is NOT valid.
• NNMi permits wildcards only in OIDs beginning with .1.3.6.1.4 (private MIBs).
• The wildcard character is not valid for an SNMPv1 generic trap because these traps do not begin with .1.3.6.1.4.
• When checking whether an SNMP Trap Incident Configuration exists, NNMi’s TrapFilter uses only implicit matching when checking generic SNMPv1 traps OIDs. See About the Trap Service Stages for more information about TrapFilter.

• NNMi matches the OID value using the longest match. Specific OID matches take precedence over an OID that is matched using the wildcard character. Click here for an example:

  The following table provides an example of precedence between a specific OID and one that includes a wildcard. This example also illustrates how NNMi uses the longest match.

  Example of Matching Incoming SNMP Traps Using Specific and Longest Match Criteria

  SNMP OID Attribute Configuration	Incoming SNMP Trap	Match Criteria
  .1.3.6.1.4.1.2.3	.1.3.6.1.4.1.2.3	Specific OID takes precedence over the wildcard OID configuration.
  .1.3.6.1.4.1.*	.1.3.6.1.4.1.2	The wildcard OID takes precedence because it is the longest match.
  .1.3.6.1.4.*	Using the specific OID and longest match criteria, this configuration is not the best match for these incoming traps.	See above.

• NNMi handles each OID as if it contains an implicit wildcard. For example, when NNMi receives a trap whose OID is .1.3.6.1.6.3.1.1.5.4.100, NNMi logs the trap as SnmpLinkUp (.1.3.6.1.6.3.1.1.5.4) and generates an SNMPLinkUp incident.
• If a trap's OID matches both an implicit and explicit wildcard, the longer one is used. If the length is the same, NNMi uses the implicit OID. Click here for an example:

  The following table provides an example of precedence between implicit and explicit wildcards.

  Example of Matching Incoming SNMP Traps Using Implicit and Explicit Wildcard Criteria

  SNMP OID Attribute Configuration	Incoming SNMP Trap	Match Criteria
  .1.3.6.1.4.1.2.3.*	.1.3.6.1.4.1.2.3.4	The longest OID takes precedence.
  .1.3.6.1.4.1.2	.1.3.6.1.4.1.2.3	The implicit OID takes precedence.
  .1.3.6.1.4.1.*	Using the length and implicit criteria, this configuration is not the best match for these incoming traps.	See above.