Markdown

IPMI (legacy OOB protocol)¶

Scope: operating a BMC over the network with ipmitool -I lanplus (chassis power, sensors, SEL, LAN and user config), plus the protocol's security weaknesses (cipher 0, default creds, RAKP hash disclosure) and why it is being superseded by Redfish.

All snippets below are reference templates, not hardware-tested. Validate against your BMC vendor's documentation and a lab node before fleet use.

What it is¶

IPMI (Intelligent Platform Management Interface) is a hardware-level management interface implemented by the BMC. It runs independently of the host OS, CPU, and main power state, so you can read sensors, drive power, and inspect the event log on a node that is wedged, off, or has no working OS.

Over the network, IPMI is delivered by RMCP/RMCP+ over UDP port 623 (Rapid7). ipmitool exposes two LAN transports:

-I lan: RMCP, the IPMI 1.5 transport. No encryption.
-I lanplus: RMCP+, the IPMI 2.0 transport. Adds session authentication, integrity, and encryption (ipmitool(1)).

Use lanplus for every real interaction. lan is plaintext and should be treated as a diagnostic-only fallback.

The protocol is frozen. The IPMI promoters announced there will be no further revisions to the specification and point integrators at DMTF's Redfish as the modern replacement (HPE). Treat IPMI as a legacy compatibility surface, not a target for new automation.

Why it's needed (and when)¶

You reach for IPMI/ipmitool when:

The BMC predates usable Redfish (older Supermicro/Dell/HPE generations, many whitebox boards). Redfish coverage on older firmware is partial or absent, so ipmitool is the only out-of-band path.
You need a scriptable, dependency-light power and sensor primitive in a provisioning or recovery path (provisioning tools, bare-metal PXE).
A node is unreachable in-band and you need lights-out power-cycle or SEL inspection (OOB-unreachable runbook).

Prefer Redfish wherever the BMC supports it: it is HTTPS/JSON, schema-driven, and not burdened by the cipher-0 and RAKP weaknesses below. Provisioning stacks reflect the same security gap. For example, OpenStack Ironic ships both an ipmi (ipmitool) driver and a redfish driver, and its ipmitool driver notes that IPMI 1.5 "does not support encryption" and so "highly recommended that version 2.0 is used" (Ironic IPMI driver).

This page does not re-document the schedulers that sit on top of provisioned nodes; see Slurm, Kubernetes, k3s, and the provisioning and scheduling overview.

How it's set up & managed¶

ipmitool needs the BMC address, a user, a password, and (for lanplus) a privilege level. The connection flags are stable across subcommands (ipmitool(1)):

-I lanplus: use the RMCP+ (IPMI 2.0) transport.
-H <addr>: BMC IP or hostname (required for lan/lanplus).
-U <user>: BMC username.
-P <pass>: password on the command line. Prefer -E (read from IPMI_PASSWORD) or -f <file> so the secret is not in your shell history or the process table.
-L <privlvl> sets session privilege: CALLBACK, USER, OPERATOR, ADMINISTRATOR. Default is ADMINISTRATOR.
-C <suite>: IPMI 2.0 cipher suite for lanplus. Modern ipmitool defaults to suite 17 (RAKP-HMAC-SHA256 / HMAC-SHA256-128 / AES-CBC-128).

Reference template (not hardware-tested). Pass the password via environment, not -P:

export IPMI_PASSWORD='REDACTED'
BMC=bmc-node01.mgmt.example.net
USER=ops

# -E reads the password from $IPMI_PASSWORD
ipmitool -I lanplus -H "$BMC" -U "$USER" -E -L ADMINISTRATOR chassis status

Chassis power¶

The chassis power subcommands map to the documented states (ipmitool(1)):

# Read current power state
ipmitool -I lanplus -H "$BMC" -U "$USER" -E chassis power status

# Power on
ipmitool -I lanplus -H "$BMC" -U "$USER" -E chassis power on

# Soft power off (graceful S4/S5)
ipmitool -I lanplus -H "$BMC" -U "$USER" -E chassis power off

# Power cycle: off, then on after >= 1s
ipmitool -I lanplus -H "$BMC" -U "$USER" -E chassis power cycle

