What Is Out-of-Band Monitoring?

What is out-of-band monitoring?

Out-of-band management (OOB) accesses and manages server hardware through a dedicated channel separate from the production network. A Baseboard Management Controller (BMC) on the motherboard provides this channel. Engineers can inspect hardware, diagnose problems and recover a server after an operating system crash or disk failure, and even when the host is switched off, provided the BMC still has power. This makes out-of-band access an important part of business continuity in finance, healthcare, government and other demanding environments.

Out-of-band vs in-band monitoring

In-band monitoring uses the production network and depends on the operating system and network stack. It can lose access after an OS crash, network driver failure or severe overload. A BMC has its own network interface, processor, memory and firmware. It can remain available when the host is unresponsive, allowing hardware diagnostics, power cycling, ISO mounting and access to the boot console. Use both approaches: in-band monitoring for system and application metrics during normal operation, and out-of-band access for hardware visibility and recovery.

• Independent channel: the BMC uses a management interface separate from the host system.
• Continued access: hardware monitoring remains available after an OS or disk failure while the BMC is powered.
• Remote control: KVM over IP, virtual media and remote power management.
• Early warning: identify abnormal hardware readings and support preventive maintenance.

IPMI vs Redfish

IPMI (Intelligent Platform Management Interface), introduced in 1998, uses a binary protocol and UDP port 623. IPMI 1.5 and 2.0 differ significantly in authentication and encryption, and legacy implementations require particular care. Redfish, introduced by DMTF in 2015, uses HTTPS and JSON REST APIs, making integration and automation more straightforward. Prefer Redfish for new deployments where supported; DCOS also supports existing IPMI infrastructure.

• Architecture: IPMI uses binary messages over UDP 623; Redfish uses HTTPS and JSON.
• Security: use encrypted management interfaces and disable obsolete authentication modes.
• Programmability: IPMI requires specialized tools; Redfish APIs can be called with curl or Postman.
• Extensibility: Redfish supports resource discovery through its data model.
• Vendor support: Dell iDRAC, HPE iLO, Lenovo XCC and Huawei iBMC support management protocols depending on model and firmware.

Monitoring capabilities

Modern BMCs provide temperature, voltage, fan speed and power supply readings through supported IPMI or Redfish interfaces. Remote access can include graphical KVM, virtual ISO media and Serial over LAN. Power controls cover startup, shutdown and reset. Supported devices also expose BIOS, BMC and RAID firmware management, plus asset details such as serial numbers, model identifiers, MAC addresses and asset tags. Together, these functions support remote incident response.

Deployment steps

Start with network planning: allocate a dedicated management VLAN isolated from production traffic. A small deployment may use a management segment with 10–50 addresses. Configure BMC addressing, administrator accounts and strong passwords, and disable obsolete protocols. Import management addresses into DCOS and set collection intervals and alert thresholds. Finally, verify power operations, KVM access and supported firmware workflows before establishing operating procedures and an emergency recovery plan.

• Network planning: dedicated VLAN and an appropriately sized address range.
• BMC configuration: static IP or DHCP, strong credentials and encrypted protocols.
• Collection: import devices and configure polling and alert parameters.
• Verification: test power management, KVM and supported firmware operations.

Security best practices

A compromised BMC can give an attacker extensive control of a server. Disable IPMI 1.5 and use supported secure management protocols. Use strong passwords, with at least 12 characters as a starting point, and rotate credentials according to policy. Isolate management networks, restrict source addresses, enable audit logs, watch for unusual login attempts and keep BMC firmware updated. Consider mutual authentication where supported.

Frequently asked questions

Can IPMI and Redfish run together? Many Dell, HPE and other enterprise servers support both. How much bandwidth is needed? The source article estimates 1–5 MB per minute for routine monitoring and 2–5 Mbps for KVM sessions; actual needs depend on polling and display settings. Does the BMC affect host performance? It runs independently, so its direct impact is generally small. Does every server include one? Most enterprise servers do, but some entry-level or white-box systems need additional hardware. What about KVM latency? The article gives a typical 50–200 ms range on a suitable network, sufficient for routine administration.

References

The original article references DMTF Redfish specifications, NVIDIA IPMI documentation and BMC management documentation from Dell EMC, HPE and Lenovo.