glossary

SNMP Glossary A–Z: Key Terms Explained

An A–Z glossary of SNMP terms, each with a clear definition and a link to the page that covers it in full — the site's central linking and entity hub.

By the SNMP Monitoring team · Reviewed July 2026

SNMP carries a dense vocabulary — agent, MIB, OID, USM, VACM, varbind — and one unfamiliar term can block a whole page of understanding. This glossary defines them tightly and accurately, and every term links to the page that owns its full detail, so you can grab a quick definition here and dive deeper when you need to. It's organized by theme — core concepts, protocol operations, the data model, security, and tooling — with an A–Z index table at the end for fast lookup. Definitions are deliberately short; the nuance lives on the deep pages. Use this as your starting point whenever a term stops you anywhere across the site.

Parent: home · FAQ & reference. Hub for: every cluster below.

Core concepts

The foundational entities that everything else builds on:

  • SNMP — Simple Network Management Protocol, an application-layer protocol (over UDP) for monitoring and managing devices. See what is SNMP.
  • Agent — the SNMP software running on a managed device that answers queries, listening on UDP 161. See what is SNMP.
  • Manager / NMS — the Network Management System that polls agents and collects data, and receives traps on UDP 162. See monitoring.
  • Managed device — any router, switch, server, or appliance running an agent that the manager monitors. See devices.
  • MIB — Management Information Base, the schema that defines managed objects and maps OIDs to names and types. See OIDs & MIBs.
  • OID — Object Identifier, a dotted-number address (e.g. 1.3.6.1.2.1.1.3.0) naming one managed object. See OIDs.

These six are the vocabulary of every SNMP conversation: a manager polls an agent on a managed device for an OID defined in a MIB.

Protocol terms

The message types and operations that move data:

  • PDU — Protocol Data Unit, the structured message an SNMP request or response is carried in. See PDU structure.
  • GetRequest — a request to read one or more specific OIDs.
  • GetNextRequest — a request for the next OID in the tree, used to walk.
  • GetBulkRequest — a v2c+ request that returns many rows efficiently in one exchange.
  • SetRequest — a request to write a value to an OID (the write operation).
  • Response — the reply an agent returns to any request, carrying the values or an error status.
  • Trap — an unacknowledged notification a device pushes to the manager when an event occurs. See traps vs polling.
  • Inform — an acknowledged trap; the receiver confirms delivery.
  • Polling — the manager querying agents on a schedule, the pull model. See traps vs polling.
  • Varbind — a variable binding, one OID-and-value pair inside a PDU.

The split that matters: get/getnext/getbulk/set are manager-initiated (polling); trap and inform are device-initiated (push).

Data-model terms

The types and structures that define what an object is:

  • SMI / SMIv2 — Structure of Management Information, the grammar MIBs are written in (SMIv2 is RFC 2578). See MIB structure.
  • MIB-II — the base standard MIB (RFC 1213) with the system and interface groups every agent implements. See standard MIBs.
  • Enterprise OID — a private OID under 1.3.6.1.4.1.<number>, where vendors define device-specific objects. See enterprise OIDs.
  • Scalar — a single-instance object, addressed with a .0 suffix (e.g. sysUpTime.0).
  • Table — a set of columnar objects with row indexes, like the interface or storage table.
  • TimeTicks — an SMI data type counting hundredths of a second (1/100 s); sysUpTime uses it.
  • Counter32 / Counter64 — ever-increasing counters that wrap at their maximum; graph their rate, not the total.
  • Gauge32 — a value that can go up or down within a range, like a current utilization.

Knowing whether an object is a counter (rate) or a gauge (value) determines how you monitor it — a distinction covered on sensors.

Security terms

The concepts behind SNMP authentication and access control:

  • Community string — the cleartext shared secret authenticating v1/v2c; no encryption. See community-string setup.
  • USM — User-based Security Model (RFC 3414), providing v3 authentication and privacy per user. See SNMPv3 setup.
  • VACM — View-based Access Control Model (RFC 3415), controlling which OIDs a credential may access. See OID allowlist.
  • Security level — the v3 protection tier: noAuthNoPriv, authNoPriv, or authPriv. See security.
  • authPriv — the strongest v3 level, with both authentication and encryption.
  • Engine ID — the unique identifier binding a v3 agent's localized keys; changing it (e.g. after cloning) invalidates users. See SNMPv3 setup.

