BMC Automation in 2026: ipmitool, Redfish API, Prometheus and Grafana for Hardware Monitoring

ipmitool and Redfish API: CLI management of BMC and integration into monitoring

The BMC web interface is convenient for one-off tasks: log in, check the temperature, reboot the server, log out. But as soon as you have more than ten servers, or you need to integrate BMC data into monitoring, or automate firmware updates, the web interface stops working. Nobody is going to click through ten separate pages to reboot a hundred servers after a planned maintenance window. And nobody is going to manually pull CPU temperature from each iDRAC to build a graph in Grafana.

For such scenarios there are two main tools. ipmitool is the classic CLI client for the IPMI protocol, which works with virtually any BMC released in the last twenty years. Redfish API is the modern REST/JSON standard from DMTF that is gradually replacing IPMI in new integrations. In practice in 2026 you should know both: ipmitool for legacy hardware and quick one-liners, Redfish for new automations and monitoring.

1. Why CLI, not the web interface

The web interface and CLI don't compete with each other, they are tools for different tasks.

The web is convenient for manual intervention: when you need to do something on one server once, when you need visual information (graphs, topology), or when you don't know exactly what you need and want to click through menus. The web works well for beginners, for one-off emergency scenarios, for looking at the state of the hardware before making a decision.

CLI and API are needed where the web stops scaling. The classic scenarios:

• Bulk operations. Need to reboot 40 servers after a switch firmware upgrade? Through the web that's 40 logins, 40 clicks, 40 confirmations. Through CLI that's one command in a loop.
• Collecting metrics into monitoring. Prometheus can't click web interfaces. It needs an endpoint from which it will pull metrics for temperature, fan RPM, PSU state every 1-5 minutes (more often for a BMC is usually excessive, because the controller itself responds slowly).
• CI/CD and provisioning. Terraform, Ansible, GitLab CI bring up a new server: PXE-boot, OS installation, RAID configuration. All of this requires programmatic access to the BMC.
• Audit and compliance. Once a month you need to verify that secure boot is enabled on all servers, the latest firmware is installed, default passwords have been changed. Through the web this works in theory, through the API it is reality.
• Emergency diagnostics under full isolation. The BMC web interface sometimes hangs by itself (especially on older Supermicro), and the CLI over SSH or IPMI-over-LAN continues to work.

2. ipmitool: the classic way

2.1 What it is and how it works

ipmitool is an open-source CLI client for the IPMI protocol that has existed since around 2003. Written in C, works on Linux, BSD and macOS, supports IPMI 1.5 and 2.0. Originally developed by Duncan Laurie at Sun Microsystems, later handed over to the community and now maintained on GitHub. Its main advantage is universality: works with almost any server with a BMC, regardless of the vendor.

There are two ways to communicate. From a local Linux host that sits on the server itself, ipmitool talks to the BMC through the KCS interface (Keyboard Controller Style) — this is a bus inside the hardware, access to which does not require a network or a password. From a remote host, ipmitool does IPMI-over-LAN on UDP port 623 with authentication.

2.2 Installation

On Debian/Ubuntu:

sudo apt update
sudo apt install ipmitool

On Rocky Linux / AlmaLinux / RHEL:

sudo dnf install ipmitool

For local mode a kernel driver is also needed. On modern distributions (Rocky Linux 9, Ubuntu 24.04 with kernels 5.x/6.x) it is enough to load one module:

sudo modprobe ipmi_devintf

The main driver ipmi_si is already built-in in modern kernels and is automatically initialized through ACPI/SMBIOS when the system boots. If you are working on an old distribution (RHEL 6, old Debian) or /dev/ipmi0 did not appear after loading ipmi_devintf, additionally try:

sudo modprobe ipmi_si

After this, devices /dev/ipmi0 or /dev/ipmidev/0 will appear. To have the driver loaded automatically at boot, add ipmi_devintf to /etc/modules-load.d/ipmi.conf.

2.3 Connection

Local mode (from the server that is being monitored):

sudo ipmitool sensor list

Here ipmitool talks to the BMC directly via KCS, no authentication is needed.

Remote mode (from another machine over the network):

ipmitool -I lanplus -H 192.0.2.10 -U admin -P password sensor list

Breakdown of the flags: -I lanplus means IPMI 2.0 over LAN with support for payload encryption via RMCP+ (use this, not -I lan, which corresponds to IPMI 1.5 — it has MD5 authentication, but no encryption of the data itself, meaning passwords and commands go over the network in plaintext), -H is the BMC address, -U and -P are the login and password.

2.4 Main commands

Sensors

Full list of all BMC sensors with current values and thresholds:

