OID Definitions In MIB Files

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.

Think of an OID like an address, but starting at a much higher level than you would usually start at. To describe where someone lives, you can start at the galaxy level, (1) then move on to the solar system they live in, (1.3) and then find the planet they live on, (1.3.6) and so on and so forth. Eventually, you will find the person and they would be the last number in the OID. This system makes it easy to systematically represent very specific events in a very large set of data.