Warmup Guide — Management Protocols: Redfish, IPMI, SNMP

Zero-to-expert primer for Phase 03. You need no prior protocol knowledge: this guide starts at "what is a BMC API" and ends with you navigating a Redfish tree, decoding an IPMI sensor, and walking an SNMP MIB — and knowing exactly when to use which. These protocols are how all of your software touches hardware (Phase 01, Ch. 3).

Table of Contents

Chapter 1: The Three Protocols and Why There Are Three

A BMC (and a PDU, a CDU, a switch) is a tiny networked computer that exposes its hardware over a management API. Three such APIs dominate, born in three eras:

  • IPMI (Intelligent Platform Management Interface, 1998): a binary out-of-band standard. You send byte-encoded commands to the BMC over a UDP session (IPMI-over-LAN / RMCP+) and get sensor readings, power control, and event logs back. Powerful, ubiquitous in deployed fleets — and deprecated (Intel stopped developing it in 2019) because it was complex and had a bad security history.
  • SNMP (Simple Network Management Protocol, 1988): a polling protocol from the networking world. A manager polls an agent for values identified by numeric OIDs, or the agent sends unsolicited traps. Still everywhere on PDUs, switches, UPSs, and environmental sensors.
  • Redfish (DMTF, 2015): the modern replacement — a RESTful, JSON, HTTPS, schema-defined API. Human-readable, hypermedia-driven, secure by default, and the standard all new hardware (including AI accelerator platforms) ships. This is the one to know cold.

Why three, still? Because a real fleet is heterogeneous: new accelerator nodes speak Redfish, the rack PDU speaks SNMP, an older switch speaks SNMP, and some BMCs still need IPMI for a specific operation Redfish doesn't yet expose. The senior move is Redfish- first: build your abstraction around Redfish's model and treat IPMI/SNMP as fallback drivers for the gear that needs them (Chapter 8).

Mental model: Redfish is "the hardware as a REST API with a typed schema." IPMI is "the hardware as a binary command set." SNMP is "the hardware as a tree of numbered variables you poll." Same goal (read/control hardware OOB), three idioms.

Chapter 2: Redfish — The Data Model

Redfish models a system as a tree of JSON resources at predictable URLs, all reachable from one entry point. Internalize this tree; it's the spine of the whole protocol.

/redfish/v1                         ← ServiceRoot (the entry point, unauthenticated GET)
├── /Systems        → collection of ComputerSystem   (the HOSTs: power, boot, processors, memory)
│   └── /Systems/1  → one ComputerSystem
│       ├── Actions: #ComputerSystem.Reset           (power on/off/cycle)
│       ├── Processors, Memory, EthernetInterfaces, Storage
│       └── Links → Chassis, ManagedBy(Manager)
├── /Chassis        → collection of Chassis           (the physical boxes)
│   └── /Chassis/1
│       ├── /Power    → PowerSupplies, voltages, PowerControl (draw, cap)
│       └── /Thermal  → Temperatures, Fans
├── /Managers       → collection of Manager            (the BMC ITSELF)
│   └── /Managers/1  → BMC firmware, network, SerialConsole, VirtualMedia
├── /UpdateService  → firmware update (SimpleUpdate, multipart push) → returns a Task
├── /EventService   → event subscriptions (push) / SSE
├── /TaskService    → long-running operations (Tasks)
├── /SessionService → login/logout, sessions
└── /TelemetryService → MetricReports, MetricDefinitions (structured telemetry)

Three resource types carry most of the weight, and beginners conflate them:

  • ComputerSystem = the host (the OS-running machine): power state, boot order, CPUs, memory, NICs. "Reset this server" acts here.
  • Chassis = the physical enclosure: its Power and Thermal sub-resources hold PSUs, voltages, temperatures, fans. "What's the inlet temperature" reads here.
  • Manager = the BMC itself: its own firmware, network config, virtual media, serial console. "Update the BMC firmware" / "mount an ISO" acts here.

