SNMP

On this page 7

SNMP (Simple Network Management Protocol) is the standard application-layer protocol for reading status and performance data from network devices and for receiving alerts from them. In networking and network monitoring, it lets a central monitoring system collect values such as interface traffic counters, error rates, CPU load, temperatures and link states from routers, switches, firewalls, printers, storage systems and servers.

SNMP follows a manager and agent model: a manager queries agents running on the devices, and agents can also send unsolicited notifications. Although newer streaming telemetry interfaces exist, SNMP remains the most universally supported monitoring interface on network equipment, which makes it a baseline skill for anyone operating a network.

How SNMP collects data

SNMP collects data by addressing every measurable value with an object identifier (OID), a dotted numeric path in a global tree. The structure of these objects is described in a Management Information Base (MIB), a text module that maps numeric OIDs to names, data types and meanings, such as ifHCInOctets for the 64-bit count of received bytes on an interface.

The manager normally polls agents over UDP port 161 at a fixed interval, while agents send traps and informs to UDP port 162 on the manager when something notable happens, such as a link going down. The table below lists the core operations.

OperationDirectionPurpose
GetManager to agentRead one or more specific OIDs
GetNextManager to agentRead the next OID in the tree
GetBulkManager to agentRead many consecutive OIDs efficiently, SNMPv2c and later
SetManager to agentChange a writable value
TrapAgent to managerUnacknowledged event notification
InformAgent to managerAcknowledged event notification
Core SNMP operations

Most traffic graphs are built from counters, not rates. The manager reads a counter twice and divides the difference by the elapsed time; a five-minute interval is traditional, while one-minute polling gives better visibility of short peaks at the cost of more load.

SNMP versions and their security

Three SNMP versions are in use, and they differ above all in how they authenticate requests and whether they encrypt data. The version choice is therefore primarily a security decision.

VersionAuthenticationEncryptionNotes
SNMPv1Community string in plain textNone32-bit counters only, legacy
SNMPv2cCommunity string in plain textNoneAdds GetBulk and 64-bit counters
SNMPv3Per-user, HMAC with SHA-2AES, typically 128-bitRecommended for all new deployments
Comparison of SNMP versions

Community strings are effectively passwords sent in clear text, and the defaults public and private are still found on poorly configured devices. SNMPv3 replaces them with the User-based Security Model, which supports three levels: noAuthNoPriv, authNoPriv and authPriv. Only authPriv provides both authentication and encryption, and it should be the standard level.

SNMP compared with other monitoring methods

SNMP answers the question how a device is doing, while neighboring tools in network monitoring answer different questions. Combining them gives a complete picture.

MethodWhat it showsGranularityTypical use
SNMP pollingDevice and interface counters, healthEvery 1 to 5 minutesCapacity graphs, availability alerts
NetFlow or IPFIXWho talks to whom, how muchPer flowTraffic analysis, top talkers
Packet captureFull packet contentsPer packetDeep troubleshooting
Streaming telemetryDevice counters pushed by the deviceSeconds or lessLarge modern networks
SyslogEvent messages in text formPer eventAudit and fault diagnosis
SNMP among network monitoring techniques

SNMP shows that an uplink is at 95 percent utilization, but it cannot show which application causes it; that requires flow data. Conversely, flow data alone does not reveal interface errors or a failing power supply, which SNMP reports directly.

Deploying SNMP well

A good SNMP deployment is read-only, restricted and versioned consistently across the network. Several practical choices decide whether the data is trustworthy and the devices remain secure.

  • Use SNMPv3 with authPriv wherever devices support it, and keep v2c only for legacy equipment on an isolated management network.
  • Disable write access unless a specific tool requires Set operations.
  • Restrict agents with access lists so that only monitoring servers can query them.
  • Poll 64-bit high-capacity counters on links of 1 Gbit/s and faster, because 32-bit counters can wrap in well under a minute at 10 Gbit/s.
  • Load vendor MIBs into the manager so that device-specific values such as optics power or fan status have readable names.

Polling intervals should match the purpose: one to five minutes for capacity and availability, while sub-minute visibility of microbursts is better served by telemetry. Very aggressive polling of large tables, such as routing tables, can overload the control plane of smaller devices.

Limitations and common pitfalls

The main limitation of SNMP is that averages hide short events. A five-minute average of 40 percent can conceal bursts that saturate the link for seconds and cause packet loss, latency spikes and jitter that users notice.

SymptomLikely causeRemedy
Gaps in graphsUDP requests lost or timed outRaise timeouts, check ACLs and agent load
Impossible traffic spikes32-bit counter wrap or device rebootUse 64-bit counters, detect resets
Interfaces renamed or swapped in graphsInterface index changed after rebootEnable index persistence
Traps never arriveWrong target address or blocked UDP 162Verify configuration and firewall rules
Typical SNMP problems and remedies

In plain words

SNMP is a way for a central monitoring computer to ask every network device how it is doing. Each router or switch keeps a list of numbered readings, such as how much data has passed through each port or how warm it is. The monitoring computer asks for these readings every few minutes and draws graphs from them.

Devices can also raise their hand on their own when something goes wrong, for example when a cable is unplugged. The modern version of SNMP locks these conversations with passwords and encryption, so outsiders cannot read the readings or pretend to be the monitoring system.

A real-world example

A regional school district monitors 60 switches and four internet routers with an open-source monitoring system. Every device is configured with SNMPv3 at the authPriv level, a read-only user and an access list that permits queries only from the two monitoring servers. The system polls 64-bit interface counters, CPU load and temperature every minute.

One morning, teachers report slow video lessons. The SNMP graphs show the main internet uplink at 98 percent of its 1 Gbit/s capacity since the start of lessons, while all switches look healthy. Flow data then identifies a misconfigured update server downloading operating system images during school hours. After the downloads are rescheduled to night hours, uplink utilization drops below 50 percent and the complaints stop.