SNMP Terminology

Terms and Terminology

Let's start with a review of some of the terms and terminology that you are likely to encounter as you start to work with SNMP. Some of them may be unfamiliar at first, but with the help of this chapter you will quickly gain an understanding of them, which will help you in the subsequent chapters.

OIDs

The term OID is short for "Object Identifier" or "Object ID" and an OID is just a set of numbers separated by periods.

An example of an OID that you'll frequently run into is:

                    1.3.6.1.2.1.1.5.0
                

That string of numbers can be used to retrieve the name that has been assigned to an SNMP-enabled device. It's also commonly referred to as the system name or sysName OID.

OIDs have a hierarchical structure that is very similar to how files and folders are organized in a file system.

In other words, "1.3.6.1.2.1.1.5.0" is an OID that is nine levels deep where each level is represented by a number and is separated by a period.

Symbolic Names

As you can imagine, it's hard to remember that "1.3.6.1.2.1.1.5.0" is what you use to get the system name value. To make it easier to know what you are looking at, SNMP supports the concept of symbolic names.

A symbolic name is just a string that's easier to read than a long series of numbers. For example, to get the system name value you can use this symbolic name:

                    SNMPv2-MIB::sysName.0
                

As you can see, the symbolic name immediately conveys more information than the numeric OID.

Under the hood, the SNMP tool that you use to get a value will translate the symbolic name into the associated OID and then retrieve the value.

MIBs

MIB is short for "Management Information Block". The previous section showed you how the symbolic name "SNMPv2-MIB::sysName.0" is mapped to the numeric OID "1.3.6.1.2.1.1.5.0". That mapping is done using a MIB file.

MIBs are text files that describe how that mapping is performed. SNMP-based tools usually have the ability to accept new MIB files and use them to start monitoring values described in them.

For example, if a vendor releases a new kind of networking equipment and they want to make a new set of values available through SNMP, they'll assign each of those values its own numeric OID and then they will create a MIB file that assigns symbolic names to them. They will usually then make that MIB file available through their web site or support portal. If you download the associated MIB file then you can use the symbolic names instead.

It's important to note that you don't need a MIB file to retrieve values from a device. Every device makes all of its values accessible using numeric OIDs. Having a MIB file can make it much easier to understand the results that you get from the device so, in general, if a MIB file is available you will want to download and use it.

Some software tools will describe how they "compile" MIBs. This generally just means that they will take a standard MIB and convert it into a different format for their own internal use. Other tools will only ask that you place new MIB files in a specific directory where they will be automatically picked up and used.

Community Strings

You can think of a community string as a sort of password. It's the secret code that a device expects to see before it will respond to any incoming requests for SNMP data.

When you enable SNMP on a device, the default community string is usually "public". Most devices will let you change this to a different value. It's good practice to change it to something else as soon as possible because it's sometimes possible to get sensitive data from a device using SNMP, including IP addresses and other network details that you may not want to divulge.

Using a custom community string can be thought of as a first line of defense to protect access to your devices.

Next Chapter: Getting SNMP Data