What Is SNMP? MIB, OID, Traps, and SNMPv3

Few sentences are repeated as often on a network, and help as little, as “the internet is slow.” Which site, what time, how slow: without those three, slowness isn’t a fault report, it’s an opinion. SNMP (Simple Network Management Protocol) is the protocol that asks network devices exactly those questions on a schedule and turns the answers into measurements.

The quickest way to understand it is an addressable fire alarm system. The panel polls every detector on its loop by address, one by one, asking the same thing each time: “number three, what’s your status?” The detector answers, the panel records it, and moves on. When there’s real smoke, the detector doesn’t wait its turn; it signals the panel itself. Those two behaviors, regular polling and unprompted alarms, explain the whole architecture of SNMP.

It’s the second article in the monitoring and alerts guide, after What Is Syslog? Syslog gives you sentences; SNMP gives you numbers. If you already know the protocol and want the measurement, jump to the community string in a packet.

What Is SNMP, and What Problem Does It Solve?

SNMP is an application-layer protocol for collecting status information from network devices. How many packets a switch dropped, how full a link is, how busy a CPU is: you ask with this protocol. The answer isn’t a sentence but a number, and because it’s a number it can be stored, compared, and graphed.

The problem it solves is really about language. “The internet is slow” is an opinion, not a measurement, and no decision can be built on it. SNMP turns the opinion into a number.

One distinction up front, because it’s the most common confusion in the field. SNMP measures how full a link is; it doesn’t measure whether a device is up. For that, monitoring systems use ping. In practice: users whose signal dropped because an access point went down will also say “the internet is slow,” yet the link isn’t full at all. SNMP tells you utilization, ping tells you reachability; with both, the complaint stops being a debate.

What Breaks as Device Count Grows?

SNMP exists because people don’t scale. In a three-device office you can check each one. The breaking point is simple multiplication: ten sites with a router, a firewall, and two switches each is 40 devices. Reading four values from each (link utilization, CPU, memory, error counters) once a day by hand is 160 readings. Nobody does that, or does it once.

The real issue isn’t effort but continuity. Faults happen when you’re not looking. You only see a link fill at 2 p.m. if you’re looking at 2 p.m. A person can’t watch continuously; a program can.

When You Don’t Need SNMP

Every technology has a lower threshold. In an office with one switch and a few computers, SNMP costs more than it returns: a server to run, software to maintain, a dashboard to read, and no meaningful trend to measure.

The sign you’re past the threshold isn’t device count. It’s any one of these: more than one site, a leased line (capacity you pay for and must grow when it fills), or learning about outages from users. The third is the clearest.

How SNMP Works: Manager, Agent, and Polling

SNMP has two sides: the manager asks, the agent answers. Separating those roles clears up most of the confusion around the protocol.

Manager and Agent

The manager generates the queries: in practice, a monitoring server. The agent is software running on the monitored device. Switches, routers, firewalls, servers, even printers and UPS units carry one.

The relationship is deliberately asymmetric, for security: the agent doesn’t open connections, it listens. A device doesn’t put data on the network unless asked. That shrinks the monitored side’s attack surface, but it has a cost, and you’ll see the mechanism that pays it shortly.

Queries travel over UDP, and that’s a necessity, not a preference. A status query is one shot: if no answer comes, asking again is cheaper than recovering a lost packet. And you need to ask hundreds of devices within seconds; setting up and tearing down a connection for each would make the protocol its own bottleneck.

Polling on Port 161

The manager asking the agent is called polling, and it goes to UDP port 161. The monitoring server asks every device the same questions at an interval you choose, typically every five minutes.

The repetition is where the value comes from. One reading gives you a number; two consecutive readings give you a difference. An interface’s total byte count only ever grows and means nothing alone. Divide the difference between two readings five minutes apart by the time, and you get bandwidth per second. The curve on the graph is that: not raw data, but the difference between two questions. The Cacti installation guide does exactly that division on a real switch port and checks the graph against the raw counter.

That’s exactly what happened in the field note above. Nobody asked a device “are you full right now?”; the system read the same counter every five minutes, accumulated the differences, and a week later the accumulation showed a peak repeating between 9 and 10 a.m.

