Portal | Level: L1: Foundations | Topics: Redfish API, BMC (Baseboard Management Controller), Out-of-Band Management, Server Hardware | Domain: Datacenter & Hardware

Redfish

Why This Matters

Name origin: "Redfish" was chosen by the DMTF (Distributed Management Task Force) as an approachable name for the standard — a deliberate break from the alphabet-soup naming of IPMI, SMASH, and WS-Management. The first Redfish spec (v1.0) was published in August 2015.

Redfish is the DMTF standard that replaces IPMI as the protocol for out-of-band server management. Every major vendor (Dell, HPE, Lenovo, Supermicro) now implements Redfish in their BMCs. If you manage physical servers at any scale — provisioning, monitoring, firmware lifecycle, configuration compliance — Redfish is how modern tooling talks to hardware.

IPMI gave us ipmitool over UDP 623 with no encryption, weak auth, and a binary protocol nobody could extend cleanly. Redfish gives us HTTPS, JSON, token-based auth, and a schema that covers everything IPMI did plus storage, networking, firmware, accounts, and event subscriptions. It is the API-first management plane that infrastructure-as-code workflows need.

This topic owns the Redfish protocol, data model, and operational patterns. Vendor-specific extensions (Dell OEM Redfish, HPE iLO Redfish) are referenced but not exhaustively covered — those belong in their vendor topics.

Scope

• Redfish protocol: REST over HTTPS, JSON payloads, OData conventions
• Data model: Systems, Chassis, Managers, Storage, AccountService, UpdateService, EventService
• Authentication: Basic auth, session tokens, role-based access
• Common operations: power control, inventory, sensors, logs, firmware update, boot override
• Event subscriptions: push-based monitoring via SSE or webhook
• Vendor landscape: what each vendor implements and where they diverge
• Tooling: curl, python-redfish-library, Ansible, vendor CLIs
• IPMI vs Redfish: when each applies, migration patterns

The Mental Model

Redfish models a server as a tree of resources, each with a URI, a JSON representation, and standard HTTP methods:

/redfish/v1/                          ← Service Root
├── /Systems/                         ← Compute nodes (the "server")
│   └── /Systems/System.Embedded.1
│       ├── /Bios                     ← BIOS settings
│       ├── /Memory                   ← DIMMs
│       ├── /Processors               ← CPUs
│       ├── /Storage                  ← RAID controllers and drives
│       ├── /EthernetInterfaces       ← Host NICs
│       └── /LogServices              ← System event logs
├── /Chassis/                         ← Physical enclosure
│   └── /Chassis/System.Embedded.1
│       ├── /Power                    ← PSUs, power consumption
│       ├── /Thermal                  ← Temps, fans
│       └── /Sensors                  ← Individual sensor readings
├── /Managers/                        ← BMC / management controller
│   └── /Managers/iDRAC.Embedded.1
│       ├── /EthernetInterfaces       ← BMC NIC config
│       ├── /LogServices              ← SEL, Lifecycle Log
│       ├── /NetworkProtocol          ← SNMP, SSH, HTTP settings
│       └── /VirtualMedia             ← Remote ISO mount
├── /AccountService/                  ← Users, roles, privileges
├── /UpdateService/                   ← Firmware inventory + update
├── /EventService/                    ← Event subscriptions (webhooks, SSE)
└── /SessionService/                  ← Auth session management

Key insight: Every resource is a URL. Every operation is an HTTP verb. If you can use curl and jq, you can manage any Redfish-compliant server without installing vendor tools.

How Redfish Differs from IPMI

Aspect	IPMI	Redfish
Transport	UDP 623 (RMCP/RMCP+)	HTTPS (TCP 443)
Data format	Binary, fixed-width	JSON
Authentication	RAKP (password hash leaked to any client)	Basic Auth + Session Tokens + TLS
Encryption	Optional (AES-128 in IPMI 2.0)	TLS (mandatory in practice)
Extensibility	Vendor OEM commands (undocumented)	OEM JSON extensions with schemas
Discovery	Broadcast probe	Service root at /redfish/v1/
Eventing	SNMP traps, PET alerts	SSE streams, webhook subscriptions
Schema coverage	Sensors, power, SEL, SOL	Everything IPMI covers + storage, BIOS, NICs, firmware, accounts, boot, virtual media
Scriptability	ipmitool (quirky arg parsing)	Any HTTP client: curl, Python requests, Ansible
Standard body	Intel (largely abandoned)	DMTF (active development)