A single physical node thus appears as (at least) a ComputerSystem + a Chassis + a Manager, linked together via Links. Knowing which resource owns which capability is the single most useful Redfish skill.

@odata annotations (Redfish builds on OData): @odata.id is a resource's canonical URL (you follow these — never hardcode paths), @odata.type names its schema, and collections carry Members (a list of {@odata.id} links) and Members@odata.count.

Chapter 3: Redfish — Navigation, Actions, Auth

Navigation is hypermedia (HATEOAS): you GET /redfish/v1, read the @odata.id of the Systems collection, GET that, read a member's @odata.id, GET that, follow its Links/Actions. You never hardcode /redfish/v1/Systems/1/... — you follow links, because vendors lay out IDs differently (Chapter 9). Lab 01 does exactly this.

Reading is plain GET returning JSON. $expand lets you pull a collection's members inline in one request (fewer round-trips, bigger payloads — a tradeoff at fleet scale).

Actions are the "do something" verbs, declared in a resource's Actions object and invoked with POST:

POST /redfish/v1/Systems/1/Actions/ComputerSystem.Reset
{ "ResetType": "ForceRestart" }     # GracefulRestart | ForceOff | On | PowerCycle ...

The available ResetType values are advertised in ResetType@Redfish.AllowableValues — you read what's allowed, you don't guess.

Writing config is PATCH (partial update) on a resource (e.g., set the boot device).

Authentication — three levels:

  • Unauthenticated: only ServiceRoot and a few metadata resources.
  • HTTP Basic: username/password on every request — simple, fine for scripts, but re-auths each call.
  • Session-based (the production choice): POST /SessionService/Sessions with credentials → you get an X-Auth-Token header → send it on subsequent requests → DELETE the session to log out. Cheaper than Basic per-call and revocable. Always over HTTPS with certificate validation (Chapter 7).

Chapter 4: Redfish — Events and Tasks

Two features separate a toy client from a production one.

Events — how you learn a PSU failed without polling every BMC constantly:

  • Subscription (push): POST /EventService/Subscriptions with a Destination URL (your listener) and the event types you want. The BMC then POSTs events to you. Scales well but requires your endpoint to be reachable by every BMC.
  • SSE (Server-Sent Events): connect to the ServerSentEventUri and the BMC streams events over a long-lived HTTP connection. No inbound endpoint needed; one connection per BMC.
  • Polling: just GET the relevant resources on an interval. Simplest, but high load and high latency at fleet scale. Use it as a fallback / for resources without events.

The tradeoff (an interview favorite): push/SSE give low latency and low steady-state load but add connection/endpoint management; polling is trivial but doesn't scale to tens of thousands of BMCs at low latency. Production telemetry (Phase 07) usually blends scheduled polling for metrics with event subscriptions for state changes/faults.

Tasks — how Redfish models long-running operations (a firmware update can take minutes): the action returns HTTP 202 Accepted with a Task resource URL (a "task monitor"). You GET that Task to watch TaskState (New→Running→Completed/Exception) and PercentComplete, and read Messages for results. Anything slow returns a Task — firmware updates (Phase 08), some resets, BIOS config jobs. A client that blocks waiting for a synchronous response to a firmware push is broken; the correct pattern is "submit → poll the Task → handle completion/failure" (Lab 01 extension).

Chapter 5: IPMI — The Legacy You Still Must Speak

IPMI is deprecated but pervasive; you will read sensors and SELs from IPMI BMCs for years.

Architecture: the BMC hosts the IPMI stack; you talk to it locally (KCS interface) or remotely over IPMI-over-LAN using RMCP+ (an authenticated, optionally encrypted UDP session — IPMI v2.0). The ubiquitous client is ipmitool:

ipmitool -I lanplus -H <bmc-ip> -U <user> -P <pass> chassis power status
ipmitool -I lanplus -H <bmc-ip> -U <user> -P <pass> sdr list      # sensors
ipmitool -I lanplus -H <bmc-ip> -U <user> -P <pass> sel list      # event log

