Download White Paper				11 of 23

When I look at my MIB files, I don't see long strings of numbers like that

That's because each element of an OID only needs to be defined once. Remember, in ASN.1 notation, once a term is defined, it can be used as a building block to define other terms. The last number of an OID - its most specific element - refers back to the more general elements defined earlier in the MIB.

Here's how the last four elements in our sample OID are defined in the DPS Telecom MIB:

dpsInc OBJECT IDENTIFIER ::= {enterprises 2682}
dpsAlarmControl OBJECT IDENTIFIER ::= {dpsInc 1}
dpsRTU OBJECT IDENTIFIER ::= {dpsAlarmControl 2}
dpsRTUsumPClr TRAP-TYPE
      ENTERPRISE dpsRTU
      VARIABLES { sysDescr, sysLocation, dpsRTUDateTime }
      DESCRIPTION "Generated when all points clear."
      ::= 102

Look at how each term is defined as the term that came immediately before it in the OID, plus one more element. For example, dpsInc is enterprises (1.3.6.1.4) plus one more element, called 2682. The next term, dpsAlarmControl, is dpsInc (1.3.6.1.4.2682), plus one more element, called 1. And so on. Each term in the OID is defined as an extension of earlier terms, going all the way back to the root term, iso.

An OID is meaningless unless every element it refers to is specifically called out and identified in the MIB. So when you're compiling your MIB files on your SNMP manager, you need to supply not only the OIDs defined by your equipment vendor, but also OIDs for public entities: iso, org, dod, internet, and so on.

		Download White Paper				11 of 23