SNMP by Device Type: Servers, Network Gear, UPS & More

By the SNMP Monitoring team · Reviewed July 2026

One pattern repeats across every device you'll ever monitor with SNMP: a portable standard layer everything shares, plus a vendor-specific layer that adds the interesting depth. A Cisco switch, a Linux box, and a UPS all answer the same MIB-II queries for system info and interfaces — then diverge into proprietary OIDs for CPU temperature, RAID health, or battery runtime. Learn that split once and every new device becomes predictable: start with the standard MIBs, then reach for the vendor MIB where you need more. This pillar maps the pattern and links to a guide for each device type.

Parent: home. Hub: glossary, sensor index.

Standard MIBs work everywhere

The portable baseline is what makes SNMP universal. Nearly every SNMP-capable device implements:

• MIB-II (1.3.6.1.2.1) — the system group (description, uptime, contact, location) and more.
• IF-MIB (1.3.6.1.2.1.2 and .31) — the interface table: traffic counters, status, errors.
• HOST-RESOURCES-MIB (1.3.6.1.2.1.25) — on servers: CPU, storage, memory, processes.

Point a manager at any of them and you get identity, uptime, and interface stats with zero vendor knowledge. That's the guaranteed floor — the metrics you can rely on being present regardless of who made the box. The standard modules are detailed on standard MIBs.

Vendor MIBs add depth

The standard layer stops at the generic. Anything specific to a vendor's hardware — a Cisco line card's temperature, a Juniper chassis sensor, a MikroTik health reading, a disk array's RAID status — lives under the enterprises subtree (1.3.6.1.4.1), where each vendor owns a numbered branch (Cisco is .9, Juniper .2636, and so on). To read those you load the vendor's MIB so the numeric OIDs resolve to names, and you consult the vendor's documentation for what's exposed. The trade-off is portability: vendor OIDs give depth but only on that vendor's gear, so never assume one is universal. Enterprise OIDs are explained on enterprise OIDs.

Devices covered

Each device type has its own guide, with the standard-plus-vendor pattern applied:

• Linux — net-snmp agent, HOST-RESOURCES and UCD for CPU/RAM/disk/load.
• Windows — the built-in (legacy) SNMP Service, and when to prefer WMI.
• Cisco — IOS/IOS-XE config plus CISCO enterprise MIBs for CPU/memory/environment.
• Juniper — Junos config plus the JUNIPER-MIB chassis family.
• MikroTik — RouterOS SNMP and MikroTik health OIDs.
• Printers — the standard Printer-MIB for supplies and status.
• NAS — storage and volume health via standard and vendor MIBs.
• UPS — the standard UPS-MIB for battery, load, and runtime.
• ESXi — hypervisor host hardware and health.
• Firewalls — sessions, throughput, and vendor security MIBs.
• IoT — lightweight sensors and the constraints they bring.

Server vs network vs appliance

Device class is the quickest way to know what to monitor and where to look:

The rule the table encodes: standard MIB for the basics of each class, vendor MIB for the depth.

Why does the split fall this way? Because the SNMP standards bodies could only standardise what's common across all vendors — an interface is an interface, a filesystem is a filesystem, so those got well-defined MIBs everyone implements. But a Cisco line card's temperature sensor, a NetApp aggregate's health, or a specific UPS model's battery chemistry are vendor inventions with no cross-vendor equivalent, so each vendor defined its own OIDs under its private enterprise branch. That's not fragmentation for its own sake — it's the only place proprietary data can live. The upshot for you is a reliable mental model: if a metric is generic enough that every device has it, expect it in a standard MIB; if it's specific to one vendor's design, expect it under that vendor's enterprise tree, and expect to load their MIB to read it by name. Once that clicks, approaching an unfamiliar device stops being guesswork and becomes a two-step routine.

A universal first check

Whatever the device, the first thing to run is always the same — walk the system group to confirm it answers and identify it:

snmpwalk -v2c -c public 10.0.0.20 system

SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, C2960 Software
SNMPv2-MIB::sysUpTime.0 = Timeticks: (987654321) 114 days, 7:49:03.21
SNMPv2-MIB::sysName.0 = STRING: core-sw01

The onboarding routine for any new device is the same four steps:

1. Walk system to confirm the device answers and read its sysDescr.
2. Identify the vendor/platform from sysDescr — it points you at the right vendor MIB.
3. Walk the interface table (ifName or ifDescr) to confirm IF-MIB works.
4. Load the vendor MIB only when you need proprietary metrics beyond the standard set.

Those first three walks establish the standard baseline on any device before you go vendor-specific — a routine that works identically whether the box is a switch, a server, or a UPS.

Frequently asked questions

Does SNMP work on all devices?

Nearly all network and hardware devices support SNMP, and almost all implement the standard MIBs (MIB-II, IF-MIB, and HOST-RESOURCES on servers), so you get identity, uptime, and interface stats universally. Vendor-specific depth varies, and some minimal IoT devices have limited or no SNMP, but the standard baseline is very widely supported.

Do I need vendor MIBs?

Only for depth. The standard MIBs cover identity, uptime, interfaces, and basic server resources on any device without vendor MIBs. You load a vendor MIB when you need proprietary data — a specific CPU temperature, RAID status, or a vendor feature — so the numeric OIDs resolve to names. For basic health, the standard baseline is often enough.

Which MIB works on any device?

MIB-II (1.3.6.1.2.1) — especially its system group and, via IF-MIB, the interface table — is the closest thing to universal. Almost every SNMP device implements it, so a walk of the system group and interfaces works regardless of vendor. Servers add HOST-RESOURCES-MIB for CPU, memory, and storage on top of that baseline.

How do I start monitoring a new device?

Run snmpwalk -v2c -c <community> <host> system first — if it answers, read the sysDescr to identify the device and its vendor, then walk the interface table to confirm IF-MIB. From there, load the vendor's MIB for any proprietary metrics you need. That standard-first sequence works on any SNMP device.

Key takeaways

• Every device follows the standard + vendor pattern — portable baseline plus proprietary depth.
• Standard MIBs (MIB-II, IF-MIB, HOST-RESOURCES) work everywhere.
• Vendor MIBs under enterprises 1.3.6.1.4.1 add depth but only on that vendor's gear.
• Match device class → key MIB → what to watch (see the table).
• First check on any device: snmpwalk … system, then the interface table.
• For independent off-box coverage of any device, see external monitoring with ostr.io.