Simple Network Management Protocol - What is SNMP & How Does it Work?

At some point, in the evolution of every organization’s network, it becomes necessary to integrate a monitoring solution to manage the infrastructure. A real-time overview of each device’s health, performance and utilization is essential to keep things running smooth, and proactively detect problems before they arise.

This need for collective system information is where the Simple Network Management Protocol (SNMP) comes in to play, becoming a critical tool in the sysadmin’s arsenal.

First released in the late 1980s, SNMP has evolved to become the foundation for nearly every monitoring solution on the market. It is the underlying architecture, accepted as an industry standard, which facilitates communication between each individual piece of the network regardless of make, model or type.

What is the SNMP Protocol?

As a set of rules that establish a standardized means of communication, SNMP works across nearly every piece of hardware and software on the market. A feat that would otherwise be nearly impossible to achieve, at least without wide spread support from all major device manufacturers. It’s a feature that is often disabled by default, but will introduce monitoring functionality to everything from routers and switches to servers and printers when activated.

To illustrate this point, let’s say a Chinese speaking store clerk was attempting to converse with Spanish and French customers. The language barrier would certainly complicate matters to say the least.

A universal means of communication however would help to translate their questions and answers to an understandable medium they all understand. In society, this could be anything from pointing at objects, drawing a picture or even sign language.

When it comes to technology however, SNMP is the medium that we can use to accomplish this task. It establishes a clear set of guidelines to help relay information effectively, despite otherwise vast differences between the various devices and data collection systems.

Contrary to what the name may suggest, implementing SNMP can become somewhat convoluted based on several unique design choices. Terms such as MIB, OID and Traps aren’t exactly straight forward, and can raise the learning curve for new users by a considerable margin.

We will first look at the basics of how it all works from an core perspective, and then dive in to the individual parts of this system to breakdown their purpose.

How Does SNMP Work?

The heart of SNMP is comprised of just two components, a Management Station and Agent. These communicate with each other using either UDP or TCP packets on ports 161 (for queries) and 162 (for trap alerts).

Management Station

The Management Station is a simple, centralized piece of software that operates as the back-end. Often running on a dedicated workstation, it polls network connected devices with SNMP enabled, requesting system information to collect and store. This data can then be displayed as charts, graphs and other visual aides that represent a network’s performance.

To ensure both the Management Station and device can communicate the same SNMP language, a Management Information Base (MIB) is used. This is essentially a book of what questions can be asked of each device, allowing them to store the necessary answers readily available.

What is the System’s Current Uptime?
What is the System’s CPU load?
How much data is being transferred on the Network Interface Card?

Since the Management Station wouldn’t otherwise be able to natively understand every device it polls, the MIB is loaded from the manufacturer as a translator of sorts. We will look at this aspect of SNMP more in the next section, but it’s an integral part of what makes the Management Station such a powerful component.

Agents

The Agent represents an individual node on the network, often built directly in to the hardware or software that will need to be monitored. Handling most of the work, it collects local system information than can be queried by the Management Station in the form of of a GET request. Furthermore, it translates that data in to answers that can be understood before sending back the response.

The System is Overheating!
The CPU has exceeded 90% Usage!
Disk 1 has 4% Disk Space Left!

While the Agent mostly responds to incoming commands, it also has the capabilities of sending out alerts known as Trap messages. Rather than waiting for the Management Station to ask for an update, it can provide immediate notice when a problematic event occurs. We will touch on these again in more depth below, but they are an essential form of communication sent from a remote Agent.

Management Information Base (MIB)

Although it remains the most complex aspect of SNMP, the Management Information Base (MIB) acts as nothing more than a translation tool between Management Station and Agent. Supplied by the device’s manufacturer, it tells the collector how to interpret the incoming messages in to usable data.

Within the MIB database is a hierarchical structure, also known as a Tree or Table, compromised of objects (OIDS) that represent all important aspects of the device. An object could be defined as the Memory Status, Network Status, etc. Each object represents one part of the hardware (or software) that can be observed and reported on as per the manufacturer’s specifications.

Most monitoring solutions will handle the grunt work for you, where it is impossible to track potentially hundreds or thousands of MIBs and OIDs. In cases where a System Administrator wishes to perform a custom poll on a specific OID, it is necessary to use an MIB Browser to locate it.

Object Identifiers (OID)

Much like a name, Object Identifiers are a unique string of decimal separated numbers assigned to each component of an individual device. In contrast to an IP or MAC address however, the digits used in OIDS can contain extensive information about the equipment such as the manufacturer, organization and device type.