What Is an SNMP Trap? The Device Speaking First

Polling is regular, and that’s also its weakness. Poll every five minutes and a link that dies right after a poll is noticed about five minutes later. For critical events, that delay is unacceptable.

A trap is a notification the device sends without being asked, and it arrives on port 162. On the fire panel, that’s the detector signaling on its own the moment there’s smoke.

Don’t miss the change of direction, because it’s why there are two ports:

• Poll: manager → agent, destination port 161. The manager asks.
• Trap: agent → manager, destination port 162. The device reports.

So 161 and 162 aren’t “two SNMP ports”; they’re two directions of conversation. If your server isn’t listening on 162, your devices can send notifications for years and none of them will reach you.

To see what a trap carries on the wire, I sent a query to the lab switch with a deliberately wrong community string and listened on 162. All three attempts produced a notification. Here’s one, 67 bytes:

0000  30 41 02 01 01 04 06 70 75 62 6c 69 63 a7 34 02  0A.....public.4.
0010  01 02 02 01 00 02 01 00 30 29 30 0e 06 08 2b 06  ........0)0...+.
0020  01 02 01 01 03 00 43 02 5e ad 30 17 06 0a 2b 06  ......C.^.0...+.
0030  01 06 03 01 01 04 01 00 06 09 2b 06 01 06 03 01  ..........+.....
0040  01 05 05                                         ...

Three details make this packet worth reading.

First, the a7 in byte fourteen. In the query you’ll see shortly, that byte is a0; in the reply, a2. The direction of the conversation isn’t a separate field; it’s encoded in the packet type. That’s how the device says “this isn’t an answer, it’s a notification I’m sending on my own.”

Second, the two values it carries. The first is 1.3.6.1.2.1.1.3.0, the device’s uptime: when the event happened. The second is 1.3.6.1.6.3.1.1.4.1.0, and here’s the point: its value is itself an address, 1.3.6.1.6.3.1.1.5.5, which means “authentication failure.” The type of event isn’t a sentence; it’s a number. The monitoring server looks the number up in its catalog and decides what to do. It doesn’t parse text; it matches numbers. The three notifications’ uptimes were 24237, 24438, and 24637, about two seconds apart: the device reported each attempt separately.

Third, and most uncomfortable, byte seven. Yes, public is here too. The community string travels in plain text not only in your queries but in the notifications the device sends on its own. Even if you never poll, your devices keep announcing that string to the network.

A proper setup uses both: polling gives you trends, traps give you events. Poll only and you hear late; trap only and you can’t plan capacity, because nothing arrives when nothing breaks.

Lab: Why the Trap Receiver Heard Nothing at First

This part isn’t in the Turkish original. Before that capture worked, the notifications were leaving the switch and never reaching the program listening on the Windows workstation. The switch was fine. The Windows firewall was not, and the obvious fix did nothing.

Windows ships a ready-made inbound rule for SNMP traps. Enabling it looks like the answer. Here are its actual filters, read with PowerShell:

foreach ($n in 'SNMPTRAP-In-UDP','SNMPTRAP-In-UDP-NoScope') {
  $r = Get-NetFirewallRule -Name $n
  $a = $r | Get-NetFirewallApplicationFilter
  $s = $r | Get-NetFirewallServiceFilter
  $p = $r | Get-NetFirewallPortFilter
  "{0} | prog={1} | svc={2} | {3}/{4} | enabled={5}" -f $n, $a.Program, $s.Service, $p.Protocol, $p.LocalPort, $r.Enabled
}

SNMPTRAP-In-UDP | prog=%SystemRoot%\system32\snmptrap.exe | svc=SNMPTRAP | UDP/162 | enabled=False
SNMPTRAP-In-UDP-NoScope | prog=%SystemRoot%\system32\snmptrap.exe | svc=SNMPTRAP | UDP/162 | enabled=False

Read the middle of each line. The rule doesn’t open UDP 162; it opens UDP 162 for one program and one service: Windows’ own snmptrap.exe running as the SNMPTRAP service. Any other trap receiver, whether a monitoring agent, a script, or a third-party collector, is a different program, so the rule never matches its traffic. Both rules are also disabled out of the box, and the first is scoped to the local subnet only.

