Vol. I · No. 46The protocol sectionSat, 10 Oct 2026
Layer 7 · Management · asking devices how they are

SNMP

Simple Network Management Protocol

SNMP is how a monitoring system knows anything. Every managed device exposes a tree of numbered values — interface counters, temperature, uptime — which a manager polls on a schedule, and the device sends a trap of its own accord when something goes wrong.

SNMP exposes a device’s state as a numbered tree that a manager polls — and lets the device shout a trap when it cannot wait to be asked.

You can run this one

Open the SNMP lab →

Poll a router’s byte counter twice and turn the difference into 45 Mbit/s. Pull a cable and the router speaks first, on port 162. Then ask again with SNMPv3—signed, sealed, and still not anonymous.

Intermediate
Operates at
Layer 7
over UDP
Ports
161 · 162
polls · traps
Data model
MIB / OID
a numbered tree
Version
v3
the only secure one

How it works

An OID is a path down the management tree
1.3.6.1.2.1.2.2.1.10.3
The prefix
mib-2
the standard tree everyone implements
The rest
ifInOctets.3
bytes received on interface 3

A MIB file is just a dictionary translating those numbers into names — the wire only ever carries 1.3.6.1.2.1.2.2.1.10.3.

The handful of operations
M →GET 1.3.6.1.2.1.1.3.0 — what is your uptime?
D ←RESPONSE — 42 days, 06:11:23
M →GETNEXT / GETBULK — walk the whole interface table
M →SET — change a value, if you are permitted
D ←TRAP on 162 — “interface 3 just went down”

Polling gives you a graph over time; traps give you the moment something changed. Most monitoring uses both — the poll for trends, the trap for the alert.

The main points

What SNMP does, step by step

1
Expose a MIB

The device publishes its state as a tree of OIDs — counters, gauges, strings and tables.

2
Poll on a schedule

The manager GETs specific OIDs, or walks a table with GETNEXT and GETBULK, every minute or so.

3
Graph the deltas

Counters only ever increase; the monitoring system subtracts successive polls to get a rate.

4
Receive traps

The device sends an unsolicited trap or inform to port 162 when a threshold or link state changes.

Three versions, one choice
v1 — community string, plaintext
v2c — faster, still plaintext
v3 — users, auth and encryption

In cybersecurity

SNMP v1 and v2c authenticate with a single shared string sent in the clear — and the default is famously public, which makes an unhardened device an open book and sometimes an open door.

Community strings

v1/v2c send them unencrypted; anyone on the path reads them and can then poll at will.

Default “public”

Scanners sweep for it constantly — one hit maps a device’s interfaces, routes and neighbours.

Write access is worse

A writable community string lets an attacker reconfigure the device, not merely read it.

Use v3 only

Per-user authentication with SHA and encryption with AES — there is no reason to run anything else.

Amplification

A small GETBULK can return a very large response, which has been used to reflect DDoS traffic.

Restrict by source

Only the monitoring system should be able to reach 161 at all — enforce it on the device and the firewall.

Rides in the stack

IPUDPSNMP

UDP keeps polling thousands of devices cheap — and is why a trap that goes missing is simply never noticed.

Works with

SyslogNTP

Operations & versions

Operations
GETone value
GETNEXTwalk the tree
GETBULKa table at once
SET / TRAPchange / alert
Security
v1 / v2ccommunity, clear
v3 noAuthstill no
v3 authNoPrivsigned only
v3 authPrivthe right answer