When IPMI still applies: - Legacy hardware (pre-2017) without Redfish support - Serial-over-LAN (SOL) — Redfish has no direct equivalent for interactive console - Very low-level BMC debugging where raw IPMI commands are needed - Mixed fleets where ipmitool is the lowest common denominator

Redfish Protocol Basics

Service Root

Every Redfish implementation exposes a service root at /redfish/v1/:

curl -sk -u admin:password https://bmc-ip/redfish/v1/ | jq .

The response lists top-level resource collections and the OData service document. This is your starting point for discovery — follow the links, don't hardcode paths.

HTTP Methods

Method	Redfish Use	Example
GET	Read a resource	Get system power state
PATCH	Modify properties	Change BIOS setting, set boot override
POST	Create resource or invoke action	Create user, power cycle, start firmware update
DELETE	Remove resource	Delete user account, remove event subscription

OData Conventions

Gotcha: Redfish chose OData (Open Data Protocol, originally a Microsoft standard for REST APIs) for its JSON conventions. This means you will see @odata.id, @odata.type, and Members@odata.count annotations that look unusual if you are used to plain REST. These are not optional metadata — @odata.id is how you follow links between resources.

Redfish uses OData annotations in JSON. The ones you'll see constantly:

• @odata.id — the canonical URI for a resource (follow these links)
• @odata.type — the schema type (e.g., #ComputerSystem.v1_16_0.ComputerSystem)
• Members — array of links in a collection
• Members@odata.count — total number of members
• Actions — available operations (POST targets)

{
  "@odata.id": "/redfish/v1/Systems/System.Embedded.1",
  "@odata.type": "#ComputerSystem.v1_16_0.ComputerSystem",
  "PowerState": "On",
  "Actions": {
    "#ComputerSystem.Reset": {
      "target": "/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset",
      "ResetType@Redfish.AllowableValues": ["On", "ForceOff", "ForceRestart", "GracefulShutdown", "PushPowerButton"]
    }
  }
}

Authentication

Basic Auth (simple, per-request):

curl -sk -u admin:password https://bmc-ip/redfish/v1/Systems/System.Embedded.1

Session Auth (token-based, better for multiple requests):

# Create session
TOKEN=$(curl -sk -X POST https://bmc-ip/redfish/v1/SessionService/Sessions \
  -H 'Content-Type: application/json' \
  -d '{"UserName": "admin", "Password": "password"}' \
  -D - -o /dev/null | grep -i X-Auth-Token | awk '{print $2}' | tr -d '\r')

# Use token for subsequent requests
curl -sk -H "X-Auth-Token: $TOKEN" https://bmc-ip/redfish/v1/Systems/System.Embedded.1

# Delete session when done
curl -sk -X DELETE -H "X-Auth-Token: $TOKEN" \
  https://bmc-ip/redfish/v1/SessionService/Sessions/<session-id>

Session auth avoids sending credentials with every request and allows the BMC to enforce session limits and timeouts.

Core Operations

Power Control

BMC=10.0.10.5
CREDS="admin:password"

# Check power state
curl -sk -u $CREDS https://$BMC/redfish/v1/Systems/System.Embedded.1 \
  | jq '.PowerState'

# Graceful shutdown
curl -sk -u $CREDS \
  -X POST https://$BMC/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset \
  -H 'Content-Type: application/json' \
  -d '{"ResetType": "GracefulShutdown"}'

# Force restart
curl -sk -u $CREDS \
  -X POST https://$BMC/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset \
  -H 'Content-Type: application/json' \
  -d '{"ResetType": "ForceRestart"}'

# Power on
curl -sk -u $CREDS \
  -X POST https://$BMC/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset \
  -H 'Content-Type: application/json' \
  -d '{"ResetType": "On"}'

ResetType values (check AllowableValues — not all BMCs support all types): - On — power on (only if currently off) - ForceOff — immediate power off (like pulling the plug) - GracefulShutdown — ACPI shutdown signal - ForceRestart — immediate power cycle - PushPowerButton — simulate physical button press

System Inventory

# Basic system info
curl -sk -u $CREDS https://$BMC/redfish/v1/Systems/System.Embedded.1 \
  | jq '{Model, Manufacturer, SerialNumber, BiosVersion, PowerState,
         ProcessorSummary: .ProcessorSummary, MemorySummary: .MemorySummary}'

# CPU details
curl -sk -u $CREDS https://$BMC/redfish/v1/Systems/System.Embedded.1/Processors \
  | jq '.Members[]."@odata.id"'
# Then GET each processor URI for model, cores, speed

# Memory (DIMMs)
curl -sk -u $CREDS https://$BMC/redfish/v1/Systems/System.Embedded.1/Memory \
  | jq '.Members[]."@odata.id"'

