SNMP OIDs Identifies elements on a network

In order to properly monitor network alarms, alarm points need to be identified. Just like your apartment or house address indicates a specific location by country, state, city, zip code then street, and finally a house number, an SNMP network has Object Identifiers (OIDs) that define components to the SNMP and SNMP Management processes.

SNMP Object Identifiers (OIDs) point to individual network objects that are maintained in a database called a Management Information Base, often referred to as a MIB. A MIB basically catalogs the structure of the network alarms being monitored (like a map catalogs the streets of a city) and uses the OIDs to keep track of the individual components (like the address to a house or other location). In this analogy, an SNMP OID would be the equivalent to the address the fire truck would drive to if the fire alarm sounded. If a fire broke out at your house, and you called the fire department with a GPS address (representing the Object ID or OID), the fire department would have to look that up in its MIB to determine the correct street address to drive to in order to put out the fire.

In the alarm networking world, where SNMP OIDs describe specific locations and conditions in the network, The OID allows the MIB to translate the location of the event into an easy to understand condition to a network technician.

The branch of the MIB object identifier tree that represents managed elements used by DPS Telecom equipment.

What does an SNMP OID look like?

Here's an example:

While it may look daunting, the OID follows a simple structure, with each "dot" segment identifying part of the underlying network element. Thinking of it like our home address analogy, 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, that would be represented by the number 102). Because of this structure, very specific elements can be identified and located even in very complex networks. An SNMP Manager (such as a DPS TMon) 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 (and understood) by people.

When the SNMP Manager, in this case a TMon, requests the value (or condition or state of an alarm) 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 numeric address and attach a "human readable" description to it. This allows the SNMP Manager to present the value of the alarm condition with the identifying description of the labelled 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 = 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.

MIB Diagram
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.

Needless to say, 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, if the MIB doesn't have a cataloged entry, the SNMP Manager is blind to that object. In order 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 MIB definitions for their applications. One client, James, needed to be able to identify all of the printers on his LAN via SNMP. He needed to ask every device for a user defined OID, at user defined time intervals. He needed to then be able to email any reporting events as they occurred to the SNMP monitor, and he needed to do this at a price that didn't break the bank.

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. We were able to provide a solution where custom OIDs 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 type of solution saved them money and down time and increase the use of existing equipment for the customer.

Finally, while each SNMP OID is unique, 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 associated specifically with their device.