The one-line security summary: community strings are cleartext (v1/v2c); USM and VACM are v3's authentication and access-control models.

Tooling terms

The software you use to work with SNMP:

  • Net-SNMP — the ubiquitous open-source SNMP toolkit and agent. See Net-SNMP.
  • snmpwalk — the CLI tool that walks a subtree via GetNext. See snmpwalk.
  • snmptranslate — a tool that converts between numeric OIDs and names using loaded MIBs.
  • MIB browser — a GUI for loading MIBs and navigating the OID tree. See MIB browser.
  • AgentX — the standard protocol (RFC 2741) letting subagents extend a master agent.

You can see snmptranslate resolve a name to its numeric OID:

snmptranslate -On SNMPv2-MIB::sysUpTime.0
.1.3.6.1.2.1.1.3.0

That mapping between name and number is exactly what a MIB provides, and what a MIB browser makes navigable. The full toolkit is on tools.

A–Z index

The quick-lookup table:

TermOne-line definitionMore
AgentSNMP software on a device, answers on UDP 161Link
Community stringCleartext v1/v2c shared secretLink
GetBulkEfficient bulk retrieval (v2c+)Link
InformAcknowledged notificationLink
Manager / NMSThe system that polls agentsLink
MIBSchema defining managed objectsLink
OIDDotted-number address of an objectLink
PDUThe SNMP message structureLink
TrapUnacknowledged device notificationLink
USMv3 User-based Security ModelLink
VACMv3 View-based Access Control ModelLink
VarbindOne OID-and-value pairLink

To get the most from the glossary, use it in this order:

  1. Land on a term you don't recognize, here or elsewhere on the site.
  2. Read the short definition to unblock your understanding.
  3. Follow the link to the deep page when you need the full detail or an example.

For an independent, off-box view of the devices these terms describe, see external monitoring with ostr.io.

Frequently asked questions

What does SNMP stand for?

SNMP stands for Simple Network Management Protocol. It's an application-layer protocol, running over UDP, that lets a manager read and sometimes write values on network devices and servers. "Simple" describes the protocol's design; note it doesn't imply security — v1 and v2c are simple but insecure, while v3 adds authentication and encryption.

What's the difference between an OID and a MIB?

An OID (Object Identifier) is the dotted-number address of a single managed value, like 1.3.6.1.2.1.1.3.0 for system uptime. A MIB (Management Information Base) is the schema that defines those objects — mapping each OID to a readable name, a data type, and a description. In short: the OID is the address, the MIB is the dictionary that tells you what lives at that address.

What's the difference between a trap and an inform?

Both are notifications a device pushes to the manager when an event occurs, but a trap is unacknowledged — the device sends it and doesn't know if it arrived — while an inform is acknowledged, with the receiver confirming delivery back to the sender. Informs are more reliable over lossy paths at the cost of an extra round trip; traps are lighter but can be lost silently.

What are USM and VACM?

They're the two security models in SNMPv3. USM, the User-based Security Model (RFC 3414), handles authentication and privacy (encryption) on a per-user basis — it's what makes v3 secure. VACM, the View-based Access Control Model (RFC 3415), controls which OIDs a given user or community is allowed to access, letting you restrict a credential to just the subtrees it needs. USM is the "who are you," VACM the "what may you see."

Key takeaways

  • The glossary gives tight definitions plus a link to each term's deep page — the site's central lookup hub.
  • Core model: a manager polls an agent on a managed device for an OID defined in a MIB.
  • Protocol split: get/getnext/getbulk/set are manager-pull; trap/inform are device-push.
  • Data types decide monitoring: counters need rate, gauges are read directly; TimeTicks = 1/100 s.
  • Security: community strings are cleartext (v1/v2c); USM (auth/priv) and VACM (access) are v3.
  • Use snmptranslate to convert names ↔ numeric OIDs via loaded MIBs.

Monitor it from outside the network

SNMP only tells you a box is healthy while something is still asking. ostr.io polls your endpoints externally and fires email + SMS alerts the moment a reading crosses your line — or the agent goes silent.