# Storage controllers
curl -sk -u $CREDS https://$BMC/redfish/v1/Systems/System.Embedded.1/Storage \
  | jq '.Members[]."@odata.id"'

# Network interfaces
curl -sk -u $CREDS https://$BMC/redfish/v1/Systems/System.Embedded.1/EthernetInterfaces \
  | jq '.Members[]."@odata.id"'

Sensors and Thermal

# Temperatures and fans
curl -sk -u $CREDS https://$BMC/redfish/v1/Chassis/System.Embedded.1/Thermal \
  | jq '{
      Temperatures: [.Temperatures[] | {Name, ReadingCelsius, Status: .Status.Health}],
      Fans: [.Fans[] | {Name, Reading, ReadingUnits, Status: .Status.Health}]
    }'

# Power consumption
curl -sk -u $CREDS https://$BMC/redfish/v1/Chassis/System.Embedded.1/Power \
  | jq '{
      PowerConsumedWatts: .PowerControl[0].PowerConsumedWatts,
      PSUs: [.PowerSupplies[] | {Name, PowerOutputWatts, Status: .Status.Health}]
    }'

System Event Log (SEL)

# List SEL entries
curl -sk -u $CREDS \
  https://$BMC/redfish/v1/Managers/iDRAC.Embedded.1/LogServices/Sel/Entries \
  | jq '.Members[] | {Id, Created, Message, Severity}'

# Filter for errors/warnings only
curl -sk -u $CREDS \
  https://$BMC/redfish/v1/Managers/iDRAC.Embedded.1/LogServices/Sel/Entries \
  | jq '[.Members[] | select(.Severity != "OK")] | sort_by(.Created) | reverse | .[:10]'

# Clear the SEL
curl -sk -u $CREDS \
  -X POST https://$BMC/redfish/v1/Managers/iDRAC.Embedded.1/LogServices/Sel/Actions/LogService.ClearLog

Boot Override

# Set one-time PXE boot
curl -sk -u $CREDS \
  -X PATCH https://$BMC/redfish/v1/Systems/System.Embedded.1 \
  -H 'Content-Type: application/json' \
  -d '{"Boot": {"BootSourceOverrideTarget": "Pxe", "BootSourceOverrideEnabled": "Once"}}'

# Set persistent boot to HDD
curl -sk -u $CREDS \
  -X PATCH https://$BMC/redfish/v1/Systems/System.Embedded.1 \
  -H 'Content-Type: application/json' \
  -d '{"Boot": {"BootSourceOverrideTarget": "Hdd", "BootSourceOverrideEnabled": "Continuous"}}'

# Check current boot settings
curl -sk -u $CREDS https://$BMC/redfish/v1/Systems/System.Embedded.1 \
  | jq '.Boot'

BootSourceOverrideTarget values: None, Pxe, Hdd, Cd, BiosSetup, UefiShell, UefiTarget

User / Account Management

# List accounts
curl -sk -u $CREDS https://$BMC/redfish/v1/AccountService/Accounts \
  | jq '.Members[]."@odata.id"'

# Get account details
curl -sk -u $CREDS https://$BMC/redfish/v1/AccountService/Accounts/2 \
  | jq '{UserName, RoleId, Enabled, Locked}'

# Create a new user
curl -sk -u $CREDS \
  -X POST https://$BMC/redfish/v1/AccountService/Accounts \
  -H 'Content-Type: application/json' \
  -d '{"UserName": "opsuser", "Password": "Str0ngP@ss!", "RoleId": "Operator"}'

# Change password
curl -sk -u $CREDS \
  -X PATCH https://$BMC/redfish/v1/AccountService/Accounts/2 \
  -H 'Content-Type: application/json' \
  -d '{"Password": "NewStr0ngP@ss!"}'

# Disable an account
curl -sk -u $CREDS \
  -X PATCH https://$BMC/redfish/v1/AccountService/Accounts/3 \
  -H 'Content-Type: application/json' \
  -d '{"Enabled": false}'

Standard roles: Administrator, Operator, ReadOnly

Firmware Update

# List firmware inventory
curl -sk -u $CREDS https://$BMC/redfish/v1/UpdateService/FirmwareInventory \
  | jq '.Members[]."@odata.id"'

# Get specific component firmware version
curl -sk -u $CREDS \
  https://$BMC/redfish/v1/UpdateService/FirmwareInventory/Installed-0-25227.5800.3300-1 \
  | jq '{Name, Version, Updateable}'

