SNMP Explained: What You Must Know About Monitoring via MIB and OIDs

Scope of SNMP

First of all, a thought on why one would make use of SNMP. As its name Simple Network Management Protocol says, you can use it for network management. That was simple, wasn't it? But let's continue that train of thought. In order to manage, you need information. This is where SNMP has its greatest value. It gathers all the data and puts it into context, which makes you able to track issues, to make decisions based on real data and to take control wherever necessary. That's what network management is all about. And that's why you as a network admin use SNMP to gain the precious monitoring information you need about your network.

SNMP Communication Partners

Secondly, we should talk about how SNMP management information is transferred. In principle, the SNMP data packages travelling through your network are just like normal messages sent and received between two (or more) communication partners. In the case of SNMP, the communication partners are the managing entity on the one hand, for example the computer running your monitoring software, and the managed devices on the other, like your switches, server racks, coffee machine, or what else you want to monitor.

Let's illustrate this with a more human example. Imagine your boss wants to know how the hardware in the company server room is doing, and so he is interested in the temperature values, for example. So you head downstairs to the server room and suddenly feel like you are on vacation in Jamaica. You go back up to let your boss know that the temperature in the server room would make a Finnish sauna feel cold. Or, another situation could be that you are in the server room, although nobody told you to check the temperature there, and you decide to inform your team because you feel like you have been hit with the heat of a thousand suns, which is not the normal situation. You send an email to the whole IT department, not knowing if anyone will even receive it and who and when someone will react to your message.

Basically, you can compare these procedures to a normal client/server communication. If it is the managing entity (or your boss upstairs in the IT department) that starts the communication to solicit a response from you, this works like pull (or poll). If it is a managed device (this was you downstairs in the server room, temporarily taking over the duty of a temperature sensor) that sends out an SNMP message upon an event, this works like push. In SNMP terminology, a GET request for example follows the pull model, whereas an SNMP trap is "pushed out" without any previous request.

OIDs

Now, let's talk about your message. In your case, the management information regards the server room temperature. Depending on what you monitor, this can also be a printer's toner status, the traffic on a switch, or the level of coffee beans in your coffee machine. Each of these pieces of information is called an object and needs an individual address to become the content for an SNMP message. This address is called an OID and stands for object identifier.

If you want the managing entity and a managed device in your network to successfully communicate, both communication partners need to know which pieces of management information, that is which OIDs, are available. Let's assume you have a printer and it wants to tell your monitoring entity not only how much toner is left (OID1), but also how many sheets it has already printed (OID2) and how many sheets are currently queued (OID3). So both your printer and your monitoring entity need to know that those three are valid pieces of management information, and thus valid OIDs, no matter which of your SNMP communication partners is the sender or receiver of the messages regarding your printer.

MIB

So how do you ensure that both your managing entity and your managed device communication partners are up to date on available OIDs and on what actually lies behind these addresses? I'll answer this question in a minute, let's use a bit of imagination first. Imagine how many different network devices in the world exist and how much specific management information is available in total! Hence counting OIDs would be pointless, unless you just really need a hobby and don't mind that you'll never be able to do anything else again. Of course, not all OIDs from all manufacturers may be relevant for you, but you will still have a considerable number of OIDs concerning your network. It would be more than a painstaking and time consuming, or even impossible, adventure to manually manage every single OID.

Luckily, the so-called MIB exists. The short form of Management Information Base, the MIB is an independent format for the definition of management information. In clear text: the MIB contains OIDs in a well-defined way. Or, from your perspective, you can find every object that you can get from a given device in its MIB files. By the way, you can easily recognize a MIB file via the extensions .my or .mib, or .txt.

Now let's get back to the question of how you can ensure that all SNMP communication partners are up to date on available OIDs. Device manufacturers normally deliver the necessary MIB files along with their products that support SNMP. So the communication is usually safe on the side of your managed devices. On the side of your monitoring entity, it is your turn as an admin to become active. You can first try if it works, of course, but if it doesn't, line up and install the missing MIB files in the way your monitoring tool needs them. If you are having trouble finding a MIB file (for whatever reason), try looking on the web or contacting the manufacturer's support.

Hierarchical Structures Everywhere

1.3.6.1.2.1.2. This may look like a freaky chapter numbering, however, this is an OID. Its structure is not "any number whatsoever" but actually really organized. Reading an OID from the left to the right basically corresponds to following an OID tree structure from the root to its leaves. Hopping from node to node gives you an impression of who is involved in the hierarchy underlying SNMP. Let's follow the nodes of the above mentioned OID.

• 1 - International Organization for Standardization (ISO)
• 3 - Identified organizations according to ISO/IEC 6523-2
• 6 - US Department of Defense (DOD)
• 1 - Internet protocol
• 2 - Internet Engineering Task Force (IETF) management
• 1 - MIB-2
• 2 - Interfaces

Note that this illustration is by no means complete. For example, the MIB-2 has 228 child nodes in total and all of them have many child nodes, and so on. (SNMP pro tip: You can find all important standard bject definnitions for monitoring with SNMP in the MIB-2. You may easily guess that from the names system, interfaces, IP, ICMP, TCP, UDP, transmission, SNMP, etc.) Some mighty branches of the OID tree are the internet and the private branches. The internet branch contains the largest part of all existing OIDs (roughly > 90 %), not least because it contains the private branch in which you can find the specific MIB file for specific devices of 46,000 currently listed enterprises and organizations. Conveniently, from a private branch OID you can also read the manufacturers as listed by the Internet Assigned Numbers Authority (IANA), for example

• 1.3.6.1.4.1.9 Cisco MIBs
• 1.3.6.1.4.1.311 Microsoft MIBs
• 1.3.6.1.4.1.2636 Juniper MIBs
• 1.3.6.1.4.1.8117 North American Association of Food Equipment Manufacturers MIBs

This also means that from the private node 1.3.6.1.4 on, all following OID parts may be specific to manufacturers.

The Value of MIBs

OIDs can theoretically have the impressive length of up to 40 (or even unlimited number of) tuples with an arbitrary number of digits. Easily readable for machines, but not for humans. The MIB is here to help. It is like a lexicon, always providing a name, a definition and a description for given objects, including meta information like data type and access rights. You can compare OIDs to IP addresses and MIB files to DNS entries. On the protocol level, the address in number format is used. Based on MIB information, or DNS information respectively, the addresses are mapped to more human friendly names and completed with additional information.

Wrapping It Up

In order to understand and work with SNMP, keep in mind that you cannot do without basic specifications like MIB and OIDs. If you are a professional network administrator, OIDs and MIB (files) are your bread and butter in the SNMP context.

Looking For A Challenge?

Interesting stuff, wasn't it? Let's stop here for today having some fun with the things you have learned. Here are some tasks:

• Explore some standard MIB files with a tool that allows you to, like the Paessler MIB Importer (free). Pro tip: If you are a Paessler PRTG monitoring software user, the MIB folder under the installation path of your PRTG instance is a little treasure chest.
• Check the capabilities of your own devices. Pro tip: To easily get an overview, you can run an SNMP walk over the main branch OID with a suitable tool, like the Paessler SNMP Tester (free).

New Horizons

Stay tuned on our SNMP blog series if at least one of the following questions has already crossed your mind:

• How do I enable SNMP on Windows, Linux, or MacOS?
• What you must know about SNMP, its versions, and FCAPS
• How can I become an SMI and ASN.1 pro?
• SNMP doesn't work, can somebody out there help me!?