MIB Viewer

SNMP Manager / NMS

An SNMP manager - also called an NMS, for Network Management Station - is the system doing the asking in an SNMP conversation. It's typically a monitoring platform that polls dozens, hundreds, or thousands of agents on a regular schedule, collecting values like interface traffic, CPU load, and error counters, and usually storing that data over time for graphing, alerting, and capacity planning.

Familiar examples of the category include general-purpose monitoring platforms like Zabbix, LibreNMS, PRTG, and Nagios (often via SNMP-specific plugins), as well as purpose-built network monitoring tools from various vendors. They all share the same underlying job: send SNMP requests, interpret the responses, and do something useful with the result.

What a manager actually needs to do its job

Polling itself is simple - send a GET or walk a table with GETBULK, get values back. The harder part is making those raw numbers meaningful, which requires:

  • MIB files, compiled/loaded so the manager can translate OIDs into names and correctly interpret data types (a raw integer might actually be an enumerated status value, a counter that wraps, or a specially-encoded textual convention like an IP address or a bitmask).
  • A polling schedule - deciding what to check, how often, and how to handle a device that's slow or unreachable without that one device stalling everything else.
  • A place to put the trap listener if the manager is also meant to receive unsolicited traps/informs on UDP port 162, separate from its outbound polling on port 161.

Polling vs. traps: two different jobs

A manager built purely around polling only knows what it explicitly asked about, on the schedule it asked - it won't notice a brief event between polling intervals. Trap-based monitoring is the complementary approach: the agent itself decides something is worth reporting immediately, rather than waiting to be asked. Most real deployments use both: routine metrics gathered by polling, urgent events (link down, hardware failure) pushed immediately via traps. Traps sent over UDP without acknowledgment can be silently lost, though, which is part of why INFORM (an acknowledged variant) exists for cases where a dropped notification would actually matter.

Why MIB compilation trips people up

A genuinely common source of confusion for anyone setting up a manager for the first time: it isn't enough for a device to support a MIB - the manager also needs that same MIB loaded and correctly parsed before it can display anything meaningful for those OIDs. A perfectly valid response from the agent will show up as an unresolved, unnamed number if the manager doesn't have (or can't parse) the matching MIB. See MIB loading errors and unknown OID for the specifics of what that looks like and how to work through it.