SNMP: Simple Network Management Protocol

What is SNMP?

SNMP (Simple Network Management Protocol) is an application-layer protocol used to monitor and manage network devices such as routers, switches, servers, printers, and firewalls. It provides a standardized way for network administrators to collect performance metrics, detect faults, and even modify device configurations remotely. SNMP is one of the most widely deployed protocols in enterprise networking, found in virtually every managed network device on the market.

SNMP was first defined in 1988 in RFC 1157 as a simple, practical solution for network management. At the time, the internet was growing rapidly and administrators needed a lightweight way to keep track of their expanding infrastructure. The protocol was designed to be easy to implement on devices with limited resources, which is why it uses UDP rather than TCP for transport. This simplicity helped SNMP achieve near-universal adoption across networking vendors.

The protocol operates on a manager-agent model. A central management station (the manager) sends requests to software agents running on managed devices. Agents respond with the requested data or carry out configuration changes. Agents can also send unsolicited notifications called traps when important events occur, such as an interface going down or CPU usage exceeding a threshold. SNMP uses UDP port 161 for queries from the manager to the agent and UDP port 162 for traps sent from the agent to the manager.

Three major versions of SNMP have been released. SNMPv1 was the original version with basic functionality and minimal security. SNMPv2c added performance improvements like the GETBULK operation and INFORM notifications but kept the same weak authentication model. SNMPv3, defined in RFC 3411 through RFC 3418, is the current standard. It introduced proper authentication, encryption, and access control, making it suitable for production environments where security matters.

SNMP Architecture: Manager and Agents

SNMP follows a client-server architecture with two primary components: the manager and the agents. Understanding how these pieces fit together is essential for grasping how network monitoring works in practice.

The NMS (Network Management Station) is the central hub where monitoring software runs. This is typically a dedicated server running tools like Nagios, Zabbix, PRTG, or SolarWinds. The NMS periodically polls agents on managed devices to collect data such as CPU usage, memory utilization, interface traffic counters, and error rates. It stores this data for trending, generates alerts when thresholds are exceeded, and provides dashboards for administrators to visualize network health.

Agents are small software processes that run on each managed device. Every modern router, switch, server operating system, and many printers ship with a built-in SNMP agent. The agent maintains a local database of management information and responds to queries from the NMS. When the manager sends a GET request for a specific piece of data (like the current CPU load), the agent retrieves the value from its local database and sends it back.

The MIB (Management Information Base) is the structured database that defines what information an agent can provide. Think of the MIB as a schema or data dictionary. It describes every variable the agent tracks, organized in a hierarchical tree structure. Each variable has a unique identifier (called an OID), a data type, and a description of what it represents. Standard MIBs define common variables that all devices support (like system uptime and interface statistics), while vendor-specific MIBs add proprietary variables unique to a particular manufacturer or device.

In addition to responding to polls, agents can proactively send notifications called traps to the manager. Traps are triggered by significant events: a link going down, a fan failure, an authentication failure, or a temperature warning. This event-driven model complements the polling model, ensuring the manager learns about critical events immediately rather than waiting for the next poll cycle.

SNMP Operations

SNMP defines a small set of operations that the manager and agents use to exchange information. Each operation serves a specific purpose, and together they provide complete read, write, and notification capabilities for network management.

• GET: retrieves the value of a single specific variable from an agent. The manager specifies the exact OID it wants, and the agent returns the current value. For example, a GET request for sysUpTime.0 returns how long the device has been running since its last reboot.
• GETNEXT: retrieves the value of the next variable in the MIB tree after the specified OID. This operation is used to walk through the MIB sequentially, discovering what variables are available. By issuing repeated GETNEXT requests, a manager can traverse an entire MIB subtree without knowing the exact OIDs in advance. This is the basis of the snmpwalk command-line tool.
• GETBULK: introduced in SNMPv2c, this operation retrieves large blocks of data in a single request. It is far more efficient than issuing many individual GETNEXT requests, especially when reading interface tables on devices with hundreds of ports. GETBULK accepts a max-repetitions parameter that tells the agent how many successive variables to return.
• SET: writes a value to a variable on the agent. This allows the manager to modify device configurations remotely. For example, a SET operation can change the hostname of a device, disable an interface, or update a routing table entry. SET operations require appropriate write permissions, which are controlled by community strings (v1/v2c) or user-based access control (v3).
• TRAP: an unsolicited notification sent from the agent to the manager. Unlike the other operations, traps are not initiated by the manager. The agent sends a trap when a predefined event occurs. Standard traps include coldStart (device rebooted), linkDown (interface failed), linkUp (interface restored), and authenticationFailure (invalid community string received). Traps are sent to UDP port 162 on the manager.
• INFORM: introduced in SNMPv2c, this is an acknowledged version of the trap. When an agent sends an INFORM, it expects the manager to reply with an acknowledgment. If no acknowledgment arrives, the agent retransmits the INFORM. This solves the reliability problem with traps, which are sent over UDP with no delivery guarantee.

