What is SNMP?

SNMP works with two main components: an SNMP agent and an SNMP manager. The agent is installed on the device to be monitored and consists of a small application that collects metrics locally to send to a remote location. The SNMP manager is on the receiving end. A series of commands can be used on the manager’s side to retrieve info from the agent. The agent itself can, when necessary, send info in the form of SNMP traps, one of the most well-known features of the SNMP protocol. How SNMP works is basically as a protocol for collecting metrics and allowing a remote agent and a manager to exchange them in a structured way.

Agent and manager communicate through one of the three versions of SNMP. Depending on the version, different settings have to be configured. The configuration of SNMP is not complex, considering its age. The question “what is SNMP” can mostly be answered by explaining that it is a protocol to monitor and maintain network devices through the use of an agent and a manager. But there is more to it.

The SNMP agent is the software component responsible for responding to queries, carrying out requests, and issuing traps. Mainly, an SNMP agent has three tasks. The first is to reply to an SNMP get from the manager, which is a type of query to get information about the managed device. Similarly, as the second task, an SNMP manager can also issue a set query to manage or configure the managed device or, alternatively, to an SNMP agent, which then carries the request to the host it is present on.

Finally, there is the trap signal that the agent can issue to the manager to communicate if an error condition has occurred. Therefore, an SNMP agent is not just a passive application waiting for the manager, because it can also actively send back information whenever reputed necessary or configured to do so. An SNMP agent is therefore the core of the SNMP protocol by virtue of collecting metrics and signaling errors back to the SNMP manager.

The SNMP manager is at the other end of an SNMP setup relative to the agent. SNMP managers are generally installed on an NMS (Network Management Station), of which there may be multiple instances per network depending on the number of managed devices.

An SNMP manager takes care of the monitoring and related computational tasks. The hardware resources that are needed for it to run are thus higher than for an agent. While SNMP can be used directly from the command line, nowadays monitoring tools with dashboards and automated queries are more commonly implemented as SNMP managers. While an SNMP agent is a small piece with rather fixed functionalities, an SNMP manager can be complex software that supports SNMP queries, but it is not limited to them only.

SNMP originated during the early 1980s from a group of collaborators who viewed the efforts at the time as both unimplementable and unworkable. So SNMP has a long history, spanning over three decades. During these years, multiple versions of the protocol have been released. The original, v1, has mostly disappeared from all modern infrastructures, unless a specific device could not be upgraded to SNMP v2.

The main issue that v1 did not solve was security. It essentially had no security at all, leaving it to the underlying channels over which the SNMP messages were sent.

SNMP v2, particularly its slightly more secure variant v2c, is by far the most popular to this day. It came out in 1993 and added new commands as well as a party-based security system that did not catch on. SNMP v2c succeeded by introducing a simpler community-based security scheme and 64-bit counters (the original SNMP had 32-bit only).

Parallel to SNMP v2c, v2u was developed as a compromise that offered better security than v1 while being less complex than v2. Although it was not used much, it was an important inspiration for v3.

SNMP v2, and all its variants, are not compatible with v1 since the messages use a different header and protocol data formats.

Version 3 came in the early 2000s with support for cryptography and a plethora of different concepts, conventions, and terminologies. However, the core protocol was not changed much, and many vendors preferred to remain on the more tested and less computational-heavy v2 and v2c.

Setting up SNMP monitoring is normally a low effort task. Since plenty of devices come with an SNMP agent already installed, it only needs to be activated to start monitoring the device. To activate the agent, you configure it to accept active requests, mostly SNMP get and set commands. However, it is usually best to refer to the individual device’s manual first since vendors have different implementations of the protocol.

Once the agents are activated, the monitoring solution of choice can now retrieve information and metrics on the device via SNMP. Often, this is accomplished through a complete pull of all SNMP data on the managed devices, an SNMP walk command. How and what is pulled depends on the operator or the monitoring tool. For example, Checkmk uses service discovery through SNMP by retrieving only the very first records (OIDs) on a device. Based on this information, further queries are made as required. This avoids the need to first transfer large quantities of data and this considerably speeds up the discovery step for SNMP devices, which can take hours on large infrastructures.

Once all is discovered and the agents active, the actual monitoring can take place. The managed devices are ready to listen for the manager requesting metrics. The collection of these metrics happens on the agent-side, after which they are sent over the network for the manager to analyze them. Occasionally, an agent may send a trap back to the manager, but most of the time it is the manager that asks the agents for data.

OID (Object Identifier) is an identifier mechanism for naming any type of object or concept. It is an international standard for addressing anything in a very specific way. SNMP adopted the concept, but did not originate it.

An SNMP OID is a long sequence of numbers separated by dots. For instance, 1.3.6.1.2.2.1.5 is an OID that unequivocally identifies with an object in a hierarchical logical tree. OIDs should be read from left to right, starting at the root which can only be either 0 or 1 or 2, depending on the arc of the following standards:

• 0 is for ITU-T (one of the three sectors of the International Telecommunication Union).
• 1 is for ISO (International Organization for Standardization).
• 2 is for a joint ISO/ITU-T arc.

