13.9 SNMP

Overview

Simple Network Management Protocol, or SNMP, is a standard protocol used to monitor and manage devices on a network. It lets a management system ask devices for information, receive alerts from them, and occasionally change settings on those devices. SNMP is especially common in enterprise networks, where there are many switches, routers, firewalls, wireless controllers, servers, and printers that all need to be watched and maintained.

SNMP operates at the application layer and uses lower layer services that you will see in other chapters. Here we stay focused on what is specific to SNMP itself, how it organizes information, and what kinds of messages it exchanges.

SNMP Components

SNMP involves three main roles that work together to provide monitoring and control.

The first role is the network management system, often called the NMS. This is usually a central server or software platform that displays dashboards, graphs, and alerts. The NMS sends SNMP requests, collects responses, and stores data, for example bandwidth use per port over time.

The second role is the managed device. This is any network element that supports SNMP, such as a router, switch, wireless access point, firewall, server, UPS, or even a networked printer. The managed device runs an SNMP agent that understands SNMP messages and has access to device information.

The third role is the SNMP agent itself. This is software running on the managed device. The agent reads and sometimes writes configuration or status values, for example interface status, CPU load, memory usage, or temperature. It responds to queries from the NMS and can also send unsolicited alerts when something happens.

In practice a single NMS might manage hundreds or thousands of agents. The NMS typically initiates most of the communication, but agents can initiate some messages as well when an event must be reported immediately.

Management Information Base (MIB)

SNMP uses a structured way to describe all the pieces of information that can be monitored or changed on a device. This structure is called the Management Information Base, or MIB. Despite the name, the MIB is not a database server. It is more like a catalog or dictionary that describes what variables exist, what they mean, and how they are organized.

Each SNMP-capable device supports one or more MIBs. There are standard MIBs defined for common things such as interfaces and system information, and there are vendor specific MIBs that describe special features of a particular product line.

Information in a MIB is organized in a tree. At the root of the tree there are broad branches such as standard organizations and private organizations. Under the private branch, each vendor gets its own subtree. Under each subtree you find groups of related objects, and under those you find individual variables.

Each variable is described by several properties, including a name, a type, whether it is read only or read write, and sometimes allowed ranges. The MIB file itself is usually a text file written in a special notation that management tools can read. Human administrators often talk about variables using their textual names, such as sysName or ifInOctets.

Object Identifiers (OIDs)

Under the surface, every SNMP variable in a MIB is identified by a unique number called an Object Identifier, or OID. An OID is written as a series of numbers separated by dots, for example:

1.3.6.1.2.1.1.5.0

Each number in the sequence represents a step down the tree hierarchy. Starting from the root, you walk down the branches by following the numbers until you reach a specific leaf, which is a particular variable in a particular context.

The same variable will have both a textual name and an OID. For example, the system name of a device might be called sysName in the MIB and have an OID like 1.3.6.1.2.1.1.5.0. SNMP messages use OIDs to specify exactly which piece of data they are talking about.

Some OIDs represent single values, while others represent tables. Interface counters are a common example. An interface table might have a base OID and then separate index numbers for each interface. The NMS can walk this table to discover all interfaces and their statistics.

Although you rarely need to memorize full OIDs, it is important to understand that OIDs create a globally unique naming scheme. This prevents collisions between vendors and between different parts of the same device.

SNMP Versions

SNMP has evolved over time through several versions. Each version changed the way security and features are handled. The three common versions are SNMPv1, SNMPv2c, and SNMPv3.

The earliest widely used version was SNMPv1. It provided basic monitoring and management abilities but had very weak security. Access control relied on a simple string called a community, which acted as a shared password. The community string was sent in plain text, so anyone who could see the traffic could read it.

The next version, SNMPv2, introduced improvements in performance and added new operations and data types. There were different security flavors of v2, but in real networks SNMPv2c became the common one. The letter c stands for community. SNMPv2c kept the same simple community based security model as v1, but it improved efficiency and added better bulk operations.

SNMPv3 is the modern version and addresses the major security weaknesses of earlier versions. It introduces a proper user based security model, with authentication and encryption options. With SNMPv3, you can verify who is sending messages and also protect the content from being read or changed in transit.

Because these versions differ mainly in security and some message features, many devices support multiple versions at the same time. Administrators can then choose which version to enable. In practice SNMPv3 is preferred for sensitive environments, while v2c is still common in simpler or legacy setups.

SNMP Operations

SNMP exchanges are built around a small set of operations. Each operation is a standard type of message that the NMS and agents understand. Together they allow both querying and modification of device information, as well as event reporting.

The most basic operation is Get. In a Get request, the NMS asks an agent for the value of one or more specific OIDs. The agent responds with a Get Response that includes the current values. This is how the NMS reads device status, for example the number of bytes in on an interface, or the current CPU load.

A related operation is GetNext. Instead of asking for a single known OID, the NMS asks the agent for the next OID in the tree after a given one. By repeatedly issuing GetNext, the NMS can walk through a table or discover all OIDs under a branch without knowing them ahead of time. This process is often called a MIB walk.