MIB and OID Structure

The MIB (Management Information Base) organizes all manageable data into a hierarchical tree. Every piece of information that an SNMP agent can report or accept is represented as a node in this tree. Each node is identified by an OID (Object Identifier), which is a sequence of numbers separated by dots, similar to a file system path.

The OID tree starts at the root and branches out through a series of well-known nodes. The path to most network management objects follows this pattern: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1). The mib-2 subtree contains the standard objects defined in RFC 1213 and its successors. Under mib-2, you will find groups like system(1) for general device information, interfaces(2) for network interface data, and ip(4) for IP-level statistics.

OIDs can be written in numeric form (like 1.3.6.1.2.1.1.1.0) or in named form (like iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0). The numeric form is what SNMP actually uses on the wire. The named form is for human readability and is resolved through MIB files loaded into the management station. The trailing .0 on scalar objects indicates this is an instance of a single-value object rather than a table entry.

Vendors extend the standard MIB tree by placing proprietary objects under the enterprises(1) subtree at 1.3.6.1.4.1. Each vendor has a registered enterprise number. For example, Cisco is 9, so Cisco-specific OIDs begin with 1.3.6.1.4.1.9. This allows every manufacturer to define custom objects for features unique to their devices without conflicting with other vendors.

The following table lists some of the most commonly queried OIDs from the standard MIB-2 tree.

SNMP Versions Compared

Three versions of SNMP are in active use today. Each version built on the previous one, primarily by improving security and adding new operations. The following table summarizes the key differences.

SNMPv1 should be avoided entirely in modern deployments. Its community string authentication sends credentials in plaintext over the network, and it lacks any encryption. SNMPv2c improved performance with GETBULK and added INFORM notifications, but it kept the same plaintext community string model, offering no real security improvement.

SNMPv3 is the recommended version for all production environments. It introduced the User-based Security Model (USM), which provides authentication through HMAC-MD5 or HMAC-SHA, and privacy through DES or AES encryption. The View-based Access Control Model (VACM) allows fine-grained control over which users can access which parts of the MIB tree, and whether they have read-only or read-write permissions.

Community Strings

In SNMPv1 and SNMPv2c, authentication is handled through community strings. A community string is essentially a password included in every SNMP packet. If the community string in the request matches the one configured on the agent, the agent processes the request. If it does not match, the agent rejects the request and may send an authenticationFailure trap.

Most devices ship with two default community strings: public for read-only access and private for read-write access. These defaults are universally known, and leaving them unchanged is one of the most common network security mistakes. Attackers who discover an SNMP agent with default community strings can read sensitive device information or, worse, reconfigure the device entirely using SET operations.

Because community strings are transmitted in plaintext, anyone capturing network traffic can read them. This means that even custom community strings offer only minimal protection on untrusted networks. Best practices for community strings include the following.

• Always change the default community strings on every device before deploying it to a production network.
• Use long, random community strings that are difficult to guess.
• Restrict SNMP access by source IP address using access control lists (ACLs) on the device, so only the management station can query the agent.
• Only use SNMPv1/v2c on isolated management networks where traffic cannot be intercepted.
• Whenever possible, migrate to SNMPv3 with USM authentication and AES encryption to eliminate plaintext credentials entirely.

Common Use Cases

SNMP is used across virtually every managed network. Its simplicity and universal support make it the go-to protocol for a wide range of monitoring and management tasks.