In fact Wireshark, a network protocol analyzer, offers an OUI lookup tool via their website that can identify this data based on their own Manufacturer database. Each vendor has their own specification, and this can take an input list and return the relevant information.

Wireshark OUI Lookup Tool

They also have the distinct benefit of improving overall SNMP structure and performance in several ways. For one, OIDS are an efficient way to manage a database of agents regardless of network size. Since the Management Information Base (MIB) is a hierarchical tree, we start from the root and trace a path to the desired node. Each parent’s ID is added to the OID string, leaving a breadcrumb trail that eventually leads to the desired device.

In addition to ID tags and location data, the usage of OIDS can also help decrease network congestion, eliminating the need for explicit polling requests. The Management Station can just pull as needed from a specific device without having to ask for it first. The data is already up to date and readily available on demand.

SNMP Traps

As mentioned before, Traps are messages sent from a remote SNMP agent to the Management Station. They act as alerts, providing immediate notification to the collector that a certain event is taking place, such as overheating or resource utilization surpassing a threshold.

Since polling uses a round robin approach, iterating through a list of agents and requesting updates one by one, new information can be significantly delayed reaching the back-end. If we were to rely on this exclusively, waiting for the next poll to take place before reporting urgent matters could be detrimental to a system’s health. Instead, agents are configured with ability to initiate contact as well when certain events occur, ensuring that critical matters are available as quickly as possible.

There is a downside to trap messages though, which is that they do not always get confirmation to ensure the alert was received. This is most notable on legacy SNMP devices, as modern hardware now supports an additional type called an Inform. In these cases, once a Trap has been received, the Management Station sends back an Inform message as acknowledgement. If the verification doesn’t arrive, the original Trap message is resent.

Furthermore, older devices lacking SNMP may not have support for sending Traps at all. In such cases, there is a workaround called Remote Telemetry Units (RTU) that act as an intermediate, capable of generating psuedo alerts that the collector can still understand.

SNMP Protocol Versions

The SNMP Protocol has managed to stay relevant for over 30 years, thanks in part to several revisions that helped it adapt to changes. As with many protocols, the significant lack of security was the most pressing concern for modern networks and was the primary focal point in each update.

Version 1: As the initial specification released in 1988, SNMPv1 still remains widely used even today. Despite the continued support, it has severe security flaws that make it vulnerable to malicious parties. Most notably is the fact authentication data is transmitted in plain text across the network, making it easily stolen from malicious 3rd parties.

Version 2: In effort to address this issue, progress on SNMPv2 was launched in 1993 with a Party Based security scheme. Despite vast improvements over the original release, it was considered too complex and resulted in several community based forks. The most popular of which became known as SNMPv2c, replacing the new security model with the original Community Based Authentication (that inherently flawed model from V1), while preserving the rest of the added features.

Ultimately considered the de facto standard for V2, it also remains operable even now by most management systems. With the advent of V3 however, it too was made obsolete and ongoing is support is regarded as backwards compatibility for older devices.

Version 3: In 1998, the current standard we use today was made available. Seeking to further enhance security practices, a user based system was adopted instead, providing the choice between 3 different options in authentication and encryption.

NoAuthNoPrivNo: No authentication is required from clients and no message encryption is provided.
AuthNoPriv: Authentication is required from clients but no message encryption is provided.
AuthPriv: Authentication is required from clients and messages are encrypted.

From a security standpoint, V3 is the optimal release and should always be used when available. Unfortunately organization’s aren’t always quick to make change, especially when doing so means spending money. As a result, nearly every monitoring solution maintains some form of backwards compatibility with V1 and V2 as well to ensure critical devices aren’t excluded.

Conclusion

When reading up on SNMP for the first time, it can quickly start to seem rather convoluted. There is a very clear picture as to how the Management Station and Agents work, but the introduction of MIBs, OIDs and message types can complicate an otherwise simple protocol.

There is never a shortage of alternative solutions in the works, many of which offer vast improvements over SNMP. Unfortunately these lack industry wide acceptance, which is the very reason that SNMP is so reliable. To quote Paul Venezia’s article from InfoWorld… “No one likes it, yet no one cares to replace it”.

On the upside, companies like SolarWinds and Paessler offer robust monitoring solutions that take care of the hard work for us. As a System Administrator, it’s always a good idea to have a working knowledge of SMTP, but rarely will you find the need to configure a system from scratch. More often than not, you will just enable this feature on each device and let the software handle the rest.