BMC Communication: IPMI, Redfish, and the Modern Hardware Management Stack

title: "BMC Communication: IPMI, Redfish, and the Modern Hardware Management Stack"
meta_description: "A practical guide to BMC communication protocols for enterprise CTOs. Covers IPMI, Redfish, sensor monitoring, and hardware management automation."
url_slug: "/bmc-communication-ipmi-redfish"
primary_keyword: "bmc communication"
secondary_keywords:
- "ipmi redfish"
- "bmc management"
- "hardware management automation"
- "out-of-band management"
author: "Rudy Salo"
date: "2026-04-09"

BMC Communication: IPMI, Redfish, and the Modern Hardware Management Stack

Introduction

If you manage enterprise infrastructure, you've likely encountered the challenge of communicating with Baseboard Management Controllers (BMCs)—the specialized processors embedded in servers that provide out-of-band management capabilities. Whether you're troubleshooting a failed node, gathering hardware telemetry, or automating infrastructure provisioning, understanding BMC communication protocols is essential.

For CTOs and infrastructure leaders, the question isn't whether you'll need to interact with BMCs—it's whether you're using the right protocol for the job. This guide examines IPMI, Redfish, and the practical considerations for modern hardware management.

Understanding BMCs and Their Role in Enterprise Infrastructure

A Baseboard Management Controller is a specialized microcontroller on the server motherboard that provides remote management and monitoring capabilities independent of the main operating system. Think of it as a tiny, always-on computer embedded in every server that can:

• Power on/off or reset the server
• Monitor temperature, voltage, and fan speeds
• Access server consoles via SOL (Serial Over LAN)
• Trigger alerts when hardware thresholds are exceeded
• Provide inventory information (CPU, memory, storage)
• Perform hardware diagnostics and troubleshooting
• Capture and store critical hardware event logs

BMCs have become critical infrastructure components, especially as organizations embracing hybrid cloud architectures and require reliable remote management for distributed server fleets. In modern data centers, BMCs enable:

• **Remote hands operations:** Managing servers without physical access to the data center
• **Infrastructure automation:** Power management integrated with orchestration platforms like Kubernetes, VMware, and cloud management systems
• **Proactive monitoring:** Early detection of hardware failures before they cause production outages
• **Compliance and auditing:** Tracking hardware changes, access events, and configuration modifications
• **Disaster recovery:** Remote rebooting and recovery procedures when systems become unresponsive
• **Green computing:** Power capping and energy management for efficiency initiatives

The BMC is essentially the "firmware immune system" of your server infrastructure—running independently of the operating system, always on, always monitoring, ready to alert you to problems whether the server is powered on, off, or experiencing a critical failure.

IPMI: The Legacy Standard

What is IPMI?

The Intelligent Platform Management Interface (IPMI) emerged in the late 1990s as a vendor-neutral specification for hardware management. It provides a standardized way to interact with BMCs regardless of the server manufacturer—whether Dell, HP, Lenovo, Supermicro, or others, IPMI offers consistent interfaces across the data center.

**Key IPMI capabilities:**

• Remote power control
• Sensor data retrieval (temperature, power, fans)
• Event log access
• Serial console redirection
• User management

IPMI Command Structure

The `ipmitool` command-line utility remains the most common way to interact with IPMI-enabled BMCs:

# Check sensor readings
ipmitool sensor list

# Remote power control
ipmitool -H bmc-hostname -U admin -P password power status
ipmitool -H bmc-hostname -U admin -P password power on/off/reset

# Read event logs
ipmitool sel list

# Configure user accounts
ipmitool user list
ipmitool user set password 2 newpassword

IPMI Security Concerns

IPMI has well-documented security vulnerabilities that modern deployments must address:

**Authentication weaknesses:**

• Default credentials often unchanged
• Passwords transmitted without encryption (unless LANPlus is configured)
• No built-in certificate-based authentication

**Network exposure:**

• UDP port 623 (IPMI) is a frequent attack vector
• Historically vulnerable to amplification attacks
• BMCs frequently misconfigured on public networks

**Recommendation:** If IPMI is required, always enable IPMI over LANPlus (encrypted mode) and isolate BMC networks on dedicated VLANs.

Redfish: The Modern Standard

What is Redfish?

Redfish is a RESTful API standard developed by the Distributed Management Task Force (DMTF) in 2014 specifically to address IPMI's limitations. It provides a modern, secure, programmable interface for hardware management that's optimized for scale and automation.

