By the SNMP Monitoring team · Reviewed July 2026
For server hardware monitoring, the defining question isn't "which reads more sensors" — it's where the monitoring lives. SNMP is in-band: it runs through the operating system, so it works when the OS is up and goes dark when the OS doesn't. IPMI and its modern successor Redfish are out-of-band: they're served by a dedicated baseboard management controller (BMC) that keeps working even when the server is crashed or powered off, and can power-cycle the box remotely. That single distinction decides most of when to use which. This page lays it out — and why data centres run both.
Parent: comparisons. Related: hardware monitoring, temperature sensor.
SNMP: in-band hardware data
SNMP reads hardware health in-band — through the host's OS agent, which exposes sensor data via MIBs like ENTITY-SENSOR-MIB and HOST-RESOURCES-MIB. That gives you temperatures, fan speeds, storage, and the rest, in the same protocol and dashboards as everything else you monitor. The dependency is the catch: because it runs in the OS, SNMP hardware monitoring needs the OS (or a BMC's own SNMP stack) to be up and reachable. If the server hangs, panics, or is powered off, the OS agent stops answering — precisely when you might most want to know what's wrong. For routine health across a fleet, in-band SNMP is efficient and uniform; its blind spot is the downed host. Hardware metrics are covered on hardware monitoring.
snmpwalk -v2c -c public 10.0.0.20 entPhySensorValue
ENTITY-SENSOR-MIB::entPhySensorValue.10 = INTEGER: 42
IPMI/Redfish: out-of-band via the BMC
IPMI and Redfish work out-of-band, through the BMC — a small, independent management processor on the motherboard (HPE calls its implementation iLO, Dell iDRAC) with its own network connection, power, and firmware. Because the BMC runs independently of the main CPU and OS, it keeps reporting sensor data when the OS is down or the server is powered off, and it can do things SNMP can't: remote power control (power on/off/cycle), console redirection, and boot management. You query legacy IPMI with tools like ipmitool:
$ ipmitool sensor reading "CPU1 Temp"
CPU1 Temp | 42.000
That independence is the whole point of out-of-band: it's lights-out management that survives the failure of the thing it's monitoring.
Comparison table
The two approaches, side by side:
| Dimension | SNMP (in-band) | IPMI/Redfish (out-of-band) |
|---|---|---|
| Path | Through the OS/agent | Through the BMC |
| Works when OS is down? | No | Yes |
| Works when powered off? | No | Yes (BMC on standby) |
| Power control | No | Yes |
| Cross-device uniformity | High (one protocol) | Per-BMC / vendor |
| Best for | Fleet health metrics | Lights-out access & control |
They're not really competitors — they occupy different layers, and the "works when OS is down" row is the one that decides most deployments. There's a security dimension the table understates, too: because the BMC is an always-on, network-connected computer with deep control over the server, it's also a high-value attack surface that must be secured carefully — kept on an isolated management network, patched, and never exposed to the internet. Legacy IPMI in particular has a history of security weaknesses, which is part of the industry's push toward Redfish. So while out-of-band access is powerful, it comes with a governance responsibility that in-band SNMP — running as an ordinary read-only service — doesn't carry to the same degree.
Redfish vs IPMI
Within out-of-band, there's a generational shift worth noting. IPMI is the long-standing but ageing standard — functional, widely supported, but built on an older, security-criticised design that many vendors are moving away from. Redfish (from the DMTF) is its modern successor: a REST/JSON API over HTTPS, far friendlier to automation and scripting than IPMI's binary protocol, with a structured schema. New servers increasingly favour Redfish, and it's the direction of travel for out-of-band management. If you're building fresh automation against a BMC, prefer Redfish where the hardware supports it; IPMI remains for older gear.
When to use which
Match the tool to the need:
- Routine hardware health across a fleet? → SNMP, for one uniform protocol.
- Monitoring a server that might be hung or off? → IPMI/Redfish via the BMC.
- Need to power-cycle or console into a box remotely? → IPMI/Redfish (SNMP can't).
- Standardising metrics with everything else? → SNMP.
- Lights-out data-centre management? → out-of-band, with SNMP for the in-band view.
The rule of thumb: SNMP for in-band fleet metrics, IPMI/Redfish for anything that must survive or control the host itself.
Bridging
The line blurs helpfully in practice: many BMCs also speak SNMP. A BMC can expose its out-of-band sensor data and send traps over SNMP, so you can fold lights-out hardware health into your existing SNMP monitoring without adopting a separate IPMI toolchain for read-only checks. That's often the pragmatic middle path — SNMP for the unified dashboards, using the BMC's SNMP where available for out-of-band reach, and reserving native IPMI/Redfish for power control and deep management. Device-specific guidance is on the devices hub.
Frequently asked questions
Should I use SNMP or IPMI for hardware monitoring?
Use SNMP for routine, uniform hardware health across a fleet — it's one protocol for everything and integrates with your existing dashboards. Use IPMI or Redfish when you need out-of-band access: monitoring a server that may be hung or powered off, or remote power control. They're complementary, so many data centres run both, and many BMCs even expose their data over SNMP too.
Does IPMI work when the OS is down?
Yes — that's its defining advantage. IPMI (and Redfish) are served by the BMC, an independent management processor with its own power and network, so they keep reporting sensor data and allow control even when the operating system is crashed or the server is powered off. SNMP, running in-band through the OS, cannot do this.
What is Redfish?
Redfish is a modern out-of-band management standard from the DMTF — a REST/JSON API over HTTPS that serves as the successor to legacy IPMI. It exposes the same kind of BMC-served hardware data and control but through a structured, automation-friendly interface, unlike IPMI's older binary protocol. New servers increasingly favour Redfish for lights-out management.
Can a BMC use SNMP?
Often yes. Many BMCs (iLO, iDRAC, and others) can expose their out-of-band sensor data and send traps over SNMP in addition to IPMI/Redfish. That lets you fold lights-out hardware health into your existing SNMP monitoring for read-only checks, while still using native IPMI or Redfish for power control and deeper management functions.
Key takeaways
- The core difference is in-band (SNMP) vs out-of-band (IPMI/Redfish).
- SNMP runs through the OS — great for fleet health, but dark when the OS is down.
- IPMI/Redfish run through the BMC — work when the OS is down or powered off, and offer power control.
- Redfish (REST/JSON) is the modern successor to legacy IPMI.
- Many BMCs also speak SNMP, so the two overlap for read-only checks.
- Use SNMP for in-band metrics, IPMI/Redfish for lights-out access — data centres run both.