Your Dell PowerEdge server crashed at 2am, and you can't remotely power it back on. The ipmitool command that worked fine for months suddenly returns "Unable to establish IPMI v2 / RMCP+ session". Meanwhile, the iDRAC web interface loads perfectly and shows all the same sensor data.
This isn't a hardware failure. It's the exact scenario that shows why understanding the difference between IPMI and Redfish matters for anyone managing bare metal servers.
The Protocol Confusion
Most sysadmins think of DRAC, iLO, and IPMI as interchangeable terms for "that thing that lets me control servers remotely". In practice, these are distinct layers. Dell's iDRAC and HP's iLO are the physical management controllers, whilst IPMI and Redfish are the protocols they use to communicate.
Here's where it gets interesting: modern iDRAC controllers support both protocols simultaneously. Your monitoring scripts might be using IPMI whilst your orchestration tools use Redfish, often without you realising it.
When IPMI Shows Its Age
IPMI works brilliantly for basic tasks. The ipmitool commands are well-documented, widely supported, and reliable for reading sensors or power cycling servers. But it starts breaking down in three specific scenarios.
First, concurrent access. IPMI struggles when multiple tools try to query the same controller simultaneously. Your monitoring system polls for temperature data every 30 seconds whilst your automation scripts check power status during maintenance windows. The result is intermittent timeouts that look like network issues but aren't.
Second, complex data structures. IPMI's simple request-response model works fine for "get CPU temperature" but becomes unwieldy for detailed system inventory or advanced power management. You end up parsing cryptic output from multiple commands instead of working with structured data.
Third, authentication and security. IPMI's password-based authentication doesn't integrate well with modern identity management systems, and troubleshooting failed authentications often requires diving into controller logs.
Why Redfish Changes the Game
Redfish addresses these problems by design. It's a RESTful API that returns structured JSON, supports proper HTTP authentication methods, and handles concurrent requests gracefully.
The practical difference shows up immediately when you're gathering system information. Instead of parsing the output from ipmitool fru list and ipmitool sdr list, you make a single HTTPS request to /redfish/v1/Systems/ and get back a complete JSON object with everything from BIOS version to memory configuration.
For monitoring tools like Server Scout, this structured approach makes it much easier to collect comprehensive system health data without overwhelming the management controller with multiple simultaneous IPMI sessions.
Making the Switch
The transition from IPMI to Redfish isn't automatic. Even on controllers that support both protocols, many tools default to IPMI because it's what they've always used.
Check your current setup by looking at what your monitoring and automation tools actually use. If you see ipmitool commands in scripts or IPMI-specific configuration options, you're likely still on the legacy protocol regardless of what your hardware supports.
The Redfish specification provides detailed documentation for implementation, though most sysadmins will find existing tools and libraries handle the protocol details.
The Practical Reality
You don't need to migrate everything immediately. IPMI isn't going away, and many simple monitoring tasks work fine with existing tools. But understanding when each protocol makes sense helps avoid those 2am troubleshooting sessions.
If you're already managing out-of-band monitoring for multiple servers, experimenting with Redfish-based approaches during your next maintenance window gives you a clearer picture of what modern management interfaces can offer.