# Hard reset (no graceful shutdown)
ipmitool -I lanplus -H "$BMC" -U "$USER" -E chassis power reset

Per the man page: off requests a soft power-down into S4/S5; cycle guarantees an off interval of at least one second; reset is a hard reset with no OS shutdown (ipmitool(1)). Use cycle/reset only after the host is drained; they do not flush filesystems or stop jobs.

Sensors¶

# Sensors with readings and threshold columns
ipmitool -I lanplus -H "$BMC" -U "$USER" -E sensor list

# Sensor Data Records (often faster; same underlying data)
ipmitool -I lanplus -H "$BMC" -U "$USER" -E sdr list

sensor list prints sensors and thresholds in a wide table; sdr list reads the Sensor Data Records and queries each sensor (ipmitool(1)). For repeated SEL/SDR work you can cache the SDR locally with sdr dump <file> and pass it via -S <file> to speed up subsequent calls.

System Event Log (SEL)¶

# SEL summary: entries, capacity, last add/erase
ipmitool -I lanplus -H "$BMC" -U "$USER" -E sel info

# Dump the event log
ipmitool -I lanplus -H "$BMC" -U "$USER" -E sel list

# Extended list: cross-reference SDR to name the sensor per event (slower)
ipmitool -I lanplus -H "$BMC" -U "$USER" -E sel elist

# Clear the SEL (destructive; capture it first)
ipmitool -I lanplus -H "$BMC" -U "$USER" -E sel clear

sel elist joins each event against the SDR to print the sensor that caused it, so it is slower than sel list but more legible (ipmitool(1)). sel clear is irreversible, so archive the log before clearing during an incident.

LAN and user configuration¶

# Print the LAN config for management channel 1 (IP, gateway, VLAN, cipher policy)
ipmitool -I lanplus -H "$BMC" -U "$USER" -E lan print 1

# List configured BMC users and their privilege levels
ipmitool -I lanplus -H "$BMC" -U "$USER" -E user list 1

# Which cipher suites does this channel accept?
ipmitool -I lanplus -H "$BMC" -U "$USER" -E channel getciphers ipmi 1

lan print <channel> shows the current configuration for that channel; user list <channel> lists all defined user IDs; channel getciphers reports the cipher suites the channel will accept (ipmitool(1)). The channel number is BMC-specific (commonly 1 for the dedicated LAN port); confirm with channel info.

Security weaknesses (read before exposing any BMC)¶

IPMI's network surface has three well-documented, largely unfixable weaknesses. The mitigation for all of them is the same: keep BMCs on an isolated OOB network, never on a routable/production VLAN.

Cipher suite 0 ("cipher zero"). Suite 0 signals clear-text auth and, on affected BMCs, accepts any password, a full pre-auth bypass, exploited as -C 0. Disclosed by Dan Farmer; tracked across vendors as CVE-2013-4782 / -4783 / -4784 and covered by US-CERT TA13-207A (Tenable, US-CERT TA13-207A). Audit with channel getciphers and disable suite 0 in the BMC's cipher policy.

# Reference template, not hardware-tested: cipher-0 reachability check.
# A user list returned with an empty/garbage password indicates suite 0 is open.
ipmitool -I lanplus -C 0 -H "$BMC" -U '' -P '' user list 1

RAKP hash disclosure (CVE-2013-4786). The IPMI 2.0 RMCP+ key exchange (RAKP) returns an HMAC of a requested user's password in RAKP message 2 before the client authenticates. An unauthenticated attacker can request this for any valid username and crack it offline. It is a flaw in the spec itself: there is no firmware patch; the only mitigations are strong passwords and network isolation (Tenable, CVE-2013-4786).
Default credentials. BMCs ship with well-known factory logins, e.g. Supermicro ADMIN/ADMIN, Dell iDRAC root/calvin, IBM IMM USERID/PASSW0RD (Rapid7). Rotate every BMC credential at commissioning (commissioning and acceptance).

Because RMCP+ encrypts the session payload but cannot fix cipher-0 or the RAKP exposure, these are reasons to move to Redfish (HTTPS/TLS, no RAKP) wherever firmware allows.

Validated usage & tests¶