ipmitool sdr list

Filter by type — only temperatures:

ipmitool sdr type Temperature

Similarly you can filter Fan, Voltage, Power Supply, Current. The output shows sensor name, current value, status: ok (normal), nc (non-critical, warning), cr (critical, critical threshold crossing), nr (non-recoverable, state beyond recovery), ns (non-specified, state not defined).

Hardware event log (SEL)

ipmitool sel list

Outputs the chronology of events: start/stop, temperature threshold triggers, PSU state, ECC memory errors. If the log is full and you need to free up space:

ipmitool sel clear

Before clear it is worth saving the contents to a file (SEL is often a valuable data source for post-mortem analysis).

Power management

# Find out the current state
ipmitool power status

# Power on (equivalent to a short press of the power button)
ipmitool power on

# Graceful shutdown via ACPI (equivalent to a short press)
ipmitool power soft

# Hard power off (equivalent to holding the power button 4+ sec)
ipmitool power off

# Warm reset (equivalent to the physical reset button)
ipmitool power reset

# Power cycle: hard off, wait, on again
ipmitool power cycle

Chassis state

ipmitool chassis status

Shows a summary: whether power is on, whether the front panel button is pressed, whether there is an intrusion-detect (case-open sensor triggered), what caused the last reboot.

Managing the BMC module itself

The mc commands (Management Controller — the BMC itself) manage not the server but the controller itself:

# Information about the BMC: firmware version, vendor
ipmitool mc info

# Reboot the BMC itself (not the server, only the controller)
ipmitool mc reset cold

The mc reset cold command is a lifesaver in the scenario when the BMC web interface hangs, and the server itself is working. The BMC reboots in 1-3 minutes, after which the web interface is available again. At this the main OS on the server notices nothing.

2.5 Limitations of ipmitool

ipmitool does its job well, but it has structural shortcomings that become more and more noticeable over the years:

• Binary protocol. IPMI is not a text format but binary structures that have to be interpreted. Errors in vendor firmware lead to incomprehensible messages.
• Non-standardized extensions. Every vendor added their own OEM commands. The same sensor on Dell and Supermicro can be named differently, have different units of measurement, different thresholds.
• Weak authentication. IPMI 2.0 RAKP protocol has known vulnerabilities (CVE-2013-4786), which remain relevant, because this is a problem of the specification itself. Cipher suite 0 in general allows connecting without a password, if the vendor did not disable it.
• Complex parsing of output data. The output of ipmitool is text styled for a human, not for scripts. To get one number, you have to write regexes or awk parsers.

That is why in 2015 DMTF launched Redfish as a modern replacement.

3. Redfish API: the modern way

3.1 What it is

Redfish is a REST/JSON standard for managing server infrastructure, developed by the DMTF consortium. Instead of binary IPMI packets on UDP port 623, in Redfish there are ordinary HTTPS requests on TCP port 443 with JSON responses. Everything that IPMI can do (sensor state, power management, virtual media, BMC settings) in Redfish is available through ordinary GET/POST/PATCH requests.

The main advantage: unification. The specification describes the hierarchy of resources (/redfish/v1/Systems, /redfish/v1/Chassis, /redfish/v1/Managers) the same way for all vendors. One and the same script with minimal changes works on iDRAC, and on iLO, and on Supermicro BMC.

3.2 Support across generations

Redfish did not appear instantly on all hardware, it is a phased rollout:

• Dell iDRAC 7/8: from firmware 2.40.40.40 (mid-2015), basic Redfish 1.0 support
• Dell iDRAC 9: from firmware 3.00.00.00 (2017), full support
• Dell iDRAC 10: Redfish is the primary API (2024+)
• HPE iLO 4: from firmware 2.30 (2015), basic endpoints
• HPE iLO 5, 6, 7: full support from day one
• Supermicro: X10 from BMC firmware 3.0, X11+ from day one
• ASUS ASMB9, ASMB10-iKVM: full support
• Lenovo XClarity Controller (XCC): Redfish supported from the first release on ThinkSystem SR/SD/SN servers (from 2017)

A simple check from the command line whether Redfish is supported on a specific BMC:

curl -k https://192.0.2.10/redfish/v1/

If a JSON with a description of the service comes back in the response, Redfish works. If 404, you have to check in the web interface whether the service itself is enabled.

3.3 Basic queries

System state

curl -k -u admin:password \
  https://192.0.2.10/redfish/v1/Systems/1 | jq

In the response: model name, serial number, power state (On/Off), CPU count, RAM size, health state (OK/Warning/Critical). The -k key ignores the BMC's self-signed certificate; in production it is better to configure trust for the BMC certificate in the client, rather than disable verification.