**Redfish advantages over IPMI:**

• **Modern security:** HTTPS/TLS by default, OAuth support, certificate-based authentication
• **Programmable:** RESTful API works with any HTTP client—curl, Python, Go, infrastructure-as-code tools
• **Scalable:** Designed for managing thousands of servers
• **Human-readable:** JSON responses are easier to debug than binary IPMI output
• **Vendor-extensible:** Standard schema with vendor-specific additions
• **Current:** Actively maintained and evolved

Redfish API Structure

Redfish organizes hardware management into a logical hierarchy:

/redfish/v1/ # Root
├── Systems/ # Physical servers
│ └── {ComputerSystemId}/ # Individual server
│ ├── Processors/ # CPU info
│ ├── Memory/ # RAM info
│ ├── EthernetInterfaces/ # NICs
│ └── LogServices/ # Event logs
├── Managers/ # BMC instances
│ └── {ManagerId}/
│ ├── NetworkProtocols/ # BMC network config
│ └── SerialInterfaces/ # Console access
├── Chassis/ # Enclosures/racks
│ └── {ChassisId}/
│ ├── Power/ # Power supplies, consumption
│ └── Thermal/ # Fans, temperatures
└── SessionService/ # Authentication

Redfish Authentication

Redfish supports multiple authentication methods:

**Basic authentication (for testing):**

curl -k -u admin:password https://bmc-hostname/redfish/v1/Systems/1

**Session-based authentication (recommended for scripts):**

# Create session
SESSION=$(curl -k -X POST https://bmc-hostname/redfish/v1/SessionService/Sessions \
-H "Content-Type: application/json" \
-d '{"UserName":"admin","Password":"password"}' \
-D - | grep -i X-Auth-Token)

# Use session token
curl -k -H "X-Auth-Token: $TOKEN" https://bmc-hostname/redfish/v1/Systems/1

**OAuth 2.0 (enterprise deployments):** Many modern BMCs support integrating with enterprise identity providers.

Practical Redfish Operations

**Get system information:**

curl -k -u admin:password \
https://bmc-hostname/redfish/v1/Systems/1 | jq '.'

**Power operations:**

# Get power state
curl -k -u admin:password \
https://bmc-hostname/redfish/v1/Systems/1 | jq '.PowerState'

# Power off
curl -k -X POST -u admin:password \
https://bmc-hostname/redfish/v1/Systems/1/Actions/ComputerSystem.Reset \
-H "Content-Type: application/json" \
-d '{"ResetType":"ForceOff"}'

**Sensor data:**

curl -k -u admin:password \
https://bmc-hostname/redfish/v1/Chassis/1/Thermal | jq '.Temperatures'

IPMI vs. Redfish: A Decision Framework

When to Use IPMI

IPMI remains appropriate in specific scenarios:

• **Legacy hardware without Redfish support:** Older servers from 2015 or earlier may lack Redfish capability
• **Familiar tooling:** Teams with established ipmitool workflows may prefer to maintain consistency
• **Minimal security requirements:** Air-gapped environments with compensating physical controls
• **Vendor-specific extensions:** Some hardware features only accessible via IPMI

When to Choose Redfish

Redfish should be the default choice for most modern deployments:

• **New infrastructure:** Any server purchased within the last 3-5 years supports Redfish
• **Security-sensitive environments:** PCI-DSS, HIPAA, SOC 2 compliance requirements
• **Automation-first operations:** Integration with Ansible, Terraform, or custom infrastructure tooling
• **Multi-vendor environments:** Consistent API across Dell, HP, Lenovo, Supermicro
• **Cloud-native or hybrid architectures:** REST API integrates naturally with modern platforms

Migration Strategy

For organizations transitioning from IPMI to Redfish:

**Phase 1: Assessment (1-2 weeks)**

1. Inventory all BMC-enabled servers
2. Identify which support Redfish (most Dell iDRAC 8+, HP iLO 5+, Lenovo XCC 2+)
3. Document current IPMI usage patterns
4. Assess automation tooling compatibility

**Phase 2: Pilot (2-4 weeks)**

1. Select representative workload
2. Deploy Redfish tooling (curl scripts, Python redfish library, or vendor tools)
3. Validate functionality matches IPMI equivalents
4. Document operational procedures

**Phase 3: Migration (4-8 weeks)**