These checks confirm the OOB path before you depend on it in a provisioning or recovery flow. The output shapes below describe what a healthy BMC returns; specific values are device-dependent, so do not assume the numbers, read them from your hardware.

# 1. Reachability + auth. Expect human-readable lines (System Power, Power Overload, ...).
#    Failure looks like "Error: Unable to establish IPMI v2 / RMCP+ session".
ipmitool -I lanplus -H "$BMC" -U "$USER" -E chassis status

A successful chassis status prints fields including System Power: on|off and the power/fault flags (ipmitool(1)). An RMCP+ session error means wrong credentials, blocked UDP 623, a disabled lanplus/cipher suite, or an unreachable BMC; see the OOB-unreachable runbook.

# 2. Power-state read matches reality (cross-check against the host if it is up).
ipmitool -I lanplus -H "$BMC" -U "$USER" -E chassis power status
# Expected: exactly "Chassis Power is on" or "Chassis Power is off".

# 3. Sensors return readings, not "ns" (no reading) / "na" everywhere.
#    Inlet temp, GPU-board and CPU thermals, fan RPM, and rail voltages should be present.
ipmitool -I lanplus -H "$BMC" -U "$USER" -E sdr list | head

# 4. SEL is readable and being written. Note the entry count from `sel info`,
#    correlate hardware events with host XID/RAS signals.
ipmitool -I lanplus -H "$BMC" -U "$USER" -E sel info
ipmitool -I lanplus -H "$BMC" -U "$USER" -E sel elist | tail

BMC SEL entries (power, thermal, voltage, correctable-memory events) are an out-of-band complement to the in-band GPU error channels; correlate them with host-side XID/ECC triage in reliability and RAS. Health gating before scheduling is covered in GPU health gating.

# 5. Security posture: confirm cipher 0 is NOT in the accepted list.
ipmitool -I lanplus -H "$BMC" -U "$USER" -E channel getciphers ipmi 1
# Expected: suites such as 3 and 17 present; suite 0 absent or administratively disabled.

Failure modes¶

Brief; full procedure in the linked runbook.

Unable to establish IPMI v2 / RMCP+ session. Wrong creds, UDP 623 filtered, lanplus/cipher disabled, or BMC down/hung. Triage in the OOB-unreachable runbook.
chassis power off does not power the node down. off is a soft (ACPI) request a hung host can ignore. Escalate to chassis power cycle/reset, but only after the node is drained (topology-aware scheduling runbook covers draining workloads first).
Stale or empty SEL. A wedged or mis-timed BMC may stop logging or carry a wrong clock; events then misalign with host telemetry. Reconcile against in-band signals in reliability and RAS.
Cipher 0 reachable / default creds. Treat as an active exposure: disable suite 0, rotate credentials, and verify the BMC is only on the OOB network.
BMC reachable but Redfish-only operations needed (structured inventory, firmware update). Use Redfish; ipmitool cannot express them.

References¶

ipmitool(1) manual (Arch): https://man.archlinux.org/man/extra/ipmitool/ipmitool.1.en
OpenStack Ironic — IPMI (ipmitool) driver: https://docs.openstack.org/ironic/latest/admin/drivers/ipmitool.html
Rapid7 — A Penetration Tester's Guide to IPMI and BMCs (cipher 0, RAKP, default creds): https://www.rapid7.com/blog/post/2013/07/02/a-penetration-testers-guide-to-ipmi/
US-CERT TA13-207A — Risks of Using the Intelligent Platform Management Interface (IPMI): https://us-cert.cisa.gov/ncas/alerts/TA13-207A
Tenable — IPMI Cipher Suite Zero Authentication Bypass: https://www.tenable.com/plugins/nessus/68931
NVD — CVE-2013-4786 (IPMI 2.0 RAKP password hash disclosure): https://nvd.nist.gov/vuln/detail/CVE-2013-4786
Tenable — IPMI v2.0 Password Hash Disclosure: https://www.tenable.com/plugins/nessus/80101
HPE — Redfish: a more secure alternative to IPMI (no further IPMI revisions): https://community.hpe.com/t5/servers-systems-the-right/redfish-a-more-secure-alternative-to-ipmi/ba-p/7044568

Related: OOB BMC · Redfish · OOB Network · OOB-Unreachable Runbook · Glossary