(lanplus = RMCP+/IPMI 2.0; plain lan is insecure IPMI 1.5 — avoid.)

Sensors and the SDR: the Sensor Data Repository describes every sensor (type, units, and thresholds). A reading comes with its thresholds:

  • lnr/lc/lnc = lower non-recoverable / critical / non-critical
  • unc/uc/unr = upper non-critical / critical / non-recoverable

So a CPU temp reading isn't just "78°C" — it's "78°C, upper-non-critical 85, upper-critical 95," which lets you classify health (OK/Warning/Critical) the way the hardware intends. Lab 02 models this.

The SEL (System Event Log): a BMC-maintained log of hardware events (a PSU lost input, a DIMM corrected-error threshold, a thermal trip). Each record has a timestamp, sensor, and event type. Parsing the SEL is core to diagnostics (Phase 08).

Other IPMI: chassis control (power on/off/cycle/reset), boot-device override (boot once from PXE — Phase 05), and SoL (Serial-over-LAN) to watch a host boot remotely.

Why deprecated: cleartext options, a history of vulnerabilities (cipher-zero auth bypass, password-hash exposure), and protocol complexity. Never expose IPMI to an untrusted network; keep it on the isolated management VLAN (Phase 09) and prefer Redfish where available.

Chapter 6: SNMP — Polling, MIBs, and Traps

SNMP is how you talk to PDUs, switches, UPSs, and environmental gear that don't (yet) speak Redfish.

