As part of our ongoing series into monitoring and infosec. We’ll break down the concept of OIDs so one can take that knowledge with you onto the job and keep your monitoring operations running smoothly.
An OID in SNMP/LDAP is an “Object Identifier”. It’s an address used to identify devices and their statuses. Want to know the temperature reading coming from a sensor at your mountaintop remote base? There’s an OID for that.
Need to know if a robotic arm is working in science commitee or a switch was just flipped on the time machine’s neutron flow regulator? There’s an OID for that.
Want your router to automatically tell you the bandwidth usage for your home network without hitting speedtest.net? You guessed it; there’s an OID for that too.
How does one read an OID
The format of an OID can be confusing at first. It’s a huge string of numbers like this:
1 . 3 . 6 . 1 . 4 . 1 . 2682 . 1 . 4 . 5 . 1 . 1. 99 . 1 . 1 . 6
Let’s start by looking at the first few numbers, which rarely change:
The first part of the OID will be the same for every piece of equipment you’ll ever use:
| Number | Label | Explanation |
|---|---|---|
| 1 | iso | ISO is the group that established the OID standard and root tree for OID/MIBS/LDAP records |
| .3 | org | An organization will be specified next. |
| .6 | dod | The US Department of Defense (established the early internet). |
| .1 | internet | Communication will be via Internet/network. |
| .4 | private | This is a device manufactured by a private entity (not gov’t). |
| .1 | enterprise | The device manufacturer is classified as an enterprise. |
Since we’re partway through this OID. What do we know so far?
We know that a private enterprise will be declared as the manufacturer of this SNMP device. This will be true for virtually every device you work with. That makes “1.3.6.1.4.1…” an almost-universal prefix to OIDs akin to DNS’s .com.
From here let’s continue with the organizations’ OID:
| Number | Label | Explanation |
|---|---|---|
| .50391 | dallasMakerspace | This device’s manufacturer is Dallas Makerspace |
| .1 | dmsAlarmControl | This is an Alarm & Control Device built by DMS |
| .4 | dmsRTU | This is a Dallas Makerspace Remote Terminal Unit (RTU) |
One now knows that they are working with an RTU from DMS Infrastructure Committee
Notice how long the “device manufacturer” number is (“50391”). This is the manufacture’s IANA private enterprise number. As there are a lot of manufacturers out there each with their own needs they all must have a unique integer value for reference.
In this section of the OID we also can defer that one is working with an RTU, which collects alarms from non-SNMP equipment. Native SNMP enabled equipment would have a different OID value here.
From here we are now within the MIB tree.
| Number | Label | Explanation |
|---|---|---|
| .5 | AlarmGrid | We’re working with a discrete alarm point (not a control relay or analog) |
| .1 | AlarmEntry | An alarm point will be specified |
| .1 | Port | This is the Port for this alarm point |
| .99 | Address | This is the Address for this alarm point |
| .1 | Display | This is the Display for this alarm point |
| .1 | Point | This is the alarm Point number |
| .6 | rtuAlarmState | This is the state of the alarm point (set, clear, etc.) |
By now one should be able to completely OID and should have devices they are interfacing with the state of discrete alarm point #1 on an RTU manufactured by Dallas Makerspace. Not bad for a string of numbers, huh?
Who decides on the structure of SNMP OIDs?
OIDs are defined in the SNMP MIB file, a kind of “codebook” for SNMP. The manufacturer (DPS Telecom in this example) spells out the second half of the OID for their own devices by supplying a MIB file to their users. The first half is established by a standard referenced “RFC” MIB used worldwide.
Let’s consider the OID from a slightly different angle
To monitor network alarms, you must know your alarm points. Your apartment or house address indicates a specific location by country, state, city, zip code, street, and house number. SNMP has Object Identifiers (OIDs) that define each thing for the manager and agents.
SNMP Object Identifiers (OIDs) point to network objects stored in a database called the Management Information Base, often referred to as the “MIB”. A MIB holds the structure of the network alarms being monitored (like a map of the “city”), and it uses the OIDs to keep track of the individual components (like the address to a house or other location). In this example, an SNMP OID is like the address the fire truck would drive to if the fire alarm sounded. What if a fire broke out at your house, and you called the fire department with GPS coordinates (representing the Object ID or OID)? The fire department would have to look that up in its MIB to determine the correct street address.
In Information Technology, SNMP OIDs describe specific locations in the network. The OID allows the MIB to translate the location of the event into a status description for your network technicians.
The branch of the MIB object identifier (OID) tree used by Dallas Makerspace equipment.
What does an SNMP OID look like?
Here’s an example: 1.3.6.1.4.1.50391.1.2.102
While it may look daunting, the OID follows a simple structure, with each “dot” segment identifying part of a network element. Going back to the home address example, the beginning of the Object Identifier tells us the hemisphere of the world, the country, state, city, zipcode, street address and eventually leads us to our driveway. In the above OID, the specific “driveway” is 102. With this structure, very specific elements can be identified and located even in very complex networks. An SNMP Manager (ex. telegraf) translates these SNMP OIDs into a value that is then assigned readable labels in the Management Information Base (MIB). This allows the SNMP manager to produce messages that can be read by people. Much in the same way that DNS does for a web site named address to IP address.
When the SNMP Manager, an instance of telegraf in this case, requests the value (“state”) of any object it is monitoring, it sends a message with that object’s OID to its Management Information Base. The MIB will decode the address and attach a text description to it. This allows the SNMP Manager to present the value of the alarm condition with the identifying description of the labeled alarm.
So for example, let’s say the SNMP Manager wants to know if there is a car in the driveway of your house which is a boolean question more often referred to as a discrete alarm. The SNMP Manager would look up the corresponding reference in the MIB in order to ask via a pull if there is a car in the driveway at 1825 Monetary Ln, Ste 104, Carrollton, TX 75006. The MIB references 1825 Monetary Ln, Ste 104 and translates it into the OID of the Makerspace’s driveway.
In our example OID above, it would be 123 Main St = 1.3.6.1.4.1.50391.1.2.102. The driveway (or alarm point we want to monitor) would be represented by the “102” portion of the address. The “value” reported is the current state of the driveway 102 : occupied by a car or not.
The sensor at the driveway reports back: 0 the Boolean integer for FALSE thus meaning Nobody’s in the driveway.
The manager uses the MIB to decode OIDs from each device
This message is captured by the SNMP Manager which again uses the Management Information Base to tie the OID sensor message that was reported by the “driveway sensor” (a simple “No” response) back into the human readable 123 Main St. which is displayed.
Since the MIB is both the schema and registry of OID objects. If an object does not have an OID listed within an MIB, the SNMP Manager cannot identify it. Even if that object has a sensor, an OID, and can transmit data. A SNMP Manager is blind without the MIB. For a condition or device to be monitored, it must have a corresponding MIB definition.
Remember that the first several pieces of each OID are almost always the same. These upper location levels are defined by a series of standard reference within the MIB. These series are called RFCs, or Requests for Comments. The RFCs that define SNMP OIDs are part of a larger group of RFC documents that define the Internet as a whole. Individual vendors create their own MIBs that only include the OIDs for their device.
Writing new mibs
One can easily create their own MIBs, OIDs, and even register for free as an authority with IANA to own their own public OID tree.
If one is to define a MIB that is to share with the world, one will need a place in the tree that wont conflict with any other MIBs written by others. The enterprises branch of the tree is specifically for individuals and organizations to define their own objects. You can apply for your own enterprise OID on the IANA Pen Application page.
A great tutorial on Writing your own MIBS is up on the Net-SNMP wiki.
Where to go from here
OIDs and MIB go way beyond just SNMP. They’re also used with SSL and AD/LDAP. For now review the relatated articles, additional resources, and build your own lab on the VCC Community Grid.