The second obstacle was quieter. On that machine there were inbound block rules matching the interpreter the receiver ran on, and on Windows a block rule wins over an allow rule, whatever order they were created in. So even a correct allow rule for the receiver changed nothing until the block rules were turned off.

The practical checklist when a Windows trap receiver is silent:

1. Confirm the traps leave the device with a capture on the receiver’s interface. If nothing arrives on the wire, the problem is upstream.
2. Don’t rely on the built-in SNMP Trap rule unless you’re actually using Windows’ own trap service. Create an inbound allow rule for UDP 162 bound to your receiver’s program.
3. Look for block rules that match that program or port; they override your allow rule silently.
4. Undo it afterward if it was a test. I didn’t, the first time: the rules stayed open after the measurement and had to be closed later.

What Is a MIB? A Catalog of What a Device Knows

A moment ago a number, 1.3.6.1.6.3.1.1.5.5, turned out to mean “authentication failure.” How does the monitoring server know that? More broadly: how does the manager know what to ask, and the agent what it’s being asked? Both sides need a shared dictionary. That dictionary is the MIB.

A MIB (Management Information Base) is the standard catalog of information that can be requested from a device. It holds no data; it records where data lives: which value is at which address, its type, its meaning.

On the fire panel, that’s the address list prepared at installation: which floor, which room, smoke or heat. When the panel asks a device, only a status value comes back; the list is what makes it meaningful. Lose the list and the panel keeps working, but what it says can’t be read. The panel’s address list maps to the MIB, and a single line’s number maps to an OID.

The MIB’s key property is that it’s agreed in advance. Your monitoring server can ask devices from different vendors the same question because they all implement the same standard catalog.

What Is an OID? An Address in the Catalog

An OID (Object Identifier) is the address of one piece of information in the MIB. It’s a dotted sequence of numbers, hierarchical: a tree that narrows from left to right.

The standard address for a system description:

1.3.6.1.2.1.1.1.0

Each part is a branch: 1.3.6.1 is the root of the internet tree, 2.1 the standard management branch, the next 1 the system group, the next 1 the description object in that group, and the trailing 0 says it’s the object’s single instance. Because the address is hierarchical, it’s predictable:

1.3.6.1.2.1.1.1.0    system description
1.3.6.1.2.1.1.3.0    uptime
1.3.6.1.2.1.1.5.0    system name
1.3.6.1.2.1.1.6.0    location
1.3.6.1.2.1.2.1.0    interface count

Asking the lab switch four of these produced two results most MIB explanations should include and don’t. The interface count came back as 119. The device has 48 ports; the difference is VLAN interfaces, stacking links, and logical interfaces. The number is correct, but it isn’t “port count”; the catalog’s definition decides what it means, not your intuition.

The second is more instructive: system name and location came back empty. The addresses exist, the device understands the question, but nobody filled them in. That’s very common, and the result is a monitoring panel full of nameless boxes, where during an outage you work out which device is talking from its IP address. The MIB gives you a slot; filling it is your job.

Where the Fire Panel Analogy Breaks

Every analogy lies somewhere, and if you don’t say where, readers take the lie as part of the concept.

This one breaks in two places. First, a panel’s address list is specific to that building; the installer writes it. A MIB is universal: 1.3.6.1.2.1.1.1.0 means the same thing on every compliant device in the world. Second, and more important: a fire panel’s loop is physically separate; nothing else in the building uses that cable. SNMP shares the network with your data. To tap a fire loop you have to get into the building; to listen to SNMP, being on the network is enough. That difference is the next section.

SNMP Versions: v1, v2c, and v3

We have a shared catalog and a two-way conversation. One question remains: who’s allowed to ask?

There are three versions, and the difference between them isn’t a feature list; it’s the answer to that question. v1 is the original, and nothing today requires it. v2c is the common one, with better data types and bulk queries, but it stands exactly where v1 does on authentication. v3 adds the security layer this section is about.

Why a Community String Isn’t a Password

A community string is the text used for access in v1 and v2c, and despite common belief it doesn’t behave like a password. The only password-like thing about it is that without it you get no answer. Every other property a password should have is missing: it’s sent unencrypted, it’s resent with every query, and it comes back again inside every reply.