The model: a manager (your software) polls an agent (the device). Every value the agent exposes is named by an OID (Object Identifier) — a dotted sequence of numbers locating a node in a global tree, e.g. 1.3.6.1.2.1.1.3.0 is sysUpTime. A MIB (Management Information Base) is the human-readable schema mapping names (sysUpTime) to OIDs and types. Enterprise-specific values live under 1.3.6.1.4.1.<enterprise-number> (e.g., a vendor's PDU outlet metering).

The operations:

  • GET — fetch one OID's value.
  • GETNEXT — fetch the next OID in lexicographic order. This is how you discover the tree without knowing it in advance.
  • WALK — repeated GETNEXT to enumerate a subtree (e.g., all outlets' power draw). The ordering is lexicographic by OID, which is why snmpwalk returns values in a predictable, sorted sequence. Lab 02 implements this ordering.
  • GETBULK (v2c+) — fetch many OIDs in one request (efficient WALK).
  • SET — write a value (e.g., switch an outlet off — if the PDU allows).

Traps and informs: unsolicited messages the agent sends to your trap receiver (UDP 162) when something happens (a PSU failed). Traps are fire-and-forget; informs are acknowledged. You run a trap receiver to get low-latency notifications and poll for the full picture — neither alone is sufficient (traps can be lost; polling is slow).

Versions (security-critical):

  • v1 / v2c: authentication is a cleartext community string ("public"/"private"). No encryption. Never on an untrusted network.
  • v3: real security — USM (User-based Security Model) with authentication (HMAC) and privacy (encryption). The only version to use where security matters.

Chapter 7: Security Across the Three

These protocols control power and firmware; a compromise here is catastrophic (Phase 09). The rules:

  • Redfish: HTTPS only, validate certificates (don't disable TLS verification — a shockingly common bug), session tokens over Basic, least-privilege Redfish roles (ReadOnly for telemetry, Operator/Administrator only where needed), and never log the token.
  • IPMI: lanplus (RMCP+) only, strong passwords, disable cipher-suite 0 (the auth- bypass), and treat it as last-resort. Management VLAN only.
  • SNMP: v3 with auth+priv where it matters; if stuck on v2c (read-only PDUs), restrict by ACL to the management network and never use it for writes/secrets.
  • All three: live only on the isolated management network (Phase 01, Ch. 6; Phase 09 builds the isolation). The single biggest real-world failure is a BMC/PDU reachable from a tenant or the internet — Shodan is full of exposed IPMI BMCs.

Chapter 8: The Driver Abstraction — Redfish-First With Fallback

A heterogeneous fleet demands one interface, many backends — the same seam idea as Phase 02 Ch. 9, applied to protocols:

class DeviceDriver(Protocol):
    def power_state(self) -> str: ...
    def set_power(self, action: str) -> None: ...
    def read_sensors(self) -> list[Reading]: ...

class RedfishDriver(DeviceDriver): ...   # preferred
class IpmiDriver(DeviceDriver): ...      # fallback for IPMI-only BMCs
class SnmpDriver(DeviceDriver): ...      # PDUs, switches

Your rack-management code programs against DeviceDriver; a factory picks the driver per device (capability detection: try Redfish ServiceRoot, fall back to IPMI/SNMP). This:

  • isolates protocol quirks behind a stable interface,
  • lets you migrate a device class from IPMI to Redfish without touching callers,
  • makes the whole stack testable with a FakeDriver (Phase 02 seam),
  • is exactly the structure of the Phase 13 capstone and the Phase 07 exporter.

The unified Reading/state model (Lab 02) is the other half: normalize Redfish Thermal.Temperatures, IPMI SDR readings, and SNMP sensor OIDs into one shape so the rest of your system doesn't care where a temperature came from.

Chapter 9: Vendor Variance and the Real World

The dirty secret: "Redfish-compliant" hardware varies. A senior engineer plans for it.

  • Layout differs: System IDs are 1, System.Embedded.1, or a UUID depending on vendor — which is why you follow links, never hardcode paths.
  • Schema gaps & OEM extensions: vendors add Oem blocks for features not in the standard schema, and sometimes omit standard fields. Code defensively (.get() with defaults; validate presence).
  • Bugs & quirks: some BMCs return 200 with an error body, rate-limit aggressively, drop sessions, or implement an action subtly wrong. Apply Phase 02 robustness: retries with backoff, timeouts, idempotency, and a conformance test per vendor (Phase 11).
  • Firmware drift: the same model behaves differently across BMC firmware versions — another reason for the firmware-baseline discipline (Phase 08).

This is where "experience with Redfish APIs" in the JD really means experience with real, imperfect Redfish implementations — and the abstraction (Chapter 8) plus defensive coding (Phase 02) is how you tame it.

Lab Walkthrough Guidance

Order: Lab 01 (Redfish) → Lab 02 (IPMI/SNMP). Learn the modern model first; it gives you the vocabulary (resources, sensors, events) that the legacy protocols map onto.

Lab 01 (Redfish client + mock):

  1. python3 solution.py — it starts an in-process Redfish mock and walks it. Read the printed tree.
  2. Trace the client: GET /redfish/v1 → follow Systems → a System → its Chassis link → Power/Thermal. Notice it follows @odata.id, never hardcodes.
  3. Watch the ComputerSystem.Reset action POST change the System's PowerState.
  4. Extensions: poll a Task to completion; add Session-token auth; point it at the real DMTF Redfish-Mockup-Server or OpenBMC sushy-emulator (the README shows how).

Lab 02 (IPMI/SNMP):

  1. python3 solution.py — read the SNMP OID-tree WALK (note the lexicographic order) and the IPMI SDR/SEL decode.
  2. See all three protocols normalized into one Reading with a health classification from thresholds.
  3. Extensions: parse real ipmitool sdr/sel text; run against snmpsim; emit the unified readings in Prometheus exposition format (the Phase 07 bridge).

Phase capstone question: "A node speaks Redfish, its PDU speaks SNMPv2c, and an older peer BMC only speaks IPMI. Sketch the one interface and three drivers, and say how you'd get a low-latency alert when any PSU fails." (Answer: DeviceDriver with Redfish/IPMI/SNMP backends + a unified Reading; PSU alerts via Redfish EventService subscription/SSE and SNMP traps, with scheduled polling as the backstop.)

Success Criteria

You're done with this phase when — without notes:

  • You can draw the Redfish tree and say which resource owns power vs temperature vs BMC firmware (Ch. 2)
  • You can navigate by following @odata.id links and explain why you never hardcode paths (Ch. 3, 9)
  • You can invoke an Action (POST) and read its AllowableValues (Ch. 3)
  • You can explain Session vs Basic auth and HTTPS/cert validation (Ch. 3, 7)
  • You can explain why firmware updates return a Task and how to monitor one (Ch. 4)
  • You can choose push/SSE vs polling for events and justify it at fleet scale (Ch. 4)
  • You can decode an IPMI sensor with thresholds and a SEL event (Ch. 5)
  • You can perform/explain an SNMP WALK and the lexicographic GETNEXT ordering, and v2c vs v3 (Ch. 6)
  • You can sketch the Redfish-first driver abstraction with IPMI/SNMP fallback (Ch. 8)

Interview Q&A

Q1: What is Redfish and why is the industry moving to it from IPMI? A: Redfish is the DMTF's modern out-of-band management standard: a RESTful, JSON, HTTPS, schema-defined API that models a system as a tree of resources (ServiceRoot → Systems, Chassis, Managers, …). The industry is moving to it because IPMI is a complex binary protocol with a poor security history (Intel deprecated it in 2019): Redfish is human-readable, hypermedia-driven (you follow links, so it's vendor-portable), secure by default (HTTPS, session tokens, role-based auth), and extensible via schemas and OEM blocks. It also models modern needs natively — Tasks for long operations, an EventService for push notifications, a TelemetryService for structured metrics, and Power/Thermal schemas that extend to PDUs and CDUs. New hardware ships Redfish; IPMI/SNMP remain as fallbacks for deployed and non-server gear.

Q2: Walk me through reading a server's power state and CPU temperature with Redfish. A: GET /redfish/v1 (ServiceRoot, no auth needed) and read the @odata.id of the Systems collection. GET that, take a member's @odata.id, GET the ComputerSystem — its PowerState field is on/off. For temperature, follow the System's Links to its Chassis, GET the Chassis, follow its Thermal sub-resource, and read Temperatures[] (each has a ReadingCelsius and threshold fields). The key discipline is that I follow @odata.id links rather than hardcoding /Systems/1/..., because vendors lay out IDs differently — that's what makes Redfish portable. I'd do it over HTTPS with a session token and certificate validation.

Q3: A firmware update takes minutes. How does Redfish handle that, and how do you write the client? A: It's an asynchronous operation. You POST to the UpdateService (SimpleUpdate or a multipart push) and the service responds 202 Accepted with a Task resource URL — a task monitor. The client then polls that Task, reading TaskState (New→Running→Completed or Exception) and PercentComplete, and inspects Messages for the result. So the correct pattern is submit → poll the Task with backoff → handle completion or failure (and surface progress) — never block expecting a synchronous response. This same Task pattern covers BIOS config jobs and some resets. I'd also make the submit idempotent and handle the BMC dropping the session mid-update (Phase 08 goes deeper on staging and rollback).

Q4: How do you get notified when a PSU fails — poll or push? A: Both, layered. For low-latency fault notification I subscribe via the Redfish EventService — either a push subscription (the BMC POSTs events to my listener) or SSE (I hold a long-lived connection per BMC and the BMC streams events). Push scales to many BMCs but needs my endpoint reachable; SSE needs no inbound endpoint but is one connection per BMC. For non-Redfish gear (PDUs), I run an SNMP trap receiver on UDP 162. But events can be missed (lost traps, dropped connections), so I also poll the relevant resources on a schedule as a backstop and to get the full state. At fleet scale (tens of thousands of BMCs) pure low-latency polling is too expensive, so the design is event-driven for state changes plus scheduled polling for metrics — exactly the Phase 07 telemetry pattern.

Q5: What's an OID, and what happens in an SNMP WALK? A: An OID (Object Identifier) is a dotted sequence of numbers naming a node in SNMP's global tree — e.g., 1.3.6.1.2.1.1.3.0 is sysUpTime. A MIB is the schema mapping human names to OIDs and types; vendor-specific values live under 1.3.6.1.4.1.<enterprise>. A WALK enumerates a subtree by repeatedly issuing GETNEXT, which returns the next OID in lexicographic order; you keep going until you leave the subtree. So snmpwalk over a PDU's outlet-power subtree returns each outlet's draw in sorted OID order. v2c uses GETBULK to fetch many at once. The security caveat: v1/v2c authenticate with a cleartext community string and no encryption, so they're management- network-only; v3 (USM) adds real auth and privacy and is what you use where security matters.

Q6: Your fleet has new Redfish nodes, SNMP PDUs, and some IPMI-only BMCs. How do you build one tool? A: A driver abstraction: define one DeviceDriver interface (power_state, set_power, read_sensors, …) and implement RedfishDriver, IpmiDriver, and SnmpDriver behind it, with a factory that detects capability per device (try Redfish ServiceRoot; fall back to IPMI/SNMP). All rack-management logic programs against the interface, so protocol quirks are isolated, a device can migrate from IPMI to Redfish without touching callers, and I can inject a FakeDriver for hermetic tests. I'd pair it with a unified Reading/state model that normalizes Redfish Thermal entries, IPMI SDR readings, and SNMP sensor OIDs into one shape, plus defensive coding for vendor variance (follow links, .get() with defaults, retries/timeouts, per-vendor conformance tests). That's the structure of a real rack-management control plane and of this track's capstone.

Q7 (Staff): "Redfish-compliant" hardware from two ODMs behaves differently. How do you keep your platform sane? A: Treat the standard as necessary but not sufficient. First, never hardcode paths — follow @odata.id links so layout differences (System.Embedded.1 vs a UUID) don't break me. Second, code defensively: .get() with defaults, validate presence, tolerate OEM blocks and missing optional fields, and read AllowableValues instead of assuming. Third, build a conformance harness (Phase 11): a suite that exercises each vendor/firmware combo against my expected behavior, run in CI against their emulators, so a quirk is caught before deployment, not in production. Fourth, work the relationship: feed concrete defects and schema-gap requests back to the ODM (e.g., Pegatron) as part of the protocol documentation and EBOM process (Phase 12) — driving them toward conformance is part of the Staff job. Finally, pin and track BMC firmware versions (Phase 08) because the same model drifts across firmware. The abstraction layer plus the conformance suite plus the partner feedback loop is how a platform stays maintainable across a heterogeneous, imperfect fleet.

References

  • DMTF Redfish — Specification, Schema Index, and the Redfish School — https://www.dmtf.org/standards/redfish
  • DMTF Redfish-Mockup-Server (a real Redfish service to test against) — https://github.com/DMTF/Redfish-Mockup-Server
  • OpenBMC sushy-emulator (a Redfish emulator) — https://docs.openstack.org/sushy/latest/
  • DMTF Redfish Power/Thermal & Outlet equipment schemas (PDU/CDU) — https://redfish.dmtf.org/schemas/
  • IPMI v2.0 Specification (Intel/Dell/HP/NEC) and ipmitool — https://github.com/ipmitool/ipmitool
  • IETF SNMP — RFC 1157 (v1), RFC 3416 (v2c ops), RFC 3414/3826 (v3 USM/priv)
  • Net-SNMP tools (snmpwalk, snmptrapd) & snmpsim simulator — http://www.net-snmp.org/ , https://github.com/etingof/snmpsim
  • "Penetration Testing a BMC" / IPMI security background (Rapid7, Dan Farmer's IPMI papers) — for Chapter 7
  • Cross-track: Security Engineer — hardware/firmware device security