Portal | Level: L1: Foundations | Topics: IPMI / ipmitool, BMC (Baseboard Management Controller), Out-of-Band Management, Server Hardware | Domain: Datacenter & Hardware
IPMI and ipmitool¶
Why This Matters¶
Timeline: IPMI v1.0 was published by Intel in 1998. IPMI v2.0 (with RMCP+ encryption) followed in 2004. Intel effectively abandoned IPMI development after v2.0, and the DMTF's Redfish standard (2015) is its intended successor. Despite being "legacy," IPMI remains on virtually every server shipped today.
IPMI (Intelligent Platform Management Interface) is the vendor-neutral protocol that lets you manage servers when the OS is dead, the network is misconfigured, or the machine won't boot. Every BMC speaks IPMI. Every datacenter operator uses ipmitool. When you understand IPMI at the protocol level -- not just as "that thing iDRAC uses" -- you can troubleshoot any server from any vendor without reaching for a vendor-specific GUI.
This topic owns the protocol, the CLI, and the hardware management plane. Vendor-specific tools (iDRAC/RACADM, iLO, Redfish) are covered in their own topics. Provisioning workflows (PXE, kickstart) live in the OOB and Provisioning topic.
Scope¶
- IPMI protocol: Architecture, message types, transport, authentication
- ipmitool CLI: The universal interface to any BMC
- Sensor Data Repository (SDR): How sensors work, thresholds, reading them
- System Event Log (SEL): Hardware event history, interpretation, lifecycle
- Serial-over-LAN (SOL): Remote console via IPMI
- BMC management: Network config, users, firmware, cold reset
- Linux IPMI kernel interface: In-band access via kernel modules
- Security: Protocol vulnerabilities, hardening, credential management
The Mental Model¶
Every modern server has two independent computers sharing one chassis:
┌─────────────────────────────────────────────┐
│ Main System │
│ ┌───────┐ ┌───────┐ ┌──────┐ ┌──────┐ │
│ │ CPU │ │ RAM │ │ NIC │ │ Disk │ │
│ └───┬───┘ └───┬───┘ └──┬───┘ └──┬───┘ │
│ │ │ │ │ │
│ ════╪══════════╪═════════╪═════════╪═══ │
│ │ System Bus / PCIe │ │
│ ════╪══════════════════════════════════ │
│ │ │
│ ┌───┴──────────────────────────────────┐ │
│ │ BMC (Baseboard Management Controller)│ │
│ │ - Own CPU (ARM) │ │
│ │ - Own RAM (256MB-1GB) │ │
│ │ - Own NIC (dedicated or shared) │ │
│ │ - Own flash (firmware, config, SEL) │ │
│ │ - Always on (standby power) │ │
│ └───────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
The BMC runs its own OS (typically Linux-based), has its own IP address, and is always powered on as long as the server has AC power -- even when the main system is completely off. It communicates with the main system over IPMB (a low-speed I2C/SMBus) and with operators over the network via IPMI-over-LAN.
IPMI vs Vendor Names¶
IPMI is the protocol. Vendors build products on top of it:
| Vendor | BMC Product | Extras Beyond IPMI |
|---|---|---|
| Dell | iDRAC (6/7/8/9) | Lifecycle Controller, RACADM, virtual console |
| HP/HPE | iLO (2/3/4/5/6) | Active Health System, Federation, virtual media |
| Supermicro | IPMI BMC | Web UI, basic virtual media |
| Lenovo | XClarity / IMM | REST API, firmware management |
| Generic / whitebox | IPMI BMC | Minimal — ipmitool is your primary interface |
All of them speak IPMI. ipmitool works with all of them. The vendor UIs add features on top, but IPMI is the common denominator.
IPMI Protocol Architecture¶
Layers¶
Application (ipmitool commands)
│
▼
IPMI Message Layer (NetFn + Cmd + Data)
│
▼
Session Layer (authentication, encryption)
│
▼
Transport (RMCP / RMCP+ over UDP 623)
│
▼
Network (IP to BMC interface)
Transport: RMCP and RMCP+¶
IPMI messages travel over RMCP (Remote Management Control Protocol) on UDP port 623.
- IPMI 1.5: RMCP with basic authentication (MD5/MD2/none). Passwords sent in weak hashes.
- IPMI 2.0: RMCP+ with RAKP (Remote Authenticated Key Exchange Protocol). Supports AES-128-CBC encryption and HMAC-SHA1/SHA256 integrity. This is what
lanplusmeans in ipmitool.
# IPMI 1.5 (insecure, legacy)
ipmitool -I lan -H <bmc-ip> -U admin -P pass power status
# IPMI 2.0 (use this — always)
ipmitool -I lanplus -H <bmc-ip> -U admin -P pass power status
Message Structure¶
Every IPMI command has: - NetFn (Network Function): Category of command (Chassis, Sensor, App, Storage, etc.) - Command: Specific operation within the NetFn - Data: Command-specific payload
You don't usually think about this unless you're debugging raw IPMI traffic, but it explains why ipmitool subcommands are grouped the way they are (chassis, sensor, sel, etc.).
Interfaces¶
ipmitool supports multiple transport interfaces:
| Interface | Flag | When to Use |
|---|---|---|
lanplus |
-I lanplus |
Remote access over network (IPMI 2.0) |
lan |
-I lan |
Remote access (IPMI 1.5 — avoid) |
open |
-I open |
Local access via /dev/ipmi0 kernel driver |
ipmb |
-I ipmb |
Direct bus access (rare, embedded systems) |
Linux IPMI Kernel Interface¶
When you run ipmitool locally (without -H), it talks to the BMC through the kernel's IPMI device driver, not over the network.
Kernel Modules¶
# Load the IPMI driver stack
modprobe ipmi_devintf # creates /dev/ipmi0
modprobe ipmi_si # system interface driver (KCS, SMIC, or BT)
# Verify it loaded
lsmod | grep ipmi
# ipmi_devintf 20480 0
# ipmi_si 57344 0
# ipmi_msghandler 53248 2 ipmi_devintf,ipmi_si
# Check the device exists
ls -l /dev/ipmi0
# crw-------. 1 root root 238, 0 Mar 14 10:00 /dev/ipmi0
# If modules don't load, check BIOS
# Some systems need "IPMI over KCS" enabled in BIOS/UEFI settings
dmesg | grep -i ipmi
# ipmi_si: Adding KCS-specified kcs state machine
# ipmi_si: Trying KCS-specified kcs state machine at i/o address 0xca2
System Interface Types¶
The BMC connects to the host CPU through one of these interfaces:
- KCS (Keyboard Controller Style): Most common. Uses I/O ports. Slow but universal.
- SMIC (Server Management Interface Chip): Older, rarely seen.
- BT (Block Transfer): Faster than KCS, supports larger messages. Used by newer systems.
The ipmi_si driver auto-detects which interface is available.
In-Band vs Over-LAN¶
# In-band (local, no network, uses /dev/ipmi0)
ipmitool sensor list
ipmitool sel elist
# Over-LAN (remote, uses UDP 623)
ipmitool -I lanplus -H 10.0.10.5 -U admin -P secret sensor list
In-band is faster and doesn't require BMC network connectivity. Use it when you're already SSH'd into the server. Over-LAN is for when the OS is unreachable.
Sensor Data Repository (SDR)¶
The BMC maintains a database of all sensors on the platform: temperature probes, fan tachometers, voltage regulators, power supplies, intrusion switches, and more.
Sensor Types¶
| Type | What It Monitors | Typical Readings |
|---|---|---|
| Temperature | CPU, inlet, exhaust, DIMM | Degrees C |
| Fan | Fan RPM | RPM (0 = dead fan) |
| Voltage | CPU Vcore, 3.3V, 5V, 12V rails | Volts |
| Power Supply | PSU presence, status, wattage | Watts, discrete states |
| Current | System current draw | Amps |
| Intrusion | Chassis cover open/closed | Discrete (open/closed) |
| Processor | CPU presence, thermal trip | Discrete states |
| Memory | DIMM ECC errors, presence | Discrete states |
Sensor Thresholds¶
Each analog sensor has up to six thresholds:
┌── Upper Non-Recoverable (UNR)
│ ┌── Upper Critical (UC)
│ │ ┌── Upper Non-Critical (UNC)
│ │ │
Reading ────┤ │ │ Normal operating range
│ │ │
│ │ └── Lower Non-Critical (LNC)
│ └── Lower Critical (LC)
└── Lower Non-Recoverable (LNR)
When a reading crosses a threshold, the BMC logs an event to the SEL and (if configured) sends an SNMP trap or PET alert.
# View sensor thresholds
ipmitool sensor get "Inlet Temp"
# Sensor ID : Inlet Temp (0x4)
# Entity ID : 64.1
# Sensor Type (Analog) : Temperature
# Sensor Reading : 23 (+/- 0) degrees C
# Status : ok
# Lower Non-Recoverable : na
# Lower Critical : 3.000
# Lower Non-Critical : 8.000
# Upper Non-Critical : 42.000
# Upper Critical : 47.000
# Upper Non-Recoverable : na
# Set a threshold (use with caution)
ipmitool sensor thresh "Inlet Temp" upper 40 45 50
# Sets UNC=40, UC=45, UNR=50
SDR vs Sensor List¶
# sdr list — compact, shows reading + status
ipmitool sdr list
# Inlet Temp | 23 degrees C | ok
# Exhaust Temp | 35 degrees C | ok
# Fan1 | 8400 RPM | ok
# sensor list — verbose, shows thresholds + units
ipmitool sensor list
# Inlet Temp | 23.000 | degrees C | ok | na | 3.0 | 8.0 | 42.0 | 47.0 | na
# sdr type — filter by sensor type
ipmitool sdr type Temperature
ipmitool sdr type Fan
ipmitool sdr type "Power Supply"
System Event Log (SEL)¶
The SEL is a circular buffer in the BMC's non-volatile storage that records hardware events: threshold crossings, discrete state changes, boot events, and errors.
Reading the SEL¶
# List events (human-readable)
ipmitool sel elist
# 1 | 03/14/2024 | 10:15:33 | Temperature #0x04 | Upper Critical going high | Asserted
# 2 | 03/14/2024 | 10:15:33 | Fan #0x30 | State Deasserted | Predictive Failure Asserted
# 3 | 03/14/2024 | 10:20:01 | Power Supply #0x51 | Failure detected | Asserted
# SEL info (capacity, usage)
ipmitool sel info
# Version : 1.5
# Entries : 47
# Free Space : 8832 bytes
# Last Add Time : 03/14/2024 10:20:01
# Export before clearing (always do this)
ipmitool sel elist > /var/log/sel-$(hostname)-$(date +%F).log
# Clear the SEL (frees space — SEL is finite)
ipmitool sel clear
SEL Capacity¶
The SEL is small — typically 512 to 2048 entries. When full, behavior depends on the BMC: - Some drop new events (you lose recent data) - Some overwrite oldest events (you lose historical data) - Some stop logging entirely
Rule: Export and clear the SEL regularly. Set up automated collection via cron or monitoring.
Interpreting SEL Events¶
Common patterns and what they mean:
| SEL Event | Likely Cause | Action |
|---|---|---|
| Temperature Upper Critical | Cooling failure, blocked airflow | Check fans, ambient temp, airflow |
| Fan Predictive Failure | Fan bearing wearing out | Schedule fan replacement |
| Power Supply Failure | PSU hardware failure or AC loss | Check PDU, replace PSU |
| Memory Correctable ECC | DIMM degrading | Monitor frequency, plan replacement |
| Memory Uncorrectable ECC | DIMM failure | Replace DIMM immediately |
| Processor Thermal Trip | CPU overheating, fan failure | Emergency — check cooling |
| Drive Fault | Disk hardware failure | Replace drive, check RAID |
| Chassis Intrusion | Cover opened | Verify authorized maintenance |
Serial-over-LAN (SOL)¶
SOL redirects the server's serial console output through the BMC to your terminal. It's your eyes on the screen when the server is 2,000 miles away.
End-to-End Setup¶
For SOL to work, four things must be configured:
1. BMC SOL must be enabled:
ipmitool sol set enabled true 1
ipmitool sol set volatile-bit-rate 115.2 1
ipmitool sol set non-volatile-bit-rate 115.2 1
2. BIOS must redirect console to serial port: - In BIOS/UEFI setup: Console Redirection → Serial Port → COM1/COM2 - Redirection type: VT100/VT-UTF8
3. GRUB must output to serial:
# /etc/default/grub
GRUB_TERMINAL="serial console"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8"
# Regenerate GRUB config
grub2-mkconfig -o /boot/grub2/grub.cfg # RHEL/CentOS
update-grub # Debian/Ubuntu
4. Login prompt on serial:
# systemd (most modern distros)
systemctl enable serial-getty@ttyS0.service
systemctl start serial-getty@ttyS0.service
Using SOL¶
# Connect
ipmitool -I lanplus -H 10.0.10.5 -U admin -P secret sol activate
# You now see the server's serial console.
# Kernel boot messages, GRUB menu, login prompt — all visible.
# Disconnect
# Type: ~.
# If connected through SSH: ~~. (escape the SSH escape)
# If SOL session is stuck/stale, deactivate first
ipmitool -I lanplus -H 10.0.10.5 -U admin -P secret sol deactivate
ipmitool -I lanplus -H 10.0.10.5 -U admin -P secret sol activate
SOL vs KVM-over-IP¶
| Feature | SOL | KVM-over-IP |
|---|---|---|
| Output | Text only | Graphical (full screen) |
| Bandwidth | Very low (serial) | High (video stream) |
| Scriptable | Yes (expect, screen) |
No |
| Licensing | Always free | Sometimes requires license (iLO) |
| Boot visibility | POST, GRUB, kernel panic | POST, GRUB, kernel panic, GUI |
| Reliability | Very high | Sometimes needs Java/HTML5 plugin |
Use SOL when: you need to see boot output, capture kernel panics in a log, or automate console interactions. Use KVM when: you need to interact with a graphical installer or BIOS setup screens.
BMC User Management¶
# List users
ipmitool user list 1
# ID Name Callin Link Auth IPMI Msg Channel Priv Limit
# 1 false false false Unknown (0x00)
# 2 admin false false true ADMINISTRATOR
# Create a user (ID 3)
ipmitool user set name 3 opsuser
ipmitool user set password 3
# (prompts for password interactively)
# Set privilege level
# 1=Callback, 2=User, 3=Operator, 4=Administrator
ipmitool channel setaccess 1 3 callin=on link=on ipmi=on privilege=4
# Enable the user
ipmitool user enable 3
# Disable a user (e.g., disable default user after creating a replacement)
ipmitool user disable 2
BMC Network Configuration¶
# View current BMC network config
ipmitool lan print 1
# IP Address Source : Static Address
# IP Address : 10.0.10.5
# Subnet Mask : 255.255.255.0
# Default Gateway IP : 10.0.10.1
# MAC Address : 00:11:22:33:44:55
# Set static IP
ipmitool lan set 1 ipsrc static
ipmitool lan set 1 ipaddr 10.0.10.5
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr 10.0.10.1
# Set to DHCP
ipmitool lan set 1 ipsrc dhcp
# Set VLAN (management VLAN)
ipmitool lan set 1 vlan id 100
# Disable VLAN tagging
ipmitool lan set 1 vlan id off
BMC Cold Reset and Recovery¶
# Soft reset the BMC (restarts BMC firmware, does not affect host)
ipmitool mc reset cold
# BMC firmware info
ipmitool mc info
# Device ID : 32
# Firmware Revision : 2.82
# IPMI Version : 2.0
# Manufacturer ID : 10876 (Dell)
# BMC self-test
ipmitool mc selftest
# Selftest: passed
# Watchdog timer (BMC auto-reboots host if OS stops responding)
ipmitool mc watchdog get
ipmitool mc watchdog off # disable
When Cold Reset is Needed¶
- BMC web UI is unresponsive but IPMI still works
- Sensor readings are stale or wrong
- SOL sessions won't connect
- After BMC firmware update (some require it)
When Cold Reset Won't Help¶
- BMC is completely unresponsive (no IPMI reply)
- BMC NIC is physically down
- In these cases: AC power cycle (pull and reseat power cables, wait 30 seconds)
IPMI Security¶
Known Vulnerabilities¶
War story: The RAKP hash leak vulnerability is so fundamental to the IPMI 2.0 protocol that it cannot be patched — it is how the authentication handshake works by design. HD Moore (Metasploit creator) and Dan Farmer published extensive research on this in 2013, estimating that over 230,000 IPMI-enabled BMCs were directly exposed to the internet. Network isolation is the only mitigation.
RAKP Authentication Bypass (CVE-2013-4786): IPMI 2.0's RAKP handshake returns a salted hash of the password to any unauthenticated client. An attacker can request this hash and crack it offline.
# An attacker does this:
# 1. Send RMCP+ Open Session Request (no auth needed)
# 2. Receive session ID
# 3. Send RAKP Message 1 with target username
# 4. Receive RAKP Message 2 containing HMAC(password) — crackable offline
# Metasploit module: auxiliary/scanner/ipmi/ipmi_dumphashes
# Hashcat mode: 7300 (IPMI2 RAKP HMAC-SHA1)
This is a protocol design flaw — it cannot be patched. It can only be mitigated by network isolation.
Cipher Suite 0 (no authentication): Some BMCs accept cipher suite 0, which means no authentication at all.
# Check if cipher 0 is enabled (should return error, not success)
ipmitool -I lanplus -H 10.0.10.5 -C 0 -U "" -P "" chassis status
# If this works, your BMC is wide open
# Disable cipher 0 (vendor-specific commands)
# Dell: racadm set iDRAC.IPMILan.CipherSuiteSelections 1,2,3,6,7,8,11,12
Hardening Checklist¶
- Isolate on dedicated management VLAN — no user/workload access to BMC network
- Change default credentials — automate during provisioning, never leave root/calvin
- Disable IPMI 1.5 (lan interface) — force lanplus (IPMI 2.0) only
- Disable cipher suite 0 — verify with the test above
- Use strong passwords — RAKP makes password cracking feasible, so use 16+ char passwords
- Restrict access via ACLs — limit source IPs that can reach UDP 623
- Keep BMC firmware updated — BMC CVEs are frequent and often critical
- Monitor BMC access — log authentication events, alert on failures
- Disable unused services — turn off web UI, SNMP, SSH on BMC if not needed
- Consider Redfish — modern replacement with TLS, token auth, and proper API design
Credential Rotation at Scale¶
For fleets of servers, manual credential rotation is impossible. Approaches:
# Script pattern: rotate BMC password across fleet
for bmc in $(cat bmc_inventory.txt); do
ipmitool -I lanplus -H "$bmc" -U admin -P oldpass \
user set password 2 "$(vault read -field=password secret/bmc/new)"
done
# Better: use Redfish API (supports TLS, token auth)
curl -k -u admin:oldpass \
-X PATCH https://$bmc/redfish/v1/AccountService/Accounts/2 \
-H "Content-Type: application/json" \
-d '{"Password": "newpass"}'
# Best: configuration management (Ansible, Puppet)
# ansible-playbook -i bmc_inventory rotate_bmc_creds.yml
IPMI and Monitoring Integration¶
Collecting IPMI Data¶
# Prometheus: use ipmi_exporter
# Exposes sensor readings, SEL events, power consumption as Prometheus metrics
# Nagios/Icinga: check_ipmi_sensor plugin
check_ipmi_sensor -H 10.0.10.5 -U monitor -P pass -T temperature
# Zabbix: built-in IPMI monitoring
# Configure IPMI interfaces per host in Zabbix UI
# Custom: cron + ipmitool + push to TSDB
*/5 * * * * ipmitool -I lanplus -H $BMC -U mon -P pass sdr list \
| parse_and_push_to_influxdb.sh
DCMI (Data Center Management Interface)¶
DCMI extends IPMI for datacenter power management:
# Read system power consumption
ipmitool dcmi power reading
# Instantaneous power reading: 287 Watts
# Minimum during sampling period: 245 Watts
# Maximum during sampling period: 342 Watts
# Average power reading over sample period: 278 Watts
# Set power cap (limit maximum power draw)
ipmitool dcmi power set_limit action 1 limit 350
ipmitool dcmi power activate
# Get power cap
ipmitool dcmi power get_limit
Multivendor Notes¶
Supermicro¶
- Default creds: ADMIN/ADMIN
- Web UI on port 80/443
ipmitoolis the primary CLI — no vendor CLI like RACADM- Fan speed control:
ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x64(raw commands, poorly documented) - BMC firmware updates via web UI or
socflashtool
Dell (iDRAC)¶
- Default creds: root/calvin
racadmCLI alongsideipmitool- Lifecycle Controller for firmware and config
- Virtual console via iDRAC web UI (HTML5 on iDRAC9+)
ipmitoolworks for all standard IPMI operations
HP/HPE (iLO)¶
- Default creds: Administrator/
hponcfgfor local BMC config- iLO has its own REST API (predates Redfish)
- Some features require iLO Advanced license
ipmitoolworks for standard IPMI; advanced features need iLO CLI/API
Lenovo (XClarity/IMM)¶
- Default creds: USERID/PASSW0RD
- XClarity Controller (XCC) on ThinkSystem
- REST API + web UI
ipmitoolworks for standard operations
How to Use This Pack¶
- primer.md (this file): Protocol architecture, component model, security context
- street_ops.md: The commands and workflows you use in production
- footguns.md: Mistakes that brick BMCs, lock out operators, and miss critical events
Related Topics¶
- Redfish: The modern REST-based replacement for IPMI — TLS, JSON, richer data model. Start here for new automation.
- Datacenter OOB and Provisioning: PXE, DHCP, kickstart — the provisioning pipeline that IPMI feeds into
- Server Hardware: Physical component diagnostics (DIMM, NIC, disk) — uses ipmitool for sensor data
- Dell PowerEdge: Dell-specific tooling (iDRAC, RACADM, Lifecycle Controller)
- Firmware: BIOS/UEFI, BMC firmware lifecycle, update workflows
Wiki Navigation¶
Prerequisites¶
- Datacenter & Server Hardware (Topic Pack, L1)
Next Steps¶
- Redfish API (Topic Pack, L1)
Related Content¶
- Redfish API (Topic Pack, L1) — BMC (Baseboard Management Controller), Hardware Security, Out-of-Band Management
- Bare-Metal Provisioning (Topic Pack, L2) — Out-of-Band Management, Server Hardware
- Case Study: BMC Clock Skew Cert Failure (Case Study, L2) — BMC (Baseboard Management Controller), Out-of-Band Management
- Case Study: Serial Console Garbled (Case Study, L1) — Out-of-Band Management, Server Hardware
- Case Study: Server Remote Console Lag (Case Study, L1) — Out-of-Band Management, Server Hardware
- Case Study: iDRAC Unreachable OS Up (Case Study, L1) — BMC (Baseboard Management Controller), Out-of-Band Management
- Datacenter & Server Hardware (Topic Pack, L1) — Out-of-Band Management, Server Hardware
- Deep Dive: Dell Linux PowerEdge (deep_dive, L2) — Out-of-Band Management, Server Hardware
- Dell PowerEdge Servers (Topic Pack, L1) — Out-of-Band Management, Server Hardware
- Skillcheck: Datacenter (Assessment, L1) — Out-of-Band Management, Server Hardware
Pages that link here¶
- Anti-Primer: IPMI And Ipmitool
- Datacenter Skillcheck
- Dell PowerEdge Servers
- Dell PowerEdge on Linux - Deep Dive Guide
- IPMI and ipmitool
- Incident Replay: BMC Clock Skew Causes Certificate Failure
- Incident Replay: Serial Console Output Garbled
- Incident Replay: iDRAC Unreachable but OS Running
- Master Curriculum: 40 Weeks
- Redfish API
- Remote KVM/Console Extremely Laggy
- Serial-over-LAN Output Garbled
- iDRAC Unreachable, OS Up