Temperatures and sensors

curl -k -u admin:password \
  https://192.0.2.10/redfish/v1/Chassis/1/Thermal | jq

Returns an array of objects for each temperature sensor (CPU, chipset, ambient, disks) with current value, critical and warning threshold, status. Similarly /Chassis/1/Power for power supplies and consumption.

Power management

This is already a POST request with a body:

curl -k -u admin:password -X POST \
  -H "Content-Type: application/json" \
  -d '{"ResetType": "ForceRestart"}' \
  https://192.0.2.10/redfish/v1/Systems/1/Actions/ComputerSystem.Reset

Values for ResetType according to the DMTF specification: On (power on), ForceOff (hard power off), GracefulShutdown (proper shutdown via ACPI), GracefulRestart (proper restart), ForceRestart (hard restart), PowerCycle (power off and on), Nmi (non-maskable interrupt for a kernel state dump). Not all are supported on all BMCs — which ones exactly are available can be found through a GET on /Systems/1, there is an Actions field with the list.

Session authentication

For scripts that make many requests in a row, instead of Basic Auth it is better to use session tokens: one POST to get a token, then all requests with the X-Auth-Token header. This is faster (the BMC does not spend CPU on verifying the password each time) and safer (the password goes over the network only once at login).

# Login
curl -k -X POST -H "Content-Type: application/json" \
  -d '{"UserName":"admin","Password":"password"}' \
  https://192.0.2.10/redfish/v1/SessionService/Sessions \
  -D headers.txt

# The token will be in the X-Auth-Token header in headers.txt
# Then all requests:
curl -k -H "X-Auth-Token: $TOKEN" \
  https://192.0.2.10/redfish/v1/Systems/1

3.4 Comparison of ipmitool vs Redfish

The practical conclusion: ipmitool remains a working tool for quick emergency scenarios and for legacy hardware. Redfish is the choice for new integrations, for CI/CD and for monitoring. For new code in 2026 the starting point is Redfish, ipmitool as a backup where Redfish is not supported.

4. Integration into the monitoring stack

Manual calls of ipmitool and curl work well for diagnostics, but for constant monitoring a different architecture is needed: an exporter collects data from the BMC, Prometheus scrapes it, Grafana visualizes it, Alertmanager sends alerts on threshold crossings.

4.1 Prometheus

ipmi_exporter

The official exporter from Prometheus community (prometheus-community/ipmi_exporter). Written in Go, uses FreeIPMI inside instead of ipmitool, although the working principle is the same. Main metrics: temperatures, fan RPM, PSU state, voltages, consumption. Fits any BMC with IPMI 2.0.

Config ipmi_exporter.yml for remote monitoring of several BMCs:

modules:
  default:
    collectors:
      - bmc
      - ipmi
      - chassis
      - sel
    user: "monitoring"
    pass: "password"  # in production take from ENV or vault
    driver: "LAN_2_0"
    timeout: 20000

The value of timeout is in milliseconds. 20000ms (20 seconds) is a reasonable minimum for modern BMCs; for slower controllers or old hardware it is worth setting 30000ms. Too small a value leads to frequent timeouts in the scrape cycle and fake alerts about unavailability.

Section in prometheus.yml with relabel config:

scrape_configs:
  - job_name: 'ipmi'
    scrape_interval: 60s
    static_configs:
      - targets:
        - 192.0.2.10
        - 192.0.2.11
        - 192.0.2.12
    metrics_path: /ipmi
    params:
      module: [default]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: bmc_host
      - target_label: __address__
        replacement: ipmi-exporter:9290

Key metrics (exact names from the official documentation of prometheus-community/ipmi_exporter): ipmi_temperature_celsius, ipmi_fan_speed_rpm, ipmi_dcmi_power_consumption_current_watts, ipmi_voltage_volts, ipmi_sensor_state (0=nominal, 1=warning, 2=critical, NaN=N/A), ipmi_chassis_power_state (1=on, 0=off), ipmi_up{collector="<NAME>"} (availability of a specific collector).

redfish_exporter

A modern alternative for BMCs with Redfish support. The most popular fork is jenningsloy318/redfish_exporter, which listens on port 9610 (this is the choice of this particular fork; the official Prometheus port allocation reserves 9618 for a different implementation, so when using alternatives check the documentation). Pros compared to ipmi_exporter: works over HTTPS, supports session tokens, does not depend on FreeIPMI, correctly handles OEM extensions for most vendors.

