iDRAC vs iLO vs IPMI: Out-of-Band Server Management Guide - 夜莺博客

iDRAC vs iLO vs IPMI: Out-of-Band Server Management Guide

Every time an OS will not boot, a firmware upgrade bricks a NIC, or you need to reinstall a hypervisor in a remote rack, the only path back is out-of-band management. iDRAC, iLO and IPMI get used interchangeably in conversation, but they are three different things: two vendor platforms with web consoles, virtual media and APIs, and one low-level standard that sits underneath both. This guide separates them, covers the licensing and hardening decisions that matter in production, and shows the automation path with Redfish.

The three layers, precisely

iDRAC iLO IPMI
Origin Dell PowerEdge HPE ProLiant Industry standard (Intel et al.)
Nature Full management platform Full management platform Command/protocol to the BMC
Remote KVM HTML5 console HTML5 console OEM dependent, limited
Virtual media Yes (some features licensed) Yes (Advanced licence for full set) Limited
API Redfish / REST, telemetry Redfish / REST, iLO Federation ipmitool, vendor CLIs
Licensing Datacenter licence for telemetry streaming Advanced licence tiers None, but capabilities vary

The practical reading: if you need a graphical console, virtual media, telemetry and a predictable API, compare iDRAC with iLO. IPMI is the fallback that still works when a vendor tool chain is unavailable - and the reason both platforms can be driven by generic tools at all.

Getting in: addresses, credentials, and the really basic checks

# generic IPMI access
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret chassis status
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret power status
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret power cycle
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret sdr list
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret sel list

# Dell
racadm -r 10.0.9.11 -u admin -p secret getsysinfo
racadm -r 10.0.9.11 -u admin -p secret serveraction powercycle
racadm -r 10.0.9.11 -u admin -p secret racadm get iDRAC.NIC

# HPE
ilorest login 10.0.9.12 -u admin -p secret
ilorest chassis
hponcfg -f ilo_reset.xml

Set a dedicated management VLAN for these interfaces, never expose them to the Internet, and lock them to the jump hosts that need access. BMC firmware is a well-known target: it runs continuously, it holds credentials for the host, and it is frequently forgotten during patching cycles.

Redfish: the automation path

curl -sk -u admin:secret https://10.0.9.11/redfish/v1/Systems/System.Embedded.1 | jq '.PowerState, .Model'
curl -sk -u admin:secret https://10.0.9.11/redfish/v1/Systems/System.Embedded.1   -H 'Content-Type: application/json'   -X POST -d '{"ResetType":"On"}'

# HPE
curl -sk -u admin:secret https://10.0.9.12/redfish/v1/Systems/1 | jq '.Oem'
# inventory of NICs and firmware versions
curl -sk -u admin:secret https://10.0.9.12/redfish/v1/Systems/1/NetworkAdapters | jq .

Redfish is the reason to standardise: the same script shape works on Dell, HPE, Lenovo and Supermicro, so power actions and inventory collection can be one code path. Enable the API explicitly, create a service account with only the privileges needed, and rotate its password with your normal secret management.

Hardening and operational habits

# Dell: verify and update firmware from Redfish or racadm
racadm -r 10.0.9.11 -u admin -p secret update -f /tmp/iDRAC.bin
# HPE
ilorest flashfwpkg iLO5_2.90.fwpkg

# always verify the version after flashing
racadm -r 10.0.9.11 -u admin -p secret getversion
ilorest serverinfo --firmware

Do these four things on every fleet: put BMCs on a management VLAN with ACLs; change default credentials and disable unused services (IPMI-over-LAN if unused, telnet, old TLS); monitor the BMC's own syslog for failed logins; and keep BMC firmware in the same patching process as the OS. Also verify the escalation path before you need it - a power cycle through IPMI that fails at 3 a.m. is not the moment to discover the credentials were never tested.

What each layer actually is, in engineering terms

