What Is SNMP Monitoring? How It Works, OIDs and Versions

Routers, switches, firewalls, UPS units, printers and many servers ship with an SNMP agent, and for hardware that cannot run a monitoring script it is often the only source of health data.

How SNMP works

The agent is software on the managed device that answers requests and sends notifications. The manager is the monitoring system that sends the requests and collects the notifications. RFC 3411, which defines the current architecture, describes them as command responder and command generator applications; agent and manager are the traditional names.

MIBs and OIDs

An agent exposes its data as a tree of managed objects. Each object has an OID, a dotted string of numbers that gives its position in the tree. A MIB (Management Information Base) module is the document that defines a group of objects: their names, OIDs, data types and meaning. Objects from IETF-standard MIBs sit under 1.3.6.1.2.1, known as mib-2. Vendors define their own under 1.3.6.1.4.1 (enterprises), each below a number assigned to that vendor.

An OID in a request names an instance of an object. A scalar such as sysUpTime has one instance, written with a trailing .0, so the full OID is 1.3.6.1.2.1.1.3.0. A table column is followed by the row index: the inbound byte counter of interface 3 is ifInOctets.3, or 1.3.6.1.2.1.2.2.1.10.3. Index numbers differ between devices, and IF-MIB only requires an interface's index to stay the same until the agent re-initializes, so look indexes up instead of hardcoding them.

Requests: Get, GetNext and GetBulk

The manager sends requests to the agent over UDP, conventionally to port 161 (RFC 3417). RFC 3416 defines the operations a monitor uses:

• GetRequest reads the exact OIDs listed in the request.
• GetNextRequest returns the next OID after the one given, in lexicographic order. Repeating it from a starting point walks a whole subtree, which is how snmpwalk lists what a device exposes.
• GetBulkRequest, added in SNMPv2, packs many GetNext steps into one request, so large tables come back in far fewer round trips. RFC 3416 advises small repetition counts when the network is under stress, because oversized responses get fragmented.
• SetRequest writes a value. Monitoring never needs it, which matters for the security settings below.

UDP gives no delivery guarantee, so the manager waits for a timeout and usually retries before it treats a device as unreachable. A request for the uptime and the state of interface 3 looks like this:

snmpget -v2c -c monitorRO 192.0.2.10 1.3.6.1.2.1.1.3.0 1.3.6.1.2.1.2.2.1.8.3
SNMPv2-MIB::sysUpTime.0 = Timeticks: (863712345) 99 days, 23:12:03.45
IF-MIB::ifOperStatus.3 = INTEGER: up(1)

Notifications: traps and informs

Notifications travel the other way: the agent sends them, unprompted, to the manager on UDP port 162. A trap is a single datagram, and RFC 3416 says there is no confirmation associated with it. An inform, available from SNMPv2c on, is acknowledged by the receiver, so the sender can retry, though RFC 3416 still offers no guarantee of delivery. Standard notifications include linkDown and linkUp (IF-MIB), coldStart and warmStart after a restart (SNMPv2-MIB) and upsTrapOnBattery (UPS-MIB).

What you can monitor over SNMP

The standard MIBs below cover most of what people chart and alert on: SNMPv2-MIB (RFC 3418), IF-MIB (RFC 2863), HOST-RESOURCES-MIB (RFC 2790), UPS-MIB (RFC 1628), ENTITY-SENSOR-MIB (RFC 3433) and Printer-MIB (RFC 3805). The parts in angle brackets are row indexes you look up on the device.

