By Uniqcli Team
SNMP, the Simple Network Management Protocol, is the long-standing standard for reading state from network devices and receiving alerts when something changes. A monitoring system acts as the manager and asks questions; an agent built into the switch, router, firewall, uninterruptible power supply, rack power strip, printer or server management controller answers them. The questions and answers are addressed to numbered objects in a hierarchical catalog, which is what allows one monitoring platform to poll a thousand devices from a dozen manufacturers without knowing anything specific about any of them.
That universality is the reason SNMP is still everywhere despite being older than most of the equipment it monitors. Newer mechanisms handle particular jobs better — flow records describe what traffic is on a link, syslog describes events, streaming telemetry pushes counters at a far higher rate — but none of them is implemented on every device in a building. If you want one query that works against the core switch, the closet switch, the environmental sensor and the battery backup under the desk, SNMP is still the only answer.
It is also a protocol with a genuinely bad security history, almost all of it caused by deployments running the two versions that have no security at all. The third version has authentication and encryption and has been an internet standard since 2002. The gap between those two facts is where the practical advice on this page lives.
How does SNMP work?
The model has two roles. The manager is the monitoring platform; the agent is software embedded in the device's firmware or operating system. The manager sends requests to the agent on UDP port 161 and the agent replies. Separately, the agent can send unsolicited notifications to the manager on UDP port 162 when something happens locally. UDP is deliberate — the protocol was designed to be light enough to run on equipment with very little memory, and to keep working on a network that is already in trouble, which is precisely when monitoring matters most.
The operations are few. Get retrieves a named object. GetNext retrieves the object following a given one in the tree, which is how a manager walks a table without knowing its size in advance. GetBulk, added in version 2, returns many objects in one exchange and is what makes polling a large interface table practical. Set writes a value, where the device permits it. Trap sends a notification with no acknowledgement, and Inform, also from version 2, sends one that the manager must acknowledge. Response carries the agent's answer back.
In practice a monitoring system runs on a cycle — commonly every one to five minutes — issuing bulk requests for the objects it cares about on each device, storing the results as time series, and evaluating thresholds against them. Traps arrive between polls to report things that cannot wait for the next cycle. The polling interval is the main scaling constraint: every device multiplied by every object multiplied by the frequency is real load on both the network and the agent, and agents on inexpensive hardware are often the first thing to fall over.
MIBs and OIDs: how a device describes itself
Every value SNMP can read has an object identifier — an OID — which is a sequence of numbers describing a path down a globally administered tree. A Management Information Base, or MIB, is the human-readable document that defines a branch of that tree: which objects exist, what each one means, its data type, and whether it can be written. The manager needs the MIB loaded to translate a numeric OID into something a person can read; the agent does not need it at all, because the agent only ever deals in numbers.
Two parts of the tree matter. The standard branch holds objects every device is expected to implement, most importantly the interfaces table, which reports the operational and administrative state of each port along with counters for octets, packets, errors and discards in each direction. RFC 2863 defines the modern interfaces group, including the extension table with 64-bit high-capacity counters — which is the detail worth knowing, because the original 32-bit octet counters wrap in a matter of seconds on a saturated ten-gigabit link and produce nonsense graphs if a monitoring system polls the wrong ones.
The second part is the enterprise branch, where each manufacturer is assigned a number and defines its own objects underneath it. This is where anything genuinely product-specific lives: power-supply and fan status, chassis temperature, battery runtime remaining, per-outlet current on a rack power strip, licence state, wireless client counts. Those objects require the vendor's MIB file loaded into the monitoring platform, and they are the reason two devices with identical specifications can be very different to monitor. It is a fair question to ask before buying: which MIBs does this model publish, and does the monitoring system already have a template for it?
The three versions, and why only one is secure
Version 1, defined in RFC 1157, and version 2c, which added GetBulk and Inform, both authenticate with a community string — a shared secret sent in the clear with every request. Anyone who can see the traffic can read it, and anyone who can guess it can use it. The defaults shipped by an alarming amount of equipment are the words public for read access and private for write access, and internet-wide scans have found devices answering to them for as long as anyone has been scanning. Version 2c is still the most widely deployed variant, which is a statement about inertia rather than about its suitability.
Version 3 is the answer, and it is not a minor revision. Published as STD 62 across RFC 3411 to RFC 3418, it replaces the community string with a User-based Security Model that supports three levels: no authentication and no privacy, authentication without encryption, and authentication with encryption. It adds the View-based Access Control Model, which restricts each user to a defined subset of the object tree, so a monitoring account can be granted interface counters and nothing else. Every recommendation that follows assumes version 3 with both authentication and privacy enabled.
The algorithms deserve a check rather than an assumption, particularly on federal systems. The original security model specified HMAC-MD5 and HMAC-SHA-1 for authentication and DES for privacy; RFC 3826 added AES, and RFC 7860 later added the SHA-2 family for authentication. MD5 and DES should not be selected on anything, and where the equipment offers it, SHA-2 authentication with AES privacy is the configuration to standardize. Be aware that AES-192 and AES-256 in the SNMP security model were never standardized and exist as vendor extensions, so two devices offering them may not interoperate — confirm what a model actually implements before writing it into a build standard.
Polling, traps and informs: two ways to learn something is wrong
Polling is the manager asking on a schedule. It produces the continuous time series that make capacity planning, trend analysis and after-the-fact investigation possible, and it detects a device that has stopped answering — which a device that has died cannot tell you itself. Its limitation is resolution: an event that starts and finishes between two polls leaves no trace, so a five-minute interval will show an average and hide the burst inside it.
Traps are the device volunteering information: a port went down, a power supply failed, a battery switched to inverter, a fan stopped, an authentication failed. They arrive within seconds rather than at the next cycle. Because a trap is a single unacknowledged UDP datagram, it can also simply be lost, and nobody finds out — the device believes it reported the failure and the manager never heard it. Informs, from version 2 onward, are acknowledged and retransmitted, which fixes that at the cost of state on both ends. Where a device supports informs for the notifications that matter, use them.
The design rule that follows is to use both and rely on neither alone. Poll for state, capacity and trend, and treat the poll as the authoritative record. Send traps or informs for events that need a response inside the polling interval. Then make sure the important conditions are also detectable by polling, so that a lost trap delays the alert rather than losing it entirely. And send device event logs to a syslog collector alongside the SNMP data, because syslog carries the detail and context that a trap's small set of fields cannot.
What SNMP is good at, and what has taken over the rest
SNMP is strong at exactly what it was designed for: reading a defined set of numbers and states from a very wide range of hardware, cheaply and reliably. Interface utilization and error counters, device reachability, CPU and memory on the device itself, environmental readings, power draw per outlet, uninterruptible power supply battery state and estimated runtime, printer consumables, disk and controller status on a server management processor. For an organization standardizing a monitoring baseline across mixed equipment, it remains the common denominator, and the read path is not going anywhere.
Its weaknesses are equally clear. It says nothing about what traffic is on a link, only how much — that is the job of flow export such as NetFlow, sFlow or IPFIX, which samples or records conversations and answers which applications and hosts filled the pipe. Polling does not scale to sub-minute resolution across a large estate, which is what pushed the industry toward streaming telemetry, where the device pushes structured data continuously over a subscription rather than answering questions one at a time. And the write path barely survived: configuration is now done through NETCONF or RESTCONF with structured data models, or through the device's API, and SNMP Set is disabled in most well-run networks.
The honest summary is that SNMP lost the configuration job and kept the inventory-and-health job. Newer telemetry is better where it is available, and it is not available on the environmental sensor, the older closet switch, the rack power strip or the battery backup. Most organizations end up running both: streaming telemetry or vendor APIs on the modern core, SNMP everywhere else, with the results landing in the same dashboards.
What to enable, and what to lock down
Start by turning off what you are not using. Disable versions 1 and 2c entirely if the monitoring platform and every device support version 3; where a legacy device forces version 2c, give it a long random community string, make it read-only, and confine it to a management segment. Never leave the defaults in place. Disable the write path unless a specific documented tool requires it, and if it is required, restrict which objects that user can write rather than granting the whole tree.
Then restrict where the agent will answer. Bind it to the management address, permit only the monitoring servers by access list, and put management traffic on its own VLAN or, better, a dedicated out-of-band network — the arrangement NSA and CISA guidance recommends for exactly this class of traffic, with physical separation as the strongest form and dedicated management hosts as the point of access. Use the view-based access control model to give the monitoring account the objects it needs and nothing more, so that a compromised monitoring credential cannot walk the whole configuration tree. Log authentication failures on the agent and alert on them; a burst of failed SNMP authentications is a scan in progress.
Finally, treat monitoring capability as a purchasing requirement rather than a discovery. Confirm before ordering that the model supports version 3 with the authentication and privacy algorithms your standard requires, publishes the objects you intend to graph, and has a template in your monitoring platform. Inexpensive unmanaged switches have no agent at all and cannot be monitored by any means. Uninterruptible power supplies and rack power strips frequently need an optional network management card before they can report anything, and that card is a separate line item that is easy to omit from a quote and expensive to add after the rack is populated.
Key takeaways
- SNMP is a manager-and-agent protocol over UDP — requests to port 161, notifications to port 162 — and it is the one monitoring interface implemented by nearly every class of network and power equipment.
- Every readable value is an object identifier in a global tree; MIB files define what those numbers mean, with a standard branch for common objects and a per-manufacturer enterprise branch for product-specific ones.
- Poll the 64-bit high-capacity interface counters from the extension table defined in RFC 2863 — the original 32-bit counters wrap in seconds on a busy ten-gigabit link.
- Versions 1 and 2c authenticate with a cleartext community string and are not secure; version 3 (STD 62) adds per-user authentication, encryption and view-based access control, and is the only version to deploy.
- Prefer SHA-2 authentication with AES privacy, avoid MD5 and DES, and note that AES-192 and AES-256 were never standardized for SNMP and remain vendor extensions with uneven interoperability.
- Poll for state and trend, use traps or acknowledged informs for events, restrict the agent to a management network with an access list, disable the write path, and confirm before purchase that a device has an agent at all.
Shop it at Uniqcli
Frequently asked
- What port does SNMP use?
- Two, both UDP. The agent listens on port 161 for requests from the monitoring system and answers on the same session. Notifications travel the other way to port 162 on the manager, which is a separate listener — so a firewall rule that permits polling does not permit traps, and vice versa. Both are UDP, which is why traps can be silently lost and why acknowledged informs exist. Some implementations also offer SNMP over TLS or DTLS on other ports, but the two UDP ports are what you will find in practice.
- Is SNMP secure?
- Versions 1 and 2c are not, and should be treated as unauthenticated. They identify a caller by a community string sent in the clear with every packet, so anyone who can observe the traffic can reuse it, and the shipped defaults of public and private are still found in the wild. Version 3, standardized in 2002 as STD 62, is a different proposition: per-user authentication, optional encryption of the payload, and view-based access control that limits each user to a defined subset of objects. SNMP is secure if you deploy version 3 with authentication and privacy enabled, restrict the agent to a management network, and disable the older versions.
- What is the difference between an SNMP trap and an inform?
- Delivery guarantees. A trap is a single UDP datagram sent by the device and forgotten — if it is dropped in transit or the manager is not listening, nobody is told, and the device has no way to know. An inform, introduced in version 2, requires the manager to acknowledge receipt and is retransmitted until it is acknowledged or the retry budget runs out. Informs cost a little state on both ends and are the better choice for notifications that matter, such as a power-supply failure or a battery switching to inverter. Not every agent implements them, so check per model.
- What is a MIB, and do I need the vendor's file?
- A MIB is the definition document for a branch of the object tree: which objects exist, what they mean, their data types, and whether they are writable. The agent works entirely in numbers and needs nothing loaded. The monitoring system needs the MIB to turn a numeric object identifier into a named, correctly scaled and correctly labelled metric. Standard MIBs cover the common ground — interfaces, system information, basic health — and your platform will already have them. Anything product-specific, such as fan status, battery runtime or per-outlet current, lives in the manufacturer's enterprise branch and needs that manufacturer's MIB file imported.
- Has SNMP been replaced by streaming telemetry?
- Partly, and only where the newer option exists. Streaming telemetry pushes structured data continuously from the device instead of answering one question at a time, which gives far better resolution and scales to large estates without a polling storm. Flow export answers what traffic is on a link, which SNMP cannot. Configuration moved to structured interfaces such as NETCONF and RESTCONF, and SNMP write access is disabled in most well-run networks. What has not changed is coverage: the environmental sensor, the older access switch, the rack power strip and the battery backup all speak SNMP and nothing else, so most organizations run both and merge the results.
- Can I monitor an unmanaged switch with SNMP?
- No. An unmanaged switch has no management plane, no IP address and no agent, so there is nothing to query — it forwards frames and reports nothing about itself. The practical consequence is that any port count behind an unmanaged switch is invisible to monitoring, including link errors and utilization, which is a common blind spot in closets that grew informally. If a segment needs to be visible, it needs a managed or lightly managed switch. The same applies to power: a basic rack power strip reports nothing, while a metered or monitored model with a network card can report load per branch or per outlet.
Keep reading