The naming confusion is easier to resolve once you know what is running underneath. Every modern server has a baseboard management controller: a small, permanently powered computer on the motherboard with its own processor, memory, network interface and firmware, wired into the power, sensor and console buses. It runs whether the server is on, off or wedged, and that independence is the entire point.

IPMI is a specification for talking to that controller. It defines a network protocol (IPMI over LAN), a serial protocol, a set of sensors, a system event log, and a fixed command vocabulary for power control and inventory. It was designed in the late 1990s and it shows: the commands are cryptic, the authentication predates modern practice, and the specification forbids nothing vendor-specific, so capability varies wildly between implementations.

iDRAC and iLO are what Dell and HPE built on top of that same controller. Each is a full embedded Linux application with a web interface, an HTML5 console, virtual media mounting, firmware staging, a Redfish API and an event log of its own. They implement IPMI for compatibility and then largely replace it. When someone says "I enabled IPMI on the Dell", they usually mean they enabled the legacy IPMI-over-LAN interface on the iDRAC, not that they installed IPMI on the server.

The practical consequence: Redfish is the modern API for both platforms, IPMI is the lowest common denominator that still works when nothing else does, and vendor tooling (racadm, ilorest) is what gives you the vendor-specific features the standard has no vocabulary for.

The remote recovery workflow, end to end

A bare-metal recovery from a desk five hundred kilometres away follows the same seven steps every time, regardless of vendor.

  1. Reach the management network. VPN or jump host, then confirm the BMC answers on its own address — not the host's address. If the BMC is unreachable, nothing else in this list matters.
  2. Establish the console. HTML5 KVM in the web interface for interactive work; Serial over LAN for scripted or low-bandwidth sessions.
  3. Check power and sensor state before changing anything, so you know whether the box is off, up, or sitting in a POST loop.
  4. Mount virtual media from an ISO on a network share or on your workstation, then set a one-time boot override to that virtual CD or DVD.
  5. Power cycle deliberately — a graceful off then on, not a reset, unless the host is already hung.
  6. Drive the installer or recovery shell through the console, watching the POST output for hardware faults rather than skipping past it.
  7. Eject the virtual media and clear the boot override before you leave. A server that boots from a disconnected virtual CD on the next reboot is a very common own goal.
# generic IPMI path for the same workflow
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret chassis power status
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret sol activate
# OEM virtual media differs per vendor; the Dell and HPE routes are below
racadm -r 10.0.9.11 -u admin -p secret remoteimage -c -l //server/share/boot.iso
ilorest virtualmedia insert --url http://server/boot.iso --bootnext

The iDRAC side: racadm and the HTML5 console

racadm -r 10.0.9.11 -u admin -p secret getsysinfo
racadm -r 10.0.9.11 -u admin -p secret getversion
racadm -r 10.0.9.11 -u admin -p secret getsel                 ! hardware event log
racadm -r 10.0.9.11 -u admin -p secret get iDRAC.NIC
racadm -r 10.0.9.11 -u admin -p secret set iDRAC.IPMILan.Enable 0
racadm -r 10.0.9.11 -u admin -p secret set iDRAC.Telnet.Enable 0
racadm -r 10.0.9.11 -u admin -p secret racreset soft
racadm -r 10.0.9.11 -u admin -p secret -i            ! interactive shell

racadm gives you a local mode through the host operating system (if the Dell OMSA or iDRAC Service Module is installed), a remote mode over the network, and an interactive shell that is genuinely faster than chaining one-shot commands. On PowerEdge generations from the 12th onward, the iDRAC also exposes a full Redfish tree, and the password-reset jumper or a racadm racresetcfg is the recovery path when credentials are lost — though racresetcfg wipes every setting, including the network configuration, so read the warnings before you type it.

The iLO side: ilorest and iLO Federation

ilorest login 10.0.9.12 -u admin -p secret
ilorest serverinfo --firmware
ilorest chassis
ilorest get --select ComputerSystem
ilorest boot --set "BootSourceOverrideTarget=CD"
ilorest power cycle
ilorest logout
hponcfg -f ilo_reset.xml