# Push firmware update (SimpleUpdate)
curl -sk -u $CREDS \
  -X POST https://$BMC/redfish/v1/UpdateService/Actions/UpdateService.SimpleUpdate \
  -H 'Content-Type: application/json' \
  -d '{"ImageURI": "https://firmware-repo.internal/updates/BIOS_FW_PACKAGE.exe",
       "TransferProtocol": "HTTPS"}'

# Check update status via task
curl -sk -u $CREDS https://$BMC/redfish/v1/TaskService/Tasks/<task-id> \
  | jq '{TaskState, TaskStatus, Messages}'

Virtual Media

# Mount an ISO remotely
curl -sk -u $CREDS \
  -X POST https://$BMC/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.InsertMedia \
  -H 'Content-Type: application/json' \
  -d '{"Image": "https://iso-repo.internal/images/rhel9.3-boot.iso"}'

# Check what's mounted
curl -sk -u $CREDS \
  https://$BMC/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD \
  | jq '{Image, Inserted, MediaTypes}'

# Eject
curl -sk -u $CREDS \
  -X POST https://$BMC/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia/CD/Actions/VirtualMedia.EjectMedia

Event Subscriptions

Redfish supports push-based eventing — the BMC sends events to your collector instead of you polling.

Server-Sent Events (SSE)

# Subscribe to SSE stream (stays open, events arrive as they happen)
curl -sk -u $CREDS -N \
  https://$BMC/redfish/v1/SSE?$filter=EventType%20eq%20Alert

Webhook Subscriptions

# Create a webhook subscription
curl -sk -u $CREDS \
  -X POST https://$BMC/redfish/v1/EventService/Subscriptions \
  -H 'Content-Type: application/json' \
  -d '{
    "Destination": "https://alertmanager.internal:9093/api/v1/alerts",
    "Protocol": "Redfish",
    "EventTypes": ["Alert"],
    "Context": "datacenter-east-rack42"
  }'

# List active subscriptions
curl -sk -u $CREDS https://$BMC/redfish/v1/EventService/Subscriptions \
  | jq '.Members[]."@odata.id"'

This replaces IPMI's SNMP trap / PET alert mechanism with something that integrates cleanly with modern alerting stacks.

Vendor Landscape

All major vendors implement the core Redfish schema, but they differ in completeness and OEM extensions.

Vendor	BMC	Redfish Since	OEM Extensions	Notes
Dell	iDRAC9+	14G (2017)	Dell OEM (SCP export/import, LC actions)	Most complete implementation. iDRAC8 has partial Redfish.
HPE	iLO 5+	Gen10 (2017)	HPE OEM (smart storage, active health)	iLO had its own REST API before Redfish existed.
Lenovo	XCC	ThinkSystem (2017)	Lenovo OEM (XCC-specific features)	Solid standard compliance.
Supermicro	BMC	X11+ (2018)	Minimal OEM	Standard Redfish coverage, less OEM polish.

URI Differences

The system ID in the URI varies by vendor:

# Dell
/redfish/v1/Systems/System.Embedded.1

# HPE
/redfish/v1/Systems/1

# Lenovo
/redfish/v1/Systems/1

# Supermicro
/redfish/v1/Systems/1

Rule: Always discover from the service root. Never hardcode system IDs across vendors.

Tooling

curl + jq (universal)

The examples throughout this primer use curl. This is the lowest common denominator — works everywhere, no dependencies.

python-redfish-library (DMTF official)

import redfish

client = redfish.redfish_client(
    base_url="https://10.0.10.5",
    username="admin",
    password="password",
    default_prefix="/redfish/v1"
)
client.login(auth="session")

# Get system info
response = client.get("/redfish/v1/Systems/System.Embedded.1")
print(response.dict["PowerState"])
print(response.dict["Model"])

# Power cycle
client.post(
    "/redfish/v1/Systems/System.Embedded.1/Actions/ComputerSystem.Reset",
    body={"ResetType": "ForceRestart"}
)

client.logout()

Ansible (dellemc.openmanage, community.general.redfish_*)

# Ansible: get system inventory via Redfish
- name: Get system inventory
  community.general.redfish_info:
    baseuri: "{{ bmc_ip }}"
    username: "{{ bmc_user }}"
    password: "{{ bmc_pass }}"
    category: Systems
    command: GetSystemInventory
  register: system_info

# Dell-specific: export server configuration profile
- name: Export SCP
  dellemc.openmanage.idrac_server_config_profile:
    idrac_ip: "{{ bmc_ip }}"
    idrac_user: "{{ bmc_user }}"
    idrac_password: "{{ bmc_pass }}"
    share_name: "/nfs/scp_exports"
    scp_components: ALL
    export_format: JSON
    job_wait: true