And in the field the string is usually one shared value on every device. Whoever captures it once can query every device that uses it.

Lab: Seeing the Community String in a Packet

That’s the claim; now the measurement.

The standard field answer is “a read-only community is harmless, it can only read.” The point of the test was to separate which part of that is true. I defined a read-only community on a managed switch and built the request by hand instead of using a ready-made tool like snmpwalk, because the point isn’t the answer but the bytes in the packet.

The request for the interface count, 43 bytes without headers:

0000  30 29 02 01 01 04 06 70 75 62 6c 69 63 a0 1c 02  0).....public...
0010  04 64 c8 5a 35 02 01 00 02 01 00 30 0e 30 0c 06  .d.Z5......0.0..
0020  08 2b 06 01 02 01 02 01 00 05 00                 .+.........

Look at the right-hand column. From byte seven it says public. That isn’t decryption or decoding: the string sits in the packet as plain text. The sequence 2b 06 01 02 01 02 01 00 in the middle is the address I asked for, so what I wanted is visible too.

The device’s reply:

0000  30 2a 02 01 01 04 06 70 75 62 6c 69 63 a2 1d 02  0*.....public...
0010  04 64 c8 5a 35 02 01 00 02 01 00 30 0f 30 0d 06  .d.Z5......0.0..
0020  08 2b 06 01 02 01 02 01 00 02 01 77              .+.........w

The trailing 02 01 77 is the expected answer: an integer, 0x77, which is 119. The instructive part is byte seven again: public sits in the reply in plain text too. Someone listening doesn’t even need to catch a query; any reply from the device will do.

One more reading was more uncomfortable. Asking for the system description, the device returned its full model name and firmware version in plain text. I’m masking it here, and the reason is the one you should care about: for an attacker, model and version are the first data point in choosing which vulnerability will work. An open community string doesn’t just grant “read”; it hands over the device’s identity.

The Same Query with SNMPv3

SNMPv3 removes the community string entirely and replaces it with a username, authentication, and encryption. I defined a v3 user on the same switch and asked the same question, again with a hand-written client so both sides were measured under the same conditions.

The mechanism is more than “encryption on”:

1. Discovery. The client first sends an unauthenticated request; the device reports its engine ID, boot count, and uptime. This step has no authentication and, honestly, it’s v3’s soft spot: a listener at least learns the device exists and how long it’s been up.
2. Key derivation. The password isn’t used directly. It’s expanded into a long buffer and hashed, then that hash is combined with the device’s engine ID and hashed again. The result is a key valid only for that device.
3. Signing and encryption. The query body is encrypted with a derived key, and the whole message is signed with another.

Measuring step two is the quickest way to explain v3. The authentication key my client derived from the passwords was:

99e4f6a753f99ab77f6784608e28d89dbab58731

The value the switch stored for that user in its own configuration was identical. Both sides reached the same key independently, because both processed the same password the same way. That’s the design in one line: the password never crosses the network and isn’t stored on the device. What’s stored is a key derived from it that’s useless on any other device.

The v3 request is 131 bytes. The key part:

0030  0b 73 65 72 63 65 69 7a 6c 65 6d 65 04 0c 4e ed  .serceizleme..N.
0040  aa 9d d8 f1 f4 a2 c9 96 73 c9 04 08 c0 f2 fa ed  ........s.......
0050  c9 bc a5 0a 04 2d a8 8b 18 0e 55 9e 7d 09 14 3f  .....-....U.}..?
0060  a2 38 38 c6 b2 21 1f 96 b0 4d a4 fd 3b 4a 3e 86  .88..!...M..;J>.

Two things show at once. The username is plain text: serceizleme sits right there. That’s by design; the other side has to know whose key to verify with. v3 doesn’t hide the username; it hides the password, and I checked programmatically that neither password appears in the packet in any form. And everything after offset 0x50 is noise: the encrypted query body. The address we read openly in the v2c request isn’t there, because the question itself is encrypted. The reply came back the same way, 173 bytes with no readable field; the model name appeared only after decrypting with the derived key.

