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.
| Operation | Direction | Purpose |
|---|---|---|
| Get | Manager to agent | Read one or more specific OIDs |
| GetNext | Manager to agent | Read the next OID in the tree |
| GetBulk | Manager to agent | Read many consecutive OIDs efficiently, SNMPv2c and later |
| Set | Manager to agent | Change a writable value |
| Trap | Agent to manager | Unacknowledged event notification |
| Inform | Agent to manager | Acknowledged event notification |
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.
| Version | Authentication | Encryption | Notes |
|---|---|---|---|
| SNMPv1 | Community string in plain text | None | 32-bit counters only, legacy |
| SNMPv2c | Community string in plain text | None | Adds GetBulk and 64-bit counters |
| SNMPv3 | Per-user, HMAC with SHA-2 | AES, typically 128-bit | Recommended for all new deployments |
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.
| Method | What it shows | Granularity | Typical use |
|---|---|---|---|
| SNMP polling | Device and interface counters, health | Every 1 to 5 minutes | Capacity graphs, availability alerts |
| NetFlow or IPFIX | Who talks to whom, how much | Per flow | Traffic analysis, top talkers |
| Packet capture | Full packet contents | Per packet | Deep troubleshooting |
| Streaming telemetry | Device counters pushed by the device | Seconds or less | Large modern networks |
| Syslog | Event messages in text form | Per event | Audit and fault diagnosis |
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.
| Symptom | Likely cause | Remedy |
|---|---|---|
| Gaps in graphs | UDP requests lost or timed out | Raise timeouts, check ACLs and agent load |
| Impossible traffic spikes | 32-bit counter wrap or device reboot | Use 64-bit counters, detect resets |
| Interfaces renamed or swapped in graphs | Interface index changed after reboot | Enable index persistence |
| Traps never arrive | Wrong target address or blocked UDP 162 | Verify configuration and firewall rules |
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.