# redfish_exporter.yml
# Note: in production, pass passwords from ENV or vault, not keep them in plaintext
hosts:
  192.0.2.10:
    username: monitoring
    password: password
  192.0.2.11:
    username: monitoring
    password: password
  default:
    username: monitoring
    password: password

The section in prometheus.yml is analogous to ipmi_exporter, only metrics_path: /redfish and replacement: redfish-exporter:9610.

4.2 Zabbix

Zabbix supports IPMI monitoring out of the box. In the management panel you need to enable the IPMI interface for the host, specify the BMC IP, port 623, credentials. Then Zabbix uses built-in templates (Template Module IPMI) with sensor metrics. This is simple, but Zabbix supports only IPMI 1.5/2.0, not Redfish.

For Redfish in Zabbix you need to use an HTTP agent item with manual configuration of URL requests and JSON preprocessing. This is not as elegant as through an exporter, but it works. In Zabbix 6.4+ ready-made community templates for Dell iDRAC and HPE iLO through Redfish have appeared, which make this part simpler.

4.3 Grafana dashboards

Ready-made dashboards with standard visualization can be taken from Grafana.com. A search for "IPMI", "Redfish", "BMC", "Hardware Sensors" gives several popular options with thousands of downloads. The standard set of panels: CPU/chipset temperatures as time-series, fan RPM as a bar chart, heatmap of servers in a rack, table of critical SEL events over the last 24 hours.

4.4 Key metrics for monitoring

Minimum useful set of BMC metrics for production monitoring:

• CPU and motherboard temperature. This is the earliest indicator of cooling problems (dust-clogged radiator, disabled fan, sensor errors)
• RPM of all fans. A sharp drop to zero means mechanical failure, gradual increase at stable load — bearing wear or overheating in the sensor zone
• PSU state. A redundant configuration with two PSUs makes sense only if you see when one of them is disconnected (for example, from its own UPS). Polling can be rare — once every few hours or twice a day, because the PSU state does not change often
• Total consumption in watts. Useful both for capacity planning (how much power to allocate per rack), and for detecting anomalies (a sudden growth can mean gradual hardware degradation)
• ECC memory errors. One correctable error per month is normal; ten per day signals a DIMM that needs to be replaced before it moves to a state of uncorrectable errors
• SEL events at warning and critical level. This is a ready alert: if a critical entry appeared in SEL, look there immediately
• Availability of the BMC itself. Metric ipmi_up{collector="ipmi"} (or analogous for redfish): if the BMC is not responding, it is either a network problem, or the BMC itself needs to be reset

5. Summary: full automation scheme

ipmitool and Redfish are not a question of "either-or", but two tools for different tasks in 2026:

• ipmitool is a quick start: one command, wide compatibility with any BMC from the last 20+ years, a universal tool for emergency scenarios and legacy hardware. If on a new server you need to check CPU temperature or reboot the machine in a minute — ipmitool does it the shortest way.
• Redfish is the future of out-of-band automation: a single API regardless of the vendor, familiar JSON format, HTTPS with TLS 1.2/1.3 instead of outdated RMCP+, ready integration with modern tools (Ansible has native redfish modules, Terraform supports it through providers, Prometheus has an exporter). Everything new is worth doing on Redfish.

The complete working scheme of hardware monitoring looks like this:

• Data source: BMCs of servers (iDRAC / iLO / Supermicro BMC / ASUS ASMB) in a dedicated management network
• Exporter: redfish_exporter for modern hardware, ipmi_exporter as a fallback for old BMCs. Both run next to Prometheus in the monitoring network
• Metric collection: Prometheus scrapes exporters once every 1-5 minutes for typical metrics (temperature, fans, consumption); the frequency depends on how quickly you want to learn about changes and how much load you are ready to give the BMC
• Visualization: Grafana with ready-made dashboards for hardware sensors, separate panels for critical metrics of each rack
• Alerts: Alertmanager reacts to threshold crossings (CPU temperature > 85°C for 5 minutes, ECC errors > 10 per hour, PSU redundancy loss, ipmi_up{collector="ipmi"} == 0), sends to Telegram/Slack and/or PagerDuty for night on-calls
• Automatic actions: for scenarios that can be automated (for example, rebooting a hanging BMC via ipmitool mc reset cold), separate scripts or Ansible playbooks that are launched via a webhook sent by Alertmanager

The result: instead of "I learn about CPU overheating from customer complaints", you have an alert 20 minutes before the CPU starts throttling. Instead of "I don't know how many servers in the rack to check after a power outage", you have a list of those with ipmi_up{collector="ipmi"} == 0. This is what is worth investing time in setting up CLI automation for, even when the BMC web interface formally allows the same thing.

Frequently asked questions