What to watch	Object (MIB)	OID	How to read it
Device uptime	sysUpTime (SNMPv2-MIB)	1.3.6.1.2.1.1.3.0	Hundredths of a second since the SNMP agent last restarted; a drop means a reboot or an agent restart. hrSystemUptime (1.3.6.1.2.1.25.1.1.0) counts from the host's own start.
Interface up or down	ifOperStatus (IF-MIB)	1.3.6.1.2.1.2.2.1.8.<ifIndex>	1 = up, 2 = down, 7 = lowerLayerDown
Traffic, 32-bit	ifInOctets, ifOutOctets (IF-MIB)	1.3.6.1.2.1.2.2.1.10.<ifIndex>, 1.3.6.1.2.1.2.2.1.16.<ifIndex>	Counter32 of bytes; wraps quickly on fast links
Traffic, 64-bit	ifHCInOctets, ifHCOutOctets (IF-MIB)	1.3.6.1.2.1.31.1.1.1.6.<ifIndex>, 1.3.6.1.2.1.31.1.1.1.10.<ifIndex>	Counter64; the right choice on fast links, readable with v2c or v3 only
Interface errors	ifInErrors (IF-MIB)	1.3.6.1.2.1.2.2.1.14.<ifIndex>	Inbound packets that contained errors; watch the rate, not the total
CPU load	hrProcessorLoad (HOST-RESOURCES-MIB)	1.3.6.1.2.1.25.3.3.1.2.<hrDeviceIndex>	Percent of time not idle, averaged over the last minute, one row per processor
Memory and disk	hrStorageUsed, hrStorageSize (HOST-RESOURCES-MIB)	1.3.6.1.2.1.25.2.3.1.6.<hrStorageIndex>, 1.3.6.1.2.1.25.2.3.1.5.<hrStorageIndex>	Both in allocation units (hrStorageAllocationUnits, column 4); RAM, swap and file systems share one table
UPS battery state	upsBatteryStatus (UPS-MIB)	1.3.6.1.2.1.33.1.2.1.0	1 = unknown, 2 = normal, 3 = low, 4 = depleted
UPS runtime left	upsEstimatedMinutesRemaining (UPS-MIB)	1.3.6.1.2.1.33.1.2.3.0	Estimated minutes of battery at the present load if mains power is off or fails
UPS on battery	upsOutputSource (UPS-MIB)	1.3.6.1.2.1.33.1.4.1.0	3 = normal, 5 = battery
Temperature	entPhySensorValue (ENTITY-SENSOR-MIB)	1.3.6.1.2.1.99.1.1.1.4.<entPhysicalIndex>	Read with entPhySensorType (8 = celsius) and entPhySensorScale; many devices report temperature only in a vendor MIB
Printer toner or ink	prtMarkerSuppliesLevel (Printer-MIB)	1.3.6.1.2.1.43.11.1.1.9.<hrDeviceIndex>.<supplyIndex>	Divide by prtMarkerSuppliesMaxCapacity (column 8) for a percentage; -2 = unknown, -3 = some remaining

Not every device implements every MIB, and many put the same data in a vendor MIB instead, so check what a device answers before you build a monitor around an OID. To find which index belongs to which port, walk ifName (1.3.6.1.2.1.31.1.1.1.1):

snmpwalk -v2c -c monitorRO 192.0.2.10 1.3.6.1.2.1.31.1.1.1.1
IF-MIB::ifName.1 = STRING: lo
IF-MIB::ifName.2 = STRING: eth0
IF-MIB::ifName.3 = STRING: eth1

SNMP v1 vs v2c vs v3

The three versions share the same MIBs and mostly the same operations. They differ in how the agent decides to trust a request:

	SNMPv1	SNMPv2c	SNMPv3
Defined in	RFC 1157	RFC 1901, with the SNMPv2 operations now in RFC 3416	RFC 3411 to RFC 3418 (STD 62)
Credentials	Community string	Community string	User name with authentication and privacy keys
Authentication	Community string sent in clear text	Community string sent in clear text	An HMAC on each message at authNoPriv and authPriv (MD5, SHA-1, later SHA-2)
Encryption	None	None	DES or AES at the authPriv level
Replay protection	None	None	Authenticated messages outside a 150-second window are rejected
GetBulk and 64-bit counters	No	Yes	Yes
Notifications	Trap	Trap and inform	Trap and inform
IETF status	Historic	Historic	Internet Standard

A community string is a shared password carried in clear text in every packet, so anyone who can capture the traffic can read it and reuse it. RFC 3410 calls v1 and v2c "fundamentally insecure", and the IETF moved both to Historic status. SNMPv3's User-based Security Model (RFC 3414) has three security levels: noAuthNoPriv (a user name only), authNoPriv (each message is signed, so a forged or altered one is rejected) and authPriv (signed and encrypted). Use authPriv:

snmpget -v3 -l authPriv -u monitor -a SHA -A 'auth-passphrase' -x AES -X 'priv-passphrase' 192.0.2.10 1.3.6.1.2.1.1.3.0

On older devices that speak only v1 or v2c, keep SNMP traffic on a network nobody else can capture.

Polling intervals, counter wrap and rate calculation

Choosing an interval

Poll each value about as often as it can change in a way you would act on. Interface state and a UPS's power source are worth checking every minute, traffic counters every one to five minutes, disk usage every 5 to 15 minutes. Uptime can wait 5 to 30 minutes, since a reboot shows up as a drop whenever you next look. hrProcessorLoad is already a one-minute average, so polling it faster returns overlapping averages. Each poll costs the device some CPU time, so read the OIDs you chart or alert on rather than walking whole tables every cycle.

Counters and wrap

Counters such as ifInOctets only go up. A Counter32 wraps to zero after 4,294,967,295 and a Counter64 after 18,446,744,073,709,551,615 (RFC 2578), so a single reading tells you nothing: the information is in the difference between two readings. RFC 2863 gives the shortest wrap times for a 32-bit octet counter on a fully loaded link: just over 57 minutes at 10 Mb/s, 5.7 minutes at 100 Mb/s and 34 seconds at 1 Gb/s. If a counter wraps twice between polls, nothing in the data shows it and the rate comes out wrong.

That is why IF-MIB added 64-bit high-capacity counters (ifHCInOctets, ifHCOutOctets) and requires 64-bit octet counters on interfaces faster than 20 Mb/s. By the RFC's estimate, a 64-bit octet counter on a 1 Tb/s link takes just under five years to wrap. SNMPv1 cannot carry Counter64 values at all (RFC 3584), so read HC counters with v2c or v3.

Rate from two samples

rate (bit/s) = (octets2 - octets1) * 8 / (t2 - t1)

if a Counter32 wrapped (octets2 < octets1):
delta = octets2 + 4294967296 - octets1

Two polls 300 seconds apart read ifInOctets as 4,200,000,000 and then 105,032,704. The second value is smaller, so the counter wrapped: 105,032,704 + 4,294,967,296 - 4,200,000,000 = 200,000,000 bytes. Times 8, divided by 300, that is about 5.3 Mb/s, or 5.3% of a 100 Mb/s port. For utilization, divide by ifSpeed (bit/s), or by ifHighSpeed (Mb/s) on links faster than 4.29 Gb/s, where ifSpeed tops out. Assuming a single wrap is safe here: 300 seconds at the full 100 Mb/s is 3.75 billion bytes, less than one wrap. At 1 Gb/s it would not be.

Take the time difference from the device's sysUpTime, requested in the same Get as the counters, because network delay and retries skew the poller's own timestamps. And drop any sample where sysUpTime went backward or ifCounterDiscontinuityTime (1.3.6.1.2.1.31.1.1.1.19.<ifIndex>) changed, since the counters were reset and the difference means nothing. sysUpTime counts hundredths of a second modulo 2^32, so it rolls over after about 497 days, which also looks like a restart.

Traps vs polling

	Polling	Traps and informs
Who starts it	The manager, on a schedule	The device, when an event happens
Detection delay	Up to one interval	Seconds
Good for	Trends, rates, capacity, reachability	Link flaps, restarts, a switch to battery power
Load	Grows with devices, OIDs and poll frequency	Only when something happens
When the device dies	The poll times out, which is itself an alert	Nothing arrives

Use polling for reachability and for anything you want on a chart or in an availability report. Use traps or informs for events that cannot wait for the next poll, such as a port that flaps for ten seconds between two polls. When a trap arrives, a poll of the same object confirms the current state.

Why polling from outside still matters

