How To Monitor Any Device With SNMP

Here's an SNMP primer for any junior person on your IT team - they may actually be younger than the protocol itself. After all these years, for most devices that you need to monitor, starting with SNMP before you try anything else is a safe bet.

The Simple Network Management Protocol—or SNMP—is, from a network administrator’s standpoint, the best thing since sliced bread. In most cases it gets the job done and it is present in virtually every network-connected equipment and the majority of IoT devices. This includes switches and routers, servers, desktop computers, firewalls, load balancers, cameras, environmental sensors, etc. If the device connects to a business network, chances are it supports SNMP. To prove our point, we’re about to explore how to monitor any device with SNMP.

About SNMP

Despite its misleading name, SNMP is rather complex technology. However, just like you don’t have to be a mechanic to drive a car, you don’t have to be an SNMP expert to use it to monitor any device. To be totally honest, in the context of monitoring any device, SNMP is not that complex. Let’s see. SNMP provides a way for local systems which, for lack of a better term, we’ll simply call SNMP managers to read information from and write information to remote devices. These devices make a certain number of parameters available to the manager either in read-only or in read-write mode. An SNMP-enabled printer, for instance, would have read-only parameters for the level of its ink cartridges or the total number of pages printed. Similarly, an SNMP-enabled server would have CPU utilization, available disk space, or system temperature. SNMP is also a network protocol that specifies how a manager communicates with the devices using GET requests to read parameters and SET requests to write them.

MIBs and OIDs

In the SNMP world, every parameter is called an object. And each object is identified by a unique Object Identifier or OID. The OID structure is hierarchical, with each level separated by dots. For example, a typical OID would be 1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3. The first thing that may strike you is how cryptic and unfriendly this is. How can one even tell what parameter this OID is referring to? Fortunately, MIBs come to our rescue. A MIB, or Management Information Base, is a special type of file whose purpose is to match Objects’ numerical IDs to more meaningful Object names. For instance, the MIB entry for the object mentioned above would read: Iso(1).org(3).dod(6).internet(1).private(4).transition(868).products(2).chassis(4).card(1).slotCps(2).cpsSlotSummary(1). cpsModuleTable(1).cpsModuleEntry(1).cpsModuleModel(3).3562.3 The MIB could also include a more readable description of the object. Manufacturers of devices that support SNMP typically publish MIB files which include every object available on their devices. As for SNMP monitoring tools and management systems, they often come with the most common MIBs already built-in. And if one of your devices’ MIB is not included, it can be usually compiled from the manufacturer’s file.

SNMP’s Security (Or Lack Thereof)

When SNMP was created, back in 1988, network security was not much of a concern. Consequently, there is not much security built into the technology. SNMP requests and responses don’t use encryption and they use a very crude authentication mechanism. Each SNMP request includes a community string, which can be thought of as a rudimentary password. The community string in the request must match that of the target device. As for the target devices, administrators can configure two different types of community strings: read-only and read-write. By default, many devices used to have public as their default read-only community string and private as their read-write one. Some even still do, saying a lot about how security is not a priority with SNMP. To address the lack of security in the initial version of SNMP, SNMPv2 and later SNMPv3 have been introduced. However, security (authentication, encryption) comes at a price - v3 is slower and thus is not supported by many older devices. For devices in networks that are private (or not open to the internet), some admins prefer to stay on SNMPv2 for optimized speed/security/load settings.

Using SNMP To Monitor Any Device

When using SNMP for monitoring purposes, only a handful of OIDs is of interest. They come in three types: gauges, counters, and statuses. Gauge-type OIDs are used for things like processor utilization or the percentage of free memory. Counter-type OIDs are typically used to count bytes in and out of a device’s interfaces. Networking equipment has one such set of counter-type OIDs for each interface. Status counters are typically used for signaling device status with relevant values, for example, 1=OK, 2=Down, 3=Error, 4=Unknown, etc. A typical SNMP monitoring tool will read the values of the relevant OIDs at regular, predefined intervals. For gauge-type OIDs, the values are typically stored in a database and displayed on the tool’s dashboard in either numerical or graphical form. Many tools will graph the evolution of the parameter over time.

For counter-type OIDs, things are more complex. The number of bytes in and out of an interface is not an interesting metric, so instead of using it as is, we compute the interface’s bandwidth utilization in bits per second. Let’s see how it’s done. The SNMP monitoring tool reads the value of the counter at a regular, known interval. (Five minutes is a common interval.) It stores the value in its database but, instead of displaying it as is, it first subtracts the previous value of the counter from the current one to get the number of bytes in the interval. It then multiplies that number by eight (the number of bits in a byte) and divides it by the number of seconds in the interval to get the average bandwidth utilization in bits per second. That is the value that the tool will display or plot on a graph.

It is important to realize that this method averages the measurements. For example, imagine a 100 Mbps interface where, in the five minutes between samples, the traffic level was at 100 Mbps for 150 seconds and at 0 for 150 seconds. It would display an average bandwidth utilization of 50% even though the interface was saturated for half of the five minutes. This is the main shortcoming of every SNMP monitoring tool.

Summary

To monitor any devices with SNMP, here’s what you have to do: Configure a read-only community string on all the devices you need to monitor. The exact procedure varies from device to device. Make sure you use the same community string on all devices. Next, configure that same community string in your SNMP monitoring tool. And last but not least, let your monitoring tool discover your device or manually add them. You’ll be able to start monitoring the devices in no time.

More on SNMP:

Monitoring SNMP devices

Receiving SNMPv3 notifications

snmpsnmpv3