Interview Bank 02 — Protocols & Hardware Interfacing

Phases 03–04, 08. Redfish/IPMI/SNMP, BMC/PDU/CDU/PCIe, firmware lifecycle, and RAS diagnostics. Full answers in the phase WARMUPs; this is the high-yield set.

Q1. What is Redfish and why is the industry moving to it from IPMI?

Redfish is the DMTF's modern OOB standard: RESTful, JSON, HTTPS, schema-defined, modeling a system as a resource tree (ServiceRoot → Systems, Chassis, Managers, …). The move from IPMI (binary, complex, poor security history — Intel deprecated it in 2019) is because Redfish is human-readable, hypermedia- driven (follow links → vendor-portable), secure by default, and models modern needs natively (Tasks for long ops, EventService for push, TelemetryService, Power/Thermal schemas extending to PDUs/CDUs). (P03 Ch. 1–2; Q1.)

Q2. Discover a server's power state and CPU temperature with Redfish — walk me through it.

GET /redfish/v1, follow the Systems collection's @odata.id, GET a member — PowerState is on the ComputerSystem. For temperature, follow the System's Links.Chassis, GET the Chassis, follow Thermal, read Temperatures[].ReadingCelsius. Key discipline: follow @odata.id links, never hardcode paths, because vendors lay out IDs differently — that's what makes Redfish portable. Over HTTPS with a session token and cert validation. (P03 Ch. 2–3; Q2.)

Q3. Which Redfish resource owns power state vs temperature vs BMC firmware?

System = the host (power state, boot, CPUs; the Reset action). Chassis = the physical box (its Power sub-resource: PSUs/draw/cap; its Thermal: temps/fans). Manager = the BMC itself (its firmware, network, virtual media). One node = a System + a Chassis + a Manager, linked. Conflating them is the #1 Redfish mistake. (P03 Ch. 2.)

Q4. A firmware update takes minutes — how does Redfish model it, and how do you write the client?

Asynchronously: POST UpdateService (SimpleUpdate/multipart) → 202 + a Task; poll the Task's TaskState (New→Running→Completed/Exception) and PercentComplete. The client must submit → poll → handle completion/failure, never block on a synchronous response. Same Task pattern covers BIOS config jobs. (P03 Ch. 4; Q3.)

Q5. How do you get notified a PSU failed — poll or push?

Both, layered: Redfish EventService subscription (BMC POSTs to my listener) or SSE (long-lived connection, one per BMC) for low-latency faults; SNMP traps (UDP 162) for non-Redfish PDUs; and scheduled polling as the backstop (events can be lost). At fleet scale: event-driven for state changes, scheduled polling for metrics. (P03 Ch. 4; Q4.)

Q6. What's an OID, and what happens in an SNMP WALK? v2c vs v3?

An OID is a dotted-number name in SNMP's global tree (e.g., 1.3.6.1.2.1.1.3.0 = sysUpTime); a MIB maps names↔OIDs; vendor data lives under 1.3.6.1.4.1.<enterprise>. A WALK enumerates a subtree via repeated GETNEXT in lexicographic (per-component numeric) order (so .2 before .10). v1/v2c authenticate with a cleartext community string (mgmt-net only); v3 (USM) adds auth + privacy and is what you use where security matters. (P03 Ch. 6; Q5.)

Q7. Your fleet has Redfish nodes, SNMP PDUs, and IPMI-only BMCs — one tool, how?

A driver abstraction: one DeviceDriver interface with RedfishDriver/IpmiDriver/SnmpDriver backends and a capability-detecting factory; all logic programs against the interface and a unified Reading model normalizes telemetry. This contains protocol quirks, lets a device migrate protocols without touching callers, and is testable with a FakeDriver. Plus defensive coding for vendor variance (follow links, .get() defaults, retries/timeouts, per-vendor conformance tests). (P03 Ch. 8–9; Q6.)

Q8. How do you reinstall an OS on a server you can't physically touch?

OOB via the BMC's virtual media: mount the installer ISO over Redfish as a virtual CD, set next-boot to it (one-time override), power-cycle, watch over SoL, then eject and boot from disk. Works even with no/broken OS — the whole point of OOB, and the rescue path behind PXE provisioning. (P04 Ch. 3; Q2.)

Q9. An accelerator is "healthy" but 4× slow — how could PCIe be the cause, and how do you find it?

A degraded link: the PCIe link negotiated down (x16→x4 or Gen5→Gen1), collapsing bandwidth while the device still enumerates and reports healthy. Find it by comparing LnkSta (negotiated) vs LnkCap (capable) in lspci -vvv or sysfs (current_link_width/speed vs max_*). Also check NUMA adjacency (GPU+NIC same socket) and AER correctable rates. (P04 Ch. 6–7; Q4.)

Q10. How do you safely update firmware on 1,000 nodes, and what are A/B banks?

Per node: verify before touching HW (checksum + signature + version + anti-rollback) → flash the inactive A/B bank (active firmware keeps running) → activate → verify after (version + health) → commit or roll back to the previous bank. A/B means a bad flash never destroys working firmware (critical for the BMC). Across the fleet: drain-first (P06), dependency order, canary 1→1%→10%→rest with auto-rollback (P11), don't update a whole failure domain at once. (P08 Ch. 3, 5; Q1.)

Q11. PCIe AER / CPU MCE — correctable vs uncorrectable, and a flood of correctable ECC?

AER: correctable (recovered; a rate signals a marginal link → monitor) vs uncorrectable (non-fatal → cordon, fatal → RMA). MCE: bank → subsystem, address → DIMM; correctable ECC = log, uncorrectable = RMA. A flood of correctable ECC on one DIMM is a predictive-failure signal → schedule replacement before it throws an uncorrectable (crash). Rate, not raw count. (P08 Ch. 6–7; Q4–5.)

Quick-fire drills

  • Follow @odata.id links; never hardcode Redfish paths.
  • System=host power; Chassis=temps/PSUs; Manager=BMC firmware.
  • Firmware/long-op = a Task (202 → poll).
  • ipmitool -I lanplus (RMCP+) only; disable cipher-0.
  • SNMP WALK = lexicographic GETNEXT; v3 for security.
  • A/B banks + verify before & after + anti-rollback.
  • Degraded link = LnkSta < LnkCap (silent perf killer).
  • RAS action tree: log → monitor (rising correctable) → cordon → RMA the FRU.