The difference between v2c and v3 isn’t “encryption was added”; it’s that what counts as identity changed. In v2c, identity is text, so it can be copied. In v3, identity is a key bound to the device; copy it and it still won’t work anywhere else.

Syslog vs. SNMP: Measuring vs. Telling

v3 closes the security side. But however well SNMP is configured, there’s a class of question it can’t answer: a number doesn’t tell the story of an event. SNMP says the CPU is at 80 percent; it doesn’t say which login failed.

A syslog line from the same lab switch:

<189> Aug 18 12:09:19 192.168.1.2-1 TRAPMGR[trapTask]: traputil.c(735) 221 %% Link Down: Vl1

The <189> is syslog’s priority field, decoded in What Is Syslog?; what matters here is that the rest of the line is a sentence. The trap for a comparable event, measured above, is not a line of text but a predefined number and the values bound to it. Side by side:

• Traps are matchable by machines. Triggering an action on a specific OID is easy, because the code is fixed.
• Syslog is readable by people. Which interface, when, in which process: it’s in the sentence, and it’s what you read during an incident.

A proper setup collects both. The most common mistake is setting both up and leaving them ownerless: notifications go to everyone, nobody looks, and a year later the alarm is background noise and the real event is lost in it.

SNMP in the Field: Rollout Order and Troubleshooting

Where to Start, and in What Order

Order matters: done in the wrong order, the setup works but stays exposed.

1. Restrict access first, then enable the protocol. SNMP should be reachable only from the management network where the monitoring server lives. The right place for that is network design, not device configuration; keeping management traffic on its own segment is covered in What Is a VLAN? Also confirm 161 and 162 are closed to the outside at your edge.
2. Use v3; keep v2c only for the transition. Define the v3 user on the monitoring server, verify on one device, migrate the rest, switch v2c off last.
3. Stay read-only. Don’t grant write access over SNMP; configure devices over an encrypted management session.
4. Fill in system name and location. They were empty in the lab, and they’re empty on most devices in the field.
5. Check the device clock. A graph is only as good as its time axis; a drifting clock makes “when did it saturate?” unanswerable.

How to Verify It Works

First, send one query. From the monitoring server, ask one device for one address. If an answer comes back, the path is open; what matters is that it arrived, not what it says.

Second, check the answer makes sense. Does the interface count fit the device? In the lab it was 119, more than the physical ports; not an error, logical interfaces count too. Don’t accept a number without interpreting it.

Third, confirm you’re listening on 162. A working poll doesn’t mean working traps; they’re separate directions and break separately. On a Windows receiver, go through the firewall checklist above.

Common Mistakes

A wrong community string fails silently, which makes diagnosis hard. I measured this too: a query with a deliberately wrong string got no answer at all. No error, no rejection. “Wrong string,” “device down,” “firewall in between,” and “SNMP never enabled” all look the same from the querying side. But the trap capture shows the subtle part: the failure isn’t silent, it’s silent to the wrong side. While the sender hears nothing, the device reports an authentication failure to the monitoring server. Failed attempts are visible, but only to whoever listens on 162. That’s the most concrete security argument for collecting traps.

The device may ship with SNMP off, and that shouldn’t reassure you. My first attempt on the lab switch, with no configuration and the best-known default string, got no answer: it shipped with SNMP disabled. The often-repeated “every switch ships with SNMP on” isn’t true for this device. But the risk isn’t in the default; it’s in the string you choose when you turn SNMP on, and how v2c carries it.

Using the same string on every device. One capture opens the whole inventory.

Treating a five-minute interval as right for every metric. It suits capacity trends, but a peak lasting seconds vanishes inside it. Averages hide short saturation.

Setting up traps and assigning them to nobody. A notification should land with a person or an on-call rotation, not a mailbox.

Conclusion

SNMP isn’t complicated; it fits in two sentences. The manager asks at regular intervals and the agent answers. In an emergency, the agent speaks first. Everything else is detail: the MIB defines what the two sides talk about, the OID which address you ask, and the version who’s allowed to ask.

The real gain isn’t technical. On a monitored network, “the internet is slow” doesn’t start an argument; someone opens a graph, finds the time window, and looks for the cause. The moment an opinion is replaced by a measurement, the problem becomes solvable, even before it’s solved.