This is part 2 of our SNMP basics tutorial.
Terminology is one of the needlessly complicated parts of SNMP. But don’t fear, it’s really very simple once understood. This page will help you understand basic SNMP terminology. We’ll start with the more important concepts in the next few sections, and a glossary of other terms can be found at the bottom of this page.
OIDs and MIBs
Two crucial SNMP concepts are OIDs (Object Identifier) and MIBs (Management Information Base).
SNMP works by querying “Objects”. An object is simply something that we can gather information about on a network device. For instance, an object might be something like Interface Status. Querying Interface Status would return a variable – the interface could be Up, or Down. SNMP identifies objects like with an Object Identifier, or OID.
OIDs are very structured, and follow a hierarchical tree pattern – much like a folder structure on your computer. Unlike folders however, all SNMP objects are numbered. So, the top level after the root is ISO, and has the number “1”. The next level, ORG, has the number “3”, since it is the 3rd object under ISO, and so on. OIDs are always written in a numerical form, instead of a text form. So the top three object levels are written as 1.3.1 not iso\org\dod. Because of the way the tree is structured, most SNMP values we’re interested in will always start with the same set of objects – 18.104.22.168. And, in the example above, Interface Status would have an OID of 22.214.171.124.126.96.36.199.1.8. Have a look at the graphic below for an example of what part of the OID tree looks like.
Most network management software has the ability to display the OID tree in some way. For example in the screenshot below, the OID tree is displayed in a folder-style list:
Closely related to the concept of an OID, are MIBs. A MIB is like a translator that helps a Management Station to understand SNMP responses obtained from your network devices. All SNMP devices generally support something called MIB-2, which is a standard set of objects that can be monitored. The Interface status object mentioned earlier is part of this group, as are most system objects like CPU or memory utilization.
Just to complicate things a little further, manufacturers can supply custom MIB files for their hardware. As an example, some hardware supports environmental monitoring of temperature or fan speeds. These objects aren’t found in the standard MIB-2 group, so manufacturers supply custom MIB files to add support for these features. The custom MIB files are loaded in to your NMS to tell the software which SNMP objects can be queried, and how to display the results.
Manufacturers register their custom objects under a different part of the OID tree from MIB-2. In the OID tree graphic above, you can find manufacturer’s objects in the blue section, under “Enterprise.” So, Microsoft would be 188.8.131.52.4.1.311 in the hierarchy, and Juniper is 184.108.40.206.4.1.2636.
MIB files themselves are difficult to read, they are only meant to be imported, or “compiled” by a Management Station. Below is an example of a Cisco MIB file for environmental monitoring.
Cisco provides a useful resource for looking up OID values, and downloading MIB files for any of their devices. You can access it here.
Community strings are another important SNMP concept. Community Strings are like passwords. They are used to allow authorized users to access the SNMP agent on a device. Unfortunately, many admins never change community strings from the defaults “Public” for read-only, and “Private” for read-write.
Community Strings can be configured as read-only(RO), or read-write(RW). As the name implies, read-only strings only allow information to be pulled from the agent. However, read-write strings are much more powerful, and can allow re-configuration of many of a device’s properties. Use extreme caution when implementing read-write strings. Earlier versions of SNMP transmit strings in clear-text, raising another security risk. See versions below.
Some general SNMP terminology that you may come across:
• Agent: A process that monitors devices for problems and sends alerts to a monitoring station.
• Community Strings: Like passwords. See earlier in this article for more information.
• Get: SNMP sends a get request to device it monitors to retrieve specific information.
• Get Next: A getnext command is used by SNMP to get the next variable in a set – for instance in a table.
• Informs: Like Traps, but sent by the agent with a request for the management station to confirm receipt. Supported in v2 and up.
• Management Station (aka Network Management Station or NMS): The software configured to receive and collect information sent from SNMP agents.
• MIB: Management Information Base. See the beginning of this article for more information on MIBs.
• MIB Browser (or MIB Walker): A tool that can pull data from SNMP enabled devices, helping to identify which objects respond to a query.
• Notification: Same as a “Trap”. V2c and up use the term Notifications to refer to a Trap.
• OID: Object Identifier. See the beginning of this article for more information on OIDs.
• Object: The things SNMP gathers information about. Examples are Interface status, or CPU utilization.
• Polling: An NMS will poll, or ask devices for their status regularly.
• Set: SNMP can use a Set command to change settings on a device.
• Trap: SNMP sends a trap, or unsolicited message sent from an agent to a management station when some important event is detected. This is the opposite of polling.
• Variable: Variables are the actual status of an object – up/down, 90% CPU used, etc.
• Version 1: Original version of SNMP, community strings sent in plain text, very weak security.
• Version 2c: SNMP v2c was developed to fix some of the problems in v1. However multiple versions were developed, none truly addressing the problems with v1. V2c is the most common flavour, and has enhanced protocol handling over v1, resulting in slightly improved operations. However, security is still an issue because it uses plain-text community strings.
• Version 3: The newest version of SNMP, v3 supports full security and authentication. Should be used if possible, especially on untrusted networks.
In our next article we’ll look at some practical ways you can use SNMP tools to make your job a little easier.