Both organizations define child nodes, the subsequent numbers, respectively, and may delegate assigning authority to others.

In the example above, the 1 is for ISO, the 3 for “identified organization”, the 6 for the American Department of Defense and down through the tree to the very last digit that addresses a specific “thing”, depending on the context. This thing is often a variable that identifies a metric specific to the device that is monitored. It can be the temperature of a processor, for instance, or the uptime of a host.

Some subtrees are generic, others belong to specific organizations or companies and specify their product. Those are monitored by SNMP, which makes the OID vital for knowing what and where every device supporting SNMP is. Each vendor is free to specify their own subtrees, depending on their devices and what they do.

These long series of numbers would be of scarce usefulness if it was not possible to retrieve what each number means. To do so, another piece of how SNMP works is used, the MIB (Management Information Base).

A MIB in SNMP translates OIDs into human-readable form by providing names, definitions, and descriptions for the values. As each vendor has a different classification for their own OID subtrees, a MIB comes as a table that is used to group instances of a tabular object.

Rows are present in each MIB and each of them represents a series of information or settings belonging to an object. For instance, a row may contain a name, type, and current temperature of a hardware sensor; another may include the number of hardware ports, the max and current speed of each, and the firmware version in a switch. The more complex the device, the more digits are used to index all its features, metrics, and settings.

Every vendor maintains and updates their MIBs. These are human-readable dictionaries that match the OIDs specific to the device in question. The protocol only needs OIDs to function, the MIBs are mostly there to inform network administrators of what is to be found at every OID.

SNMP get is the simplest operation done in SNMP monitoring. The SNMP manager uses the get command to retrieve information from the agent by specifying the OID of what should be retrieved. An OID can be obtained for each SNMP get command, retrieving a single metric on each sweep.

Depending on the version of the SNMP protocol used, a community string may also be necessary to authenticate with the agent. Commonly, it has to be provided. The address of the target devices is obviously needed. The agent will take care of retrieving the correct data at the desired OID.

What if you want to retrieve a large amount of metrics via SNMP without having to specify each one? SNMP walk does exactly this. It uses the SNMP GetNext command to retrieve a whole subtree starting from an OID downward. All variables in the subtree below the specified OID are queried and passed back to the SNMP manager.

If no OID is specified, but only the address of a device, all the variables belonging to that device will be polled. This returns a large quantity of data and may be a slow operation.

In SNMP monitoring, this is one of the most useful ways to check the health of a device or a part of your network. An SNMP walk is a simple and easy to automate way to obtain a good view of one or more managed devices.

SNMP traps are how agents communicate with the manager without being polled. SNMP traps enable an agent to notify a manager of significant events immediately, without waiting to be queried.

The agent has both generic and enterprise-specific types of traps to send. The generic ones are to signal common events like a link being down or up again, the device being reinitialized, or authentication failures. Enterprise-specific traps depend on the vendor and can encompass dozens of different traps.

Whatever type of traps are sent, the manager listens for it and can take action, according to the implemented network monitoring tool. As SNMP traps are the closest to what a real-time notification system is within the protocol, they are of great use in network monitoring for alerting.

SNMP community strings act like passwords to authenticate between SNMP agents and managers. A community string is an alphanumeric string which was notoriously set to “public” by default, but this is no longer common. The string is sent in plain text over the network in SNMP v1 and v2c, and if it matches, access to the agent is granted.

SNMP v3 introduced encryption of community strings, so they are no longer sent in a cleartext over the network, which avoids spoofing. The encryption has to be pre-configured, though. Encrypting SNMP can slow down monitoring as it puts a heavier toll on the agent mainly but also on the manager. So it has to be weighed against the capabilities of the underlying hardware.

Regardless of the SNMP protocol version used, it is strongly advised to change the default community string, as it is well known to attackers. SNMP is not big on security and, unless the network section is closed off from the outside, configuring a custom community string and enabling encryption provide only a moderately secure environment for monitoring.

SNMP monitoring is best explained as a combination of agents on managed devices and one or more managers that collect and analyze the data received from the agents. The data that can be retrieved via SNMP is suitable for getting information on the status of devices on the network and is thus ideal for IT monitoring. The monitoring solution acts as a central processor that retrieves data in a targeted manner from the SNMP agents on the monitored devices, or serves as the recipient of event messages.

The most important point that speaks for the use of SNMP lies in its power to retrieve information from many devices in your network quite easily. Its large adoption within the industry over the years makes implementing an SNMP monitoring solution an easy choice. Many network monitoring systems, like Checkmk, make use of SNMP for collecting information. SNMP is “already there” in most networks, so making use of it in your monitoring often as easy as just activating the agents.

SNMP offers further advantages compared with other network monitoring protocols. It is capable, for example, of retrieving metrics about your cooling, voltage, or temperature sensors. These metrics are not commonly available in other protocols and need a specific agent. Even with the latter, it is not always as easy as with SNMP to get these types of metrics.

Retrieving information via SNMP does not require high-level access rights on the device. A shared community string is sufficient to start exchanging data between the agents and managers. Setting up monitoring via SNMP is therefore simpler than with other solutions.