Vendor CLIs

• Dell: racadm (wraps iDRAC/Redfish behind a CLI)
• HPE: ilorest (HPE's Redfish CLI tool)
• DMTF: redfishtool (vendor-neutral reference CLI)

Security

Redfish fixes IPMI's worst security problems but introduces its own attack surface.

What Redfish Fixes

• TLS everywhere — no plaintext password hashes on the wire
• No RAKP hash leak — the protocol-level flaw that makes IPMI password cracking trivial does not exist in Redfish
• Proper session management — tokens with expiry, session limits
• Role-based access — granular privileges beyond IPMI's coarse user/operator/admin

What You Still Need to Do

1. Use valid TLS certificates — self-signed certs are the default; deploy proper certs from your internal CA
2. Enforce HTTPS only — disable HTTP (port 80) on the BMC
3. Network isolation — Redfish endpoints on a dedicated management VLAN, just like IPMI
4. Strong passwords — TLS protects the wire but won't help if creds are root:calvin
5. Disable IPMI if possible — if Redfish is your primary interface, disable IPMI-over-LAN to reduce attack surface
6. Monitor authentication failures — Redfish logs auth events; forward them to your SIEM
7. Keep BMC firmware updated — Redfish implementations have their own CVEs
8. Restrict session limits — prevent session exhaustion attacks

IPMI-to-Redfish Migration

Most fleets don't cut over all at once. Common pattern:

Phase 1: Use Redfish for new provisioning (boot override, firmware, accounts)
         Keep ipmitool for SOL, sensor monitoring, legacy hardware
Phase 2: Move monitoring to Redfish (sensors, SEL, power metrics)
         Replace ipmitool in cron jobs and monitoring integrations
Phase 3: Decommission IPMI-over-LAN on Redfish-capable hardware
         SOL stays until Redfish consoles mature or KVM-over-IP suffices

SOL gap: Redfish does not have a direct equivalent to IPMI Serial-over-LAN. Some vendors offer proprietary solutions (Dell has iDRAC virtual console via HTML5), but there is no standardized Redfish console interface yet. This is the main reason ipmitool persists in modern environments.

How to Use This Pack

1. primer.md (this file): Protocol architecture, data model, operations reference, security, migration
2. street_ops.md: Production workflows — the scripts and patterns you actually run
3. footguns.md: Mistakes that break automation, lock out operators, and create security holes

Related Topics

• IPMI and ipmitool: The predecessor protocol — still needed for SOL, legacy hardware, and mixed fleets
• Dell PowerEdge: Dell-specific Redfish extensions (iDRAC OEM, Lifecycle Controller, SCP templates)
• Datacenter OOB and Provisioning: PXE, DHCP, kickstart — the provisioning pipeline that Redfish feeds into
• Bare-Metal Provisioning: Automated server deployment workflows that use Redfish for boot override and firmware prep
• Firmware: BMC and BIOS firmware lifecycle — UpdateService is the Redfish surface for this
• Server Hardware: Physical component diagnostics — Redfish provides the data, this topic provides the interpretation

---

Wiki Navigation

Prerequisites

• IPMI and ipmitool (Topic Pack, L1)

Related Content

• IPMI and ipmitool (Topic Pack, L1) — BMC (Baseboard Management Controller), Hardware Security, Out-of-Band Management
• Datacenter & Server Hardware (Topic Pack, L1) — Firmware / BIOS / UEFI, Out-of-Band Management, Server Hardware
• Dell PowerEdge Servers (Topic Pack, L1) — Firmware / BIOS / UEFI, Out-of-Band Management, Server Hardware
• Bare-Metal Provisioning (Topic Pack, L2) — Out-of-Band Management, Server Hardware
• Case Study: BIOS Settings Reset After CMOS (Case Study, L1) — Firmware / BIOS / UEFI, Server Hardware
• Case Study: BMC Clock Skew Cert Failure (Case Study, L2) — BMC (Baseboard Management Controller), Out-of-Band Management
• Case Study: Firmware Update Boot Loop (Case Study, L2) — Firmware / BIOS / UEFI, Server Hardware
• 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

Pages that link here

• Anti-Primer: Redfish
• BMC Clock Skew - Certificate Failure
• Bare-Metal Provisioning
• Dell PowerEdge Servers
• IPMI and ipmitool
• Incident Replay: BIOS Settings Reverted After CMOS Battery Replacement
• Incident Replay: Firmware Update Causes Boot Loop
• 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