SNMPv2c added an operation called GetBulk. GetBulk allows the NMS to retrieve large sections of data in fewer messages compared to many single GetNext calls. This is more efficient for walking big tables, such as all interfaces and their counters on a large switch.

There is also a Set operation. With Set, the NMS requests that the agent modify the value of an OID. If the agent allows that variable to be written, it will change the setting and confirm in a response. This enables remote configuration changes, for example turning a port on or off, or changing a device name. Many organizations restrict or disable Set for security and stability reasons, and use SNMP mostly for read only monitoring.

Two additional operations are used by agents to report events. A Trap is an unsolicited message sent by an agent to the NMS when something noteworthy happens, such as an interface going down or a temperature threshold being exceeded. Traps are one way. The agent sends them and does not expect a confirmation.

An Inform is similar to a Trap but is designed to be reliable. When an agent sends an Inform, it expects an acknowledgment from the NMS. If it does not receive one, it can retry. This reduces the risk of losing critical event notifications.

Together, Get, GetNext, GetBulk, Set, Trap, and Inform provide a flexible set of tools for reading, changing, and reacting to the state of devices.

SNMPv1 and v2c Security with Communities

SNMPv1 and SNMPv2c both use a simple security model built around community strings. A community string is a piece of text that acts like a shared password between the NMS and an agent. The community identifies a group of access rights for SNMP operations.

Typically there are at least two communities on a device. One community is used for read only access. With this community, the NMS can issue Get, GetNext, and GetBulk requests to read values, but it cannot change anything with Set. Another community may be configured for read write access. With this, the NMS can also send Set operations to change configuration values.

In practice, administrators often choose random or complex strings instead of words like public or private. However, the key limitation is that these strings are sent in clear text, without encryption. Anyone who can see the network traffic and capture packets can read the community strings and then impersonate the NMS.

Because of this, SNMPv1 and v2c are considered weak from a security perspective, especially over untrusted or shared networks. They are typically limited to internal and controlled environments, and many organizations restrict them to read only, combined with other protective measures outside SNMP itself.

SNMPv3 Security Concepts

SNMPv3 improves on earlier versions by introducing a user based security model. Instead of just community strings, SNMPv3 defines users, along with authentication and privacy settings. This allows more precise and secure control over who can access what, and how messages are protected.

SNMPv3 security is often summarized using three levels, which combine authentication and privacy. Authentication means verifying that the message comes from a known user and has not been tampered with. Privacy means encrypting the content so that others cannot read it.

The three security levels are usually presented in increasing order of protection.

The first level is noAuthNoPriv. At this level there is no authentication and no privacy. Messages are not verified or encrypted. Although it uses the v3 framework, the security properties are similar to community based models in that they provide little protection.

The second level is authNoPriv. At this level the user is authenticated with a password or key, and the integrity of the message is protected. The receiver can detect if the message has been modified. However, the content is still in plain text and can be read by anyone who can capture the traffic.

The third level is authPriv. This level includes both authentication and privacy. The user is authenticated, the integrity of the message is checked, and the contents are encrypted. This is the strongest of the common SNMPv3 levels and is typically recommended for sensitive monitoring information.

SNMPv3 also separates the concepts of security and access control. It defines how to verify and encrypt messages, and it also defines how to control which users can access which parts of the MIB, and with which permissions. An administrator can configure roles and views, for example allowing a user to read interface statistics but not change configuration values, or preventing access to certain MIB branches entirely.

Because of these features, SNMPv3 is the version that aligns best with modern security requirements. It does add complexity to configuration compared to simple community strings, but it significantly improves confidentiality and integrity.

Typical Uses and Monitoring Scenarios

SNMP is most visible in how it is used by network administrators and monitoring tools to keep an eye on infrastructure. One common use is performance monitoring. The NMS can periodically query interface counters to measure bandwidth usage, error rates, and discards. By storing these values over time, it can draw graphs of traffic patterns, identify peak hours, and detect growing problems such as a port that is beginning to show many errors.

Another common use is availability monitoring. The NMS can use SNMP to check whether devices are up and whether key interfaces are operational. A failed response or unexpected value can trigger alerts. Combined with regular polling, this allows fast detection of outages and degraded links.

SNMP is also used to monitor health metrics such as CPU load, memory usage, disk space, fan status, and temperature. The NMS can raise alarms if any of these metrics cross defined thresholds, so issues can be addressed before they cause failures.

In addition to polling, Trap and Inform messages let devices push alerts. For example, if a power supply fails, a fan stops, or a link goes down, the agent can send a Trap immediately instead of waiting for the next polling cycle. This reduces detection time and can give more precise event information.

Some environments use SNMP Set operations to automate configuration changes, but many prefer to limit SNMP to read only for safety reasons. Even without Set, SNMP remains a key source of visibility and data for capacity planning, troubleshooting, and reporting.

Key Points to Remember

SNMP provides a common language for network management tools and devices to communicate about status, performance, and configuration. The MIB and OID structure define what can be monitored and how it is identified. Different SNMP versions offer different levels of security, with SNMPv3 adding proper authentication and encryption. Operations like Get, GetNext, GetBulk, Set, Trap, and Inform define how information is exchanged and how events are reported.