A trap can only report what the device is still able to send. When the device loses power, crashes, or the site loses its uplink, the trap receiver hears nothing, and that silence looks the same as a quiet, healthy network. Traps can also be dropped on the congested link that caused the problem. The UPS-MIB works around this for one event: upsTrapOnBattery is resent every minute until the UPS shuts down or returns to mains power (RFC 1628). A poller that runs outside the device, ideally outside the site's power and network, notices the silence: a poll with no reply after its retries is an alert. One lost UDP packet should not page anyone, so confirm before alerting; the recheck strategies guide compares the options.

SNMP security best practices

• Use SNMPv3 with authPriv. Prefer SHA-2 authentication (RFC 7860) and AES privacy (RFC 3826) where both ends support them, and keep MD5 and DES for devices that offer nothing newer. Give each monitoring system its own user.
• Grant read-only access. A monitor never needs SetRequest, so use a read-only community or a v3 user with no write view. View-based access control (RFC 3415) can also limit the read view to the subtrees you poll, such as system, interfaces and host resources.
• Replace default community strings. Factory defaults such as public are the first thing anyone tries. On a device limited to v1 or v2c, use a long random string and treat it as a password.
• Filter by source address. Configure the agent, and the firewall in front of it, to accept UDP 161 only from your pollers. UDP source addresses can be forged, so an attacker who knows a write community could still send a blind SetRequest, one more reason to keep access read-only.
• Never expose UDP 161 to the internet. An open agent gives away device details to anyone who guesses the community string and can be used for reflection attacks, where a small request with a forged source address triggers a larger response aimed at the victim.
• Watch for failed attempts. Agents count requests with unknown community strings in snmpInBadCommunityNames (1.3.6.1.2.1.11.4.0) and can send an authenticationFailure trap. A rising count means a misconfigured poller or someone guessing.
• Turn SNMP off on devices you do not monitor.

How HostTracker monitors SNMP devices

HostTracker's SNMP monitoring reads one numeric OID per monitor from a router, switch, firewall, UPS or printer over SNMP v1, v2c or v3, with Get or GetNext, on the interval you set, and keeps every reading in the check history. The polls come from HostTracker's fixed internal check network, not its 300+ public checkpoints, so you admit that network with a scoped firewall rule or a VPN endpoint instead of opening port 161 to the internet. When the device stops answering, an alert goes out by email, SMS, voice call, Slack, Telegram, webhooks or another channel; alerts on a threshold for the value itself are not available yet. The SNMP check setup guide covers each field, and what is server monitoring covers the availability and resource checks around it.

Frequently asked questions

What ports does SNMP use?

UDP 161 on the device for requests from the manager, and UDP 162 on the manager for traps and informs. RFC 3417 suggests these values and both can be changed, so a firewall in between has to allow 161 toward the device from the poller and 162 toward the trap receiver.

What is the difference between a MIB and an OID?

An OID is the numeric address of one object, such as 1.3.6.1.2.1.1.3.0 for sysUpTime. A MIB is the module that defines a set of objects: their names, OIDs, types and meaning. The device answers numeric OIDs either way; a monitoring tool needs the MIB file to show names instead of numbers and to know how to interpret each value.

Can SNMP monitor servers?

Yes, if an SNMP agent runs on the server: HOST-RESOURCES-MIB then reports CPU load, memory and disk use, and IF-MIB the network interfaces. Dedicated monitoring agents and external checks can see more than the standard MIBs cover.

Is SNMP still used?

Yes. SNMPv1 and v2c are Historic in IETF terms, but SNMPv3 is a full Internet Standard (STD 62), and routers, switches, UPS units and printers commonly ship with SNMP agents. Newer network operating systems also stream telemetry, pushing data at short intervals instead of waiting to be polled, and many networks run both.

Sources and further reading

• RFC 3411, An Architecture for Describing SNMP Management Frameworks: the manager and agent roles, security levels and the SNMPv3 framework.
• RFC 3416, Version 2 of the Protocol Operations for SNMP: Get, GetNext, GetBulk, traps and informs.
• RFC 3414, User-based Security Model for SNMPv3: authentication, privacy and the 150-second timeliness window.
• RFC 2863, The Interfaces Group MIB: interface objects, 64-bit counters and their wrap times.