Understanding BMC Communication: IPMI, Redfish, and the Hardware Layer

How BMCs Control Servers Even When They’re Off

4 min readFeb 25, 2026

When validating servers, you often encounter a unique scenario: the server is “off,” yet you can still log in remotely, power it on, or read sensor data. How is this possible?

The answer lies in the BMC (Baseboard Management Controller) — an independent processor that manages the relationship between the host system and the physical hardware.

Two Computers Inside One Server

A modern server is essentially two independent computer systems residing on a single motherboard:

The Host System

Components: CPU (x86/ARM), DRAM, OS, Kernel.
Role: Run applications, databases, and workloads.
Power: Use the Main Power Rail.

The BMC

Components: A small independent SoC (usually ARM-based) with its own processor, RAM and storage.
Role: Remote management, hardware health checks, and recovery.
Power: Use the Standby Rail (Always on if the power cord is plugged in).
Key Advantage: It remains “alive” even when the host is powered down (Soft-Off/S5 state).

Two Communication Domains of the BMC

The BMC acts as a bridge, managing two fundamentally different communication paths:

Domain A: Host ↔ BMC (In-Band)

This is how the Operating System talks to the hardware management layer.

Path: Uses the LPC (legacy) or eSPI (modern) bus.
Interface Protocol: KCS (Keyboard Controller Style). This is a register-based “mailbox” where the Host writes a command byte, and the BMC reads and responds.
Dependency: Requires the Host CPU to be running (BIOS stage or OS running) and the correct IPMI drivers (e.g., ipmi_si, ipmi_devintf) to be loaded.

Domain B: BMC ↔ Hardware (Southbound)

This is how the BMC monitors and controls the physical environment.

Path: I2C, SMBus, GPIO, and SPI.
Actions:
Sensors: Polling temperature, voltage, and fan speeds via I2C/SMBus
Power: Toggling GPIOs (like PWR_BTN#) to trigger power cycles.
Firmware: Writing to SPI Flash to update BIOS or its own image.
Dependency: None. This works even if the Host CPU is dead or the OS is crashed.

Management Interfaces: IPMI vs. Redfish

While the BMC performs the same “hardware actions” (like reading a sensor), the way a user triggers those actions depends on the protocol used.

IPMI (The Legacy Standard)

IPMI is a binary-encoded protocol. It is efficient but can be cryptic to debug.

In-Band IPMI

Host OS → IPMI Driver → KCS Registers → LPC Bus → BMC Firmware

Get Allie Hsu’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Use for local management, commands like:

ipmitool sensor list

LPC (Low Pin Count bus) is a low-speed internal motherboard bus connecting the host CPU to the BMC.
In-band means the Host OS actively participates and must be running.

Out-of-Band (OOB) IPMI

Remote PC → Network (UDP 623) → BMC NIC → BMC Firmware

Bypasses the Host OS entirely, commands like:

ipmitool -I lanplus -H <IP> -U <User> -P <Password> sensor list

Protocol: Leverages RMCP (Remote Management Control Protocol), which uses UDP as its transport layer.

Redfish (The Modern Standard)

Redfish is the successor to IPMI, designed for cloud-scale management.

Format: RESTful API, JSON-based, and human-readable.
Transport: Runs over HTTPS (TCP 443).
Path: Almost exclusively Out-of-Band. It talks to the BMC’s internal web service to request data that the BMC has gathered from the hardware sensors.

Core idea: In all cases, the BMC is controlling hardware directly. The host OS is only involved if using in-band communication (KCS over LPC).

Summary: How the Data Flows

To visualize the difference, let’s look at a “Sensor Read” command:

The Request: You send a GET request via Redfish (Network) or a binary command via IPMI (KCS).
The Processing: The BMC firmware receives the request.
The Action: The BMC initiates an I2C/SMBus transaction to the physical sensor chip.
The Response: The sensor returns a raw voltage/hex value; the BMC converts it to degrees Celsius/Volts and sends it back to you through the original interface.

Troubleshooting Guide (Validation Tips)

If you encounter management failures, use this logic to isolate the root cause:

[ Case1 ] In-Band fail, OOB works
Host-side issue: IPMI driver not loaded, KCS driver error, or LPC bus physical failure.

[ Case 2 ] In-Band works, OOB fail
Network-side issue: BMC IP configuration, firewall block (Port 623/443), or BMC NIC failure.

[ Case 3 ] In-Band fail, OOB fail
BMC Firmware issue: The BMC SoC may have hung, is stuck in a boot loop, or has lost power.
In this case, a BMC Cold Reset (pulling the power cord or using a dedicated reset pin) is usually the only way to recover the controller.