SNMP OID: Introduction for Industry Professionals

Need SNMP remote monitoring?

Our NetGuardian RTUs collect alarm and analog data from devices that don't support SNMP and can forward it to an SNMP manager or master station.

Browse RTUs

Need to monitor SNMP alarms?

Our T/Mon Master System is perfect for managing SNMP devices.

Master Stations

If you're a professional responsible for managing your organization's large-scale network, read on. Here we will break down the concept of OIDs so you can take that knowledge with you onto the job and keep your enterprise's operations running smoothly.

An OID in SNMP 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 facility? There's an OID for that.

How do you obtain the numerical OID for a named object in SNMP?

Once you can answer "what is OID in networking?" you can explore how to retrieve the numerical OID for a named object in SNMP. To get an SNMP object's OID, you'll typically:

1. Use MIB Browser Tools: MIB browser tools are available both online and as downloadable software. These tools allow you to search for specific named objects (like sysDescr, sysUpTime, etc.) and view their associated OIDs within the MIB files.
2. Identify the MIB File Containing the Object: Find the correct MIB file that contains the object you're interested in. This is usually provided by the device manufacturer, as each manufacturer may define its own custom MIBs alongside standard ones.
3. Search Within the MIB File: Once you have the correct MIB file, you can open it with a text editor or use a MIB browser to search for the named object. The file will include the object name along with its corresponding OID in a hierarchical structure.
4. Obtain the Full OID: To get the complete numerical OID, you'll need to resolve the OID path based on the structure defined in the MIB.
5. Use SNMP Get or Walk Tools to Verify: After obtaining the OID, you can verify it using SNMP tools like SNMP Get or SNMP Walk. These tools allow you to query the object on an SNMP-enabled device to make sure the OID corresponds to the named object you are looking for.

How do you 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:

We're partway through this OID. What do we know so far?

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. Let's continue:

Now we know we're working with an RTU from DPS

Notice how long the "device manufacturer" number is ("2682"). There are a lot of manufacturers out there, and they all must have a unique integer value. This section of the OID also told us that we're working with an RTU, which collects alarms from non-SNMP equipment. Native SNMP gear would have a different OID value here. Let's finish reading this OID now:

Now you've completely read through this OID

Now you know that you're dealing with the state of discrete alarm point #1 on an RTU manufactured by DPS Telecom. 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 now...

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 telecom, 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 DPS Telecom equipment.

What does an SNMP OID look like?

Here's an example: 1.3.6.1.4.1.2681.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. T/Mon) 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.

When the SNMP Manager, a T/Mon 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 (a "yes or no" question, often referred to as a discrete alarm in the alarm monitoring world). The SNMP Manager would look up the corresponding reference in the MIB in order to "poll" (ask) if there is a car in the driveway at 123 Main St. The MIB references 123 Main St. and translates it into the OID of your driveway. In our example OID above, it would be 123 Main St = 1.3.6.1.4.1.2681.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: Nope. 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.

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 and can transmit data, he SNMP Manager is blind without the MIB. For a condition or device to be monitored, it must have a corresponding MIB definition.

Here at DPS, we will occasionally have clients that require specific MIBs for their applications. One client, James, needed to be able to identify all of the printers on his LAN via SNMP by asking every device for its OID at user-defined time intervals. He needed to email any reporting events to the SNMP monitor, and he had to do that without busting his budget.

Another client had a need to send certain SET commands to remote units at some microwave sites. The units were not capable of sending those commands. Our solution had custom OIDs that were configured with variable bindings to accept SNMP Traps. This allowed monitoring and control of the remote microwave sites with the ability to toggle up to 40 discrete relays in the system. This solution saved them money and down time and increased the use of existing equipment for the customer.

Finally, 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.