HPE's equivalent of the interactive shell is hponcfg with an XML script, which is the fastest way to apply the same configuration to a fleet, and iLO Federation, which lets one iLO query and act on groups of peers without logging into each one. The iLO directory integration (Active Directory or LDAP) is also worth setting up, because it removes the shared local account that everybody ends up using and never rotating.

IPMI in the real world: what still works, and what never did

ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret fru
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret sdr list full
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret sel list
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret chassis identify 30
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret sol activate
ipmitool -I lanplus -H 10.0.9.11 -U admin -P secret mc info

Unable to establish LAN session from ipmitool is almost always a cipher-suite or privilege mismatch rather than a network problem. Try -C 3 (or -C 17 for a modern iDRAC) before you start re-checking VLANs, and make sure you are using -I lanplus rather than plain lan. Also read up on the historical RAKP authentication weakness before you leave IPMI-over-LAN enabled on a network you do not fully control; if the vendor's tooling covers your use case, disable it.

Licensing: the details that surprise people

Capability Dell HPE
Basic web console, power control, IPMI iDRAC Express (included) iLO Standard (included)
HTML5 remote console Enterprise Advanced
Virtual media Enterprise Advanced
Telemetry / metric streaming to Redfish Datacenter Advanced Premium
Automated firmware staging and updates Datacenter Advanced Premium

Nothing is more frustrating than building an automation workflow and then discovering, halfway through implementation, that the licence tier on half your fleet does not expose the endpoint you are calling. Inventory the licence tier before you design, not after. Trial licences expire quietly and revert the features, so record the expiry date next to the BMC in your inventory.

Security hardening checklist for the management plane

  1. Separate VLAN, no internet exposure. Management interfaces never carry application traffic, and if a BMC does not need to reach the internet, it does not get a route to it.
  2. Unique credentials or directory-backed accounts. A single fleet-wide password on a component that runs continuously and holds host credentials is the highest-value target in the rack.
  3. Disable what you do not use. IPMI over LAN, telnet, unencrypted HTTP, SNMP v1/v2c and PXE provisioning where it is not needed.
  4. Replace the self-signed certificate. Browser warnings train people to click through, and the vendor certificate is a public key that anyone can reproduce.
  5. Patch the BMC with the same discipline as the OS. BMC firmware is exposed firmware that rarely appears in a vulnerability scan, because scanners usually cannot see it.
  6. Ship the BMC logs somewhere you actually read. Failed logins on a BMC are one of the clearest signs of lateral movement, and the log lives in a system nobody opens.
  7. Test the escalation path. Rehearse a power cycle through IPMI on a spare unit. Discovering at 3 a.m. that the credentials were never verified is not a recovery plan, it is a confession.

Frequently asked questions

Do I need a licence to use the BMC at all? No. Power control, sensor readings, the event log and IPMI work on the free tier. What you lose without a paid tier is the graphical console, virtual media and the richer telemetry endpoints.

Why does Redfish return 404 on an endpoint the documentation lists? Firmware generation. Older iDRAC and iLO releases implement an earlier schema version, and some collections appear only after a firmware update. Check the firmware version first, then the Redfish schema version.

How do I find BMC addresses across a large fleet? The management network's DHCP leases or static IPAM records, a discovery scan restricted to the management VLAN, or the vendor's own configuration tool reading the BMC settings through the host OS.

Why did the BMC lose its settings after a firmware update? Occasionally a firmware or generation change resets network and service configuration. Have out-of-band access (a serial console or a KVM) available before you flash, and keep the network settings in your documentation so you can re-apply them without guessing.

Related guides: resetting an ILOM password, iDRAC Redfish API automation with Python and PowerShell, Cisco UCS firmware auto install and HPE 3PAR controller failure handling.

原文链接:https://servermall.com/blog/idrac-vs-ilo-vs-ipmi-remote-management