• Network device monitoring: SNMP collects real-time metrics from routers, switches, and firewalls, including CPU utilization, memory usage, temperature, and fan speeds. These metrics help administrators identify overloaded or failing devices before they cause outages.
• Bandwidth and traffic monitoring: interface counters like ifInOctets and ifOutOctets track the number of bytes flowing through each port. By polling these counters at regular intervals, monitoring tools calculate bandwidth utilization, detect congestion, and generate traffic graphs.
• Uptime tracking: the sysUpTime OID reports how long a device has been running since its last restart. Monitoring systems use this to detect unexpected reboots and track device stability over time.
• Interface status monitoring: the ifOperStatus OID indicates whether each network interface is up, down, or in a testing state. Combined with traps, this provides immediate notification when a link fails.
• Configuration management: SET operations allow administrators to push configuration changes to devices remotely. While most organizations prefer dedicated configuration management tools, SNMP SET is still used for simple tasks like updating contact information or enabling/disabling interfaces.
• Capacity planning: historical SNMP data reveals trends in resource utilization. By analyzing bandwidth, CPU, and memory trends over weeks or months, administrators can predict when upgrades will be needed and plan accordingly.
• Automated alerting via traps: agents send trap notifications when predefined events occur, such as link failures, authentication errors, or environmental warnings. The NMS receives these traps and triggers alerts through email, SMS, or integration with incident management platforms.
• Performance graphing: tools like Cacti, MRTG, Zabbix, and PRTG use SNMP to collect data and generate visual graphs of network performance over time. These graphs are invaluable for troubleshooting, reporting, and capacity planning.

Frequently Asked Questions About SNMP

What is the difference between SNMP GET and GETNEXT?

GET retrieves the value of a specific, known OID. You must provide the exact OID you want to read. GETNEXT returns the value of the next OID in the MIB tree after the one you specify. GETNEXT is useful for walking through a subtree when you do not know all the OIDs in advance. Tools like snmpwalk use repeated GETNEXT requests to traverse an entire branch of the MIB.

What is an SNMP trap?

A trap is an unsolicited message sent from an SNMP agent to the manager when a significant event occurs on the managed device. Examples include interface failures, device reboots, and authentication errors. Traps are sent to UDP port 162 on the manager without the manager requesting them. Because traps use UDP, delivery is not guaranteed. SNMPv2c and v3 added the INFORM operation, which requires the manager to acknowledge receipt, providing reliable notification delivery.

Is SNMP secure?

SNMPv1 and SNMPv2c are not secure. They use community strings sent in plaintext, which means anyone capturing network traffic can read the credentials. SNMPv3 significantly improves security by offering authentication (verifying the identity of the sender) and encryption (protecting the contents of SNMP messages). For any network exposed to untrusted traffic, SNMPv3 with authentication and encryption is strongly recommended.

What is the default SNMP community string?

Most devices ship with public as the default read-only community string and private as the default read-write community string. These defaults are widely known and should always be changed before connecting a device to a production network. Leaving default community strings in place is a common security vulnerability that allows unauthorized monitoring or control of network devices.

What is the difference between SNMPv2c and SNMPv3?

SNMPv2c uses plaintext community strings for authentication and offers no encryption. SNMPv3 replaces community strings with a username and password model (USM), supports encryption via DES or AES, and provides fine-grained access control through VACM. Both versions support GETBULK and INFORM operations. The key distinction is security: v2c is suitable only for trusted, isolated networks, while v3 is safe for production use on any network.

What tools use SNMP?

Many popular network monitoring platforms rely on SNMP as their primary data collection method. These include Zabbix, Nagios, PRTG Network Monitor, SolarWinds Network Performance Monitor, Cacti, MRTG, LibreNMS, and Datadog. On the command line, the Net-SNMP suite provides tools like snmpget, snmpwalk, snmpset, and snmptrap for interacting with SNMP agents directly. Most programming languages also have SNMP libraries available for building custom monitoring solutions.

Related Protocols

• UDP: the transport protocol SNMP uses for all its communication, chosen for low overhead and simplicity
• TCP: sometimes used as an alternative transport for SNMP in environments requiring reliable delivery
• NTP: accurate timestamps are essential for correlating SNMP trap events across multiple devices
• SSH: often used alongside SNMP for secure command-line management of network devices