---
type: Topic Hub
title: "What Is SNMP"
description: "SNMP is the Simple Network Management Protocol — a standard way to read health and status from servers, switches and any device over UDP port 161."
resource: "https://snmp-monitoring.com/what-is-snmp/"
tags: [what-is-snmp, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# What Is SNMP

## What is SNMP — definition

What is SNMP? SNMP is the **Simple Network Management Protocol** — a standard, application-layer protocol that lets one system read (and sometimes change) configuration and status values on another over a network. It runs over UDP, typically on port 161, and it's the near-universal way to collect health data from servers, switches, routers, firewalls, printers, and anything else with a management interface. That's the SNMP meaning in a nutshell: a common language for asking a device "what's your state?" and getting a structured answer back.

The protocol is old and deliberately small. It was born in the late 1980s to solve a real headache — every vendor exposing metrics differently — and it won because it kept the wire format simple and the data model consistent. When people say the SNMP protocol, they mean both the messages (get this value, here's the value) and the shared catalog of what those values are. This page defines the protocol and points you to the deeper mechanics; the sub-pages own the details.

One thing worth clearing up early, because it confuses newcomers: "network" in the name is historical, not limiting. SNMP started life managing routers and switches, but the same machinery reads a database server's memory or a UPS battery's charge just as happily. Anything that can run an agent and expose values can be managed by it. That breadth — one protocol, every class of device — is precisely why it became the backbone of infrastructure monitoring rather than a niche networking tool.

## How it works

At its core SNMP is request/response. A single poll runs in four short steps:

1. The **manager** builds a request naming the OIDs it wants and sends it to the agent's UDP port.
2. The **agent** on the target device receives it and checks the request against its access rules.
3. The agent reads the current values from the underlying system and packs them into a response.
4. The manager matches that response to its request and records the values.

Most monitoring is exactly this loop, repeated on a schedule. It's a pull model: the manager decides when to ask, and the agent simply answers whoever's allowed to.

Each request names the data it wants by **OID** — a numeric address like `1.3.6.1.2.1.25.1.1.0`, which happens to be `hrSystemUptime`, the device's uptime. There are a handful of operation types. A `GET` fetches one value. A `GETNEXT` walks to the following item in the tree, which is how tools crawl an entire branch. A `GETBULK` (added in v2c) grabs many rows in one round trip, and a `TRAP` runs the other direction — the agent pushes an unsolicited alert to the manager.

The wire is where the versions differ, and it matters for security:

- **SNMPv1** (RFC 1157) — the original; community string in clear text.
- **SNMPv2c** (RFC 1901, operations in RFC 3416) — adds `GETBULK` and better errors; still a clear-text community.
- **SNMPv3** (RFC 3411–3418) — adds real authentication and encryption through USM and access control through VACM.

Why the layered version story? Because SNMP has been retrofitted for security over thirty-odd years without ever breaking the core request/response model. v1 got the job done but shipped credentials in the clear. v2c improved efficiency — that `GETBULK` matters a lot when you're pulling a switch's whole interface table — yet left the security model untouched. v3 is where authentication and encryption finally arrived, at the cost of more configuration. The upshot for you: pick the version that matches your threat model, not the newest number. I'm keeping this deliberately shallow — the full message-flow walkthrough lives in [how SNMP works](/what-is-snmp/how-snmp-works.md), and the version trade-offs get their own treatment in [SNMP versions](/what-is-snmp/snmp-versions.md).

## Key components / concepts

SNMP is really four moving parts working together. Get these straight and the rest is detail.

| Component | Role | Note |
|---|---|---|
| Managed device | The thing being watched | Runs an agent |
| Agent | Software that exposes values | e.g. `snmpd` on Linux |
| Manager | Polls agents, stores/graphs data | Monitoring server or external checker |
| MIB / OID | The data model and addressing | Objects defined in MIBs, addressed by OID |

![Diagram of the SNMP protocol showing a manager polling an agent on a managed device using the MIB and OID data model](https://snmp-monitoring.com/img/what-is-snmp/snmp-manager-agent-overview.webp)

The **managed device** is any node with something worth reporting. The **agent** is the small daemon on it that answers queries and, if configured, emits traps. The **manager** — sometimes called the network management station — is the client side that polls, records history, and raises alerts. And the whole thing only works because both ends agree on the **MIB/OID** model: the Management Information Base defines what objects exist and the object identifier is each object's unique numeric address. The manager-and-agent relationship is unpacked in [SNMP architecture](/what-is-snmp/architecture.md); the addressing scheme is covered in [MIB and OID explained](/what-is-snmp/mib-and-oid.md). Two more concepts worth naming early: the [community string](/what-is-snmp/community-strings.md) that gates access in v1/v2c, and the choice between [traps versus polling](/what-is-snmp/traps-vs-polling.md) for how data reaches you.

## Practical example

Enough theory. Here's the protocol doing its job. With Net-SNMP installed, ask a host for its uptime:

```bash
snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.1.1.0
```

```
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (90534700) 10 days, 11:29:07.00
```

One request, one answer. Now walk an entire branch instead of a single value — say the storage table, which lists every disk, RAM, and swap area the host knows about:

```bash
snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.2.3.1.3
```

```
HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: Physical memory
HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: /
HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: /boot
```

`snmpwalk` is just `GETNEXT` in a loop, stopping when it leaves the subtree. That single verb — "give me the next thing" — is how monitoring tools discover what a device even has. Swap the OID and you're reading CPU, network counters, or anything else the agent publishes.

![Screenshot of an snmpwalk command returning Host Resources MIB values from a Linux server](https://snmp-monitoring.com/img/what-is-snmp/snmpwalk-example.webp)

## Common pitfalls / notes

A few things trip up almost everyone the first time:

- **Clear-text communities.** In v1 and v2c the community string is effectively a password sent in the open. Treat it like one — don't reuse it, and don't run v2c across the public internet unprotected.
- **UDP means no guarantees.** SNMP rides UDP, so a lost packet is just a lost packet. Pollers retry; don't panic over one missed sample.
- **The agent only shows what it's told to.** If a walk comes back empty, the OID probably isn't in the agent's allowlisted view — not that the device lacks the data.
- **Index suffixes aren't row numbers.** The `.1`, `.3`, `.6` on the end of an OID are table indices the agent assigns, not friendly IDs. Don't read meaning into them.
- **Version choice is a security decision.** ostr.io's SNMP health monitoring uses **SNMPv2c** with a random community string acting as the password, which is a sensible default for read-only polling behind a firewall; reach for SNMPv3 when the traffic crosses untrusted ground.

## FAQ

**What does SNMP stand for?**
Simple Network Management Protocol. The "simple" refers to the protocol's design, not always the experience of configuring it — but the wire format genuinely is lightweight.

**Is SNMP still relevant today?**
Very. It remains the default telemetry protocol baked into servers, network gear, and IoT-adjacent hardware. Newer streaming-telemetry options exist, but nothing matches SNMP's universal support across existing devices.

**What port does SNMP use?**
UDP 161 for agent queries and UDP 162 for traps. Both are configurable — the ostr.io docs even recommend moving 161 to a random port to cut down on unwanted probing.

**Is SNMP secure?**
It depends entirely on the version. v1 and v2c send the community string in clear text, so they belong on trusted networks or behind a tunnel. v3 adds authentication and encryption. See [SNMP versions](/what-is-snmp/snmp-versions.md) for the full comparison.

## Conclusion

So, what is SNMP? A small, standardized protocol that turns device health into structured values you can read by their OIDs — the backbone of practically all infrastructure monitoring. You've got the definition, the operations, the components, and a working example; the next logical step is [SNMP architecture](/what-is-snmp/architecture.md) to see how manager and agent fit together. And when you're ready to watch these values without trusting the box to report on itself, [ostr.io Monitoring](https://ostr.io/service/monitoring) polls them from outside your network — the [double durability](/monitoring/double-durability.md) principle in action.