1. Roll out to development/test environments
2. Train operations teams
3. Migrate production workloads
4. Decommission IPMI access (disable UDP 623)

**Phase 4: Optimization (ongoing)**

1. Integrate with monitoring/alerting systems
2. Build reusable automation libraries
3. Include Redfish in infrastructure-as-code templates
4. Monitor for vendor Redfish implementation differences

Integrating BMC Communication into Kubernetes Operations

Modern infrastructure increasingly integrates BMC communication with container orchestration platforms.

Bare Metal Kubernetes and BMC Integration

For organizations running Kubernetes on bare metal servers, BMC communication enables:

**Node lifecycle management:**

# Example: Node maintenance workflow
# 1. Cordon node (prevent new pods)
kubectl cordon node-k8s-worker-01

# 2. Drain workloads
kubectl drain node-k8s-worker-01 --ignore-daemonsets --delete-emptydir-data

# 3. Use BMC to boot from maintenance media
curl -X POST -u admin:password \
https://bmc/redfish/v1/Systems/1/Actions/ComputerSystem.SetDefaultBootOrder \
-d '{"BootSource":"PXE"}'

# 4. Power cycle
curl -X POST -u admin:password \
https://bmc/redfish/v1/Systems/1/Actions/ComputerSystem.Reset \
-d '{"ResetType":"ForceRestart"}'

**Health monitoring integration:**

Many organizations integrate BMC sensor data with Prometheus for comprehensive infrastructure monitoring:

# Prometheus node_exporter includes BMC metrics via Redfish
# Additional Redfish-specific exporters available

Hardware Event Handling

BMC event logs can trigger automated responses:

# Example: Redfish event subscription
# Subscribe to hardware events for automated response
response = requests.post(
f'{REDFISH_URL}/EventService/Subscriptions',
json={
'Destination': 'https://your-app.example.com/webhook',
'EventTypes': ['Alert', 'ResourceUpdated'],
'Context': 'kubernetes-operator'
},
auth=(USER, PASS),
verify=False
)

Practical Recommendations

For New Deployments

If you're deploying new infrastructure, Redfish should be your default choice:

• **Require Redfish support** in server procurement specifications
• **Implement from day one** — don't accumulate IPMI technical debt
• **Train teams** on Redfish tooling and automation
• **Integrate with modern monitoring** (Prometheus exporters, Grafana)

For Existing Infrastructure

For legacy systems still on IPMI:

• **Prioritize by risk:** Internet-facing IPMI interfaces are critical vulnerabilities
• **Network isolation:** Place IPMI networks on isolated VLANs
• **Implement compensating controls:** VPN for IPMI access, IP allowlisting
• **Plan migration:** Include Redfish-capable hardware in refresh cycles

Security Best Practices

Regardless of protocol, certain security principles apply universally:

• **Never expose BMCs to the public internet** — this is the #1 security failure leading to breaches
• **Use strong, unique credentials** for each BMC — no shared passwords across infrastructure
• **Enable encryption** (IPMI over LANPlus, always for Redfish)
• **Implement network segmentation** for management interfaces — use dedicated VLANs
• **Regularly update BMC firmware** — monthly updates or per vendor security advisories
• **Monitor access logs** for suspicious activity — set up alerts for unusual patterns
• **Implement least-privilege access** for automation service accounts
• **Conduct quarterly audits** of BMC access, credentials, and configuration
• **Disable unused protocols** — turn off IPMI if using Redfish, disable unused interfaces
• **Implement certificate authentication** where supported for enhanced security

Conclusion

The shift from IPMI to Redfish represents a broader trend in infrastructure management: moving from proprietary, limited protocols to open, programmable, secure APIs. For CTOs and infrastructure leaders, this transition offers significant benefits in automation capability, security posture, and operational efficiency.

The key is to approach it strategically—assessing current usage, planning the migration, and implementing incrementally. Most organizations will find that the investment in Redfish migration pays dividends in reduced complexity, improved security, and more capable automation.

If your organization is navigating infrastructure management modernization and wants guidance on BMC communication strategies, consider scheduling an assessment workshop to evaluate your current state and develop a practical migration roadmap.

---

**Ready to assess your hardware management strategy?**

Schedule a free Assessment Workshop with our team to review your current BMC communication stack, identify optimization opportunities, and develop a practical modernization plan.

[Book Assessment Workshop]