Out-of-Band Management

In-band and out-of-band

Normally you manage a server in-band: you connect over SSH or Remote Desktop to its operating system, through the same network that carries its production traffic. That works until it doesn't. At 03:00 a database server stops responding: the operating system has hung, or a kernel update left it stuck at boot, or someone misconfigured its network interface. SSH is gone, and the data center is a two-hour drive away.

Out-of-band management is access to a device through a dedicated path that is independent of the device's operating system and of its production network: a separate controller, port and network that keep working when the device's main software or connectivity has failed. With it, the engineer at home can see the server's screen, power-cycle it, boot it from a rescue image and watch it start, as if standing in front of it.

Out-of-band access comes in two forms in a data center: the management controller built into every server, and the console server for network devices. Both rely on a separate management network.

The baseboard management controller

A baseboard management controller (BMC) is a small, separate computer on a server's motherboard, with its own processor, memory, firmware and network connection, that monitors and controls the server independently of the main processors and operating system. It runs on the server's standby power, so it is reachable whenever the power cords are plugged in, even with the server switched off.

The BMC usually has its own dedicated network port on the back of the server, labeled for management. Many servers can also share one of the regular network ports with the BMC (a shared LOM, LAN on motherboard, port), which saves a cable but mixes management traffic with production traffic; data centers normally use the dedicated port.

What a BMC can do

• Remote power control: power on, graceful shutdown, hard power off, reset and power-cycle.
• Remote console: the server's screen, keyboard and mouse in a browser window (often called KVM over IP), from firmware setup through boot to the operating system's login prompt.
• Virtual media: mount an ISO image from your laptop or a file share as if it were a USB drive or DVD in the server, to install an operating system or boot a rescue system remotely.
• Sensors and health: temperatures (including inlet temperature), fan speeds, power draw, voltages, and the status of power supplies, memory and drives.
• Logs: a hardware event log that survives operating system crashes, such as a memory error corrected by ECC, a power supply that lost input, or a fan failure.
• Configuration and firmware: firmware settings, RAID configuration, and updates of the BIOS/UEFI, the BMC itself, and controllers and network cards.
• Alerts: SNMP traps, syslog, email or Redfish events to the monitoring system.

Vendor names

Every server vendor builds its own BMC firmware and gives it a name. You will meet these most often (generations as of 2026):

The names differ, the functions are largely the same, and all current ones support Redfish. The licensing differs too: some advanced features, such as the graphical remote console or virtual media, can require a paid license level on certain vendors' servers. Check this when ordering, not during an outage.

IPMI

The Intelligent Platform Management Interface (IPMI) is an older, vendor-neutral specification for talking to BMCs, both locally from the operating system and over the network. Version 2.0 is the last major version and is considered legacy, but it is still found on almost every server. Over the network it uses UDP port 623. The command-line tool ipmitool is the usual way to use it:

# Password comes from the IPMI_PASSWORD environment variable (-E), not the command line
ipmitool -I lanplus -H 198.51.100.11 -U opsadmin -E chassis power status
ipmitool -I lanplus -H 198.51.100.11 -U opsadmin -E sel elist
# Serial over LAN: the server's text console through the BMC (type ~. to leave)
ipmitool -I lanplus -H 198.51.100.11 -U opsadmin -E sol activate

Chassis Power is on
   1 | 09/28/2026 | 03:12:44 | Power Supply PS2 | Power Supply AC lost | Asserted
   2 | 09/28/2026 | 03:14:02 | Power Supply PS2 | Power Supply AC lost | Deasserted

The event log above tells a story the operating system never saw: power supply 2 lost its input for just over a minute at 03:12, a sign of a problem on one power feed, worth a ticket to facilities even though the server stayed up.

Redfish

Redfish is the modern standard of the DMTF (formerly the Distributed Management Task Force) for managing servers and other hardware: a RESTful API that exchanges JSON over HTTPS, describing the server as a tree of resources such as systems, chassis, managers, and their sensors and actions. It was designed as the successor to IPMI: secured with TLS, readable by people, easy to automate with any HTTP client, and extensible. As of October 2026 the current specification is DSP0266 version 1.25.0 (August 2026), with schema bundle 2026.2.

Every Redfish service starts at /redfish/v1/, and every resource links to the others with @odata.id URLs, so a client can discover a server's layout by following links (see REST APIs for the general principles). Reading the main system resource:

curl --cacert mgmt-ca.pem -u opsadmin \
  https://bmc-db01.mgmt.example.com/redfish/v1/Systems/1

{
  "@odata.id": "/redfish/v1/Systems/1",
  "Id": "1",
  "Name": "System",
  "Manufacturer": "Example Corp",
  "Model": "R2-2400",
  "SerialNumber": "EXA1234567",
  "PowerState": "On",
  "BiosVersion": "2.4.1",
  "ProcessorSummary": { "Count": 2 },
  "MemorySummary": { "TotalSystemMemoryGiB": 512 },
  "Status": { "State": "Enabled", "Health": "OK", "HealthRollup": "OK" },
  "Actions": {
    "#ComputerSystem.Reset": {
      "target": "/redfish/v1/Systems/1/Actions/ComputerSystem.Reset",
      "ResetType@Redfish.AllowableValues": ["On", "ForceOff", "GracefulShutdown", "GracefulRestart", "ForceRestart"]
    }
  }
}

The system's identifier differs per vendor (Dell uses System.Embedded.1, for example), which is why clients should follow the links from /redfish/v1/Systems rather than hard-code a path. Actions are POST requests to the advertised target. A graceful restart:

curl --cacert mgmt-ca.pem -u opsadmin -X POST \
  -H "Content-Type: application/json" \
  -d '{"ResetType": "GracefulRestart"}' \
  https://bmc-db01.mgmt.example.com/redfish/v1/Systems/1/Actions/ComputerSystem.Reset

Because Redfish is plain JSON, a few lines of code can check a whole fleet. The example below takes the responses of three BMCs (embedded here, so the example runs without a network) and compares each system with the approved firmware baseline.

import json

# Responses from GET /redfish/v1/Systems/1 on three BMCs (shortened)
responses = {
    "bmc-db01": '{"Id": "1", "PowerState": "On", "BiosVersion": "2.4.1",'
                ' "Status": {"State": "Enabled", "Health": "OK"}}',
    "bmc-db02": '{"Id": "1", "PowerState": "On", "BiosVersion": "2.3.0",'
                ' "Status": {"State": "Enabled", "Health": "Warning"}}',
    "bmc-vm07": '{"Id": "1", "PowerState": "Off", "BiosVersion": "2.4.1",'
                ' "Status": {"State": "Enabled", "Health": "Critical"}}',
}
APPROVED_BIOS = "2.4.1"   # the firmware baseline agreed in change management

for bmc, body in sorted(responses.items()):
    system = json.loads(body)
    problems = []
    if system["Status"]["Health"] != "OK":
        problems.append(f"health {system['Status']['Health']}")
    if system["PowerState"] != "On":
        problems.append(f"power {system['PowerState']}")
    if system["BiosVersion"] != APPROVED_BIOS:
        problems.append(f"BIOS {system['BiosVersion']} (baseline {APPROVED_BIOS})")
    print(f"{bmc}: {', '.join(problems) if problems else 'ok'}")

bmc-db01: ok
bmc-db02: health Warning, BIOS 2.3.0 (baseline 2.4.1)
bmc-vm07: health Critical, power Off

Console servers and local access

Switches, routers, firewalls and storage controllers have no BMC with a graphical console, but almost all have a serial console port, usually an RJ45 or USB port marked "console". A console server (also called a terminal server or serial server) is an appliance with dozens of serial ports, each cabled to the console port of one network device, that makes all those consoles reachable over the management network through SSH. When a configuration change cuts off a core switch from the network, the console server is how you get back in to undo it.

Console servers are often the last line of out-of-band access, so they are built to survive the failures they are meant to fix: many have a 4G/5G cellular modem as a backup uplink that does not depend on the data center's own network, and they are powered from both power feeds.

When remote access fails completely, someone goes on site. The options, in the words Server+ uses:

• Crash cart: a trolley with a monitor, keyboard, mouse and cables that you wheel to the rack and plug directly into the server.
• KVM switch: one keyboard, monitor and mouse shared among several servers in a rack (see Peripherals). An IP KVM adds network access to the same console, which makes it a form of out-of-band access for servers without a usable BMC.
• Serial connectivity: a laptop with a USB-to-serial adapter and a console cable, directly on a device's console port.

The management network

A management network is a separate network, physically or at least logically isolated from production and user traffic, that connects the management interfaces of servers, network devices, storage and power equipment, and that only administrators can reach through controlled entry points. BMCs, console servers, rack PDUs and the management ports of switches all live here.

Good management networks follow a few design rules:

• Separate from production. At minimum a dedicated VLAN; better, separate switches. If the management network depends on the production core switches, a core failure takes away the very access you need to repair it.
• Narrow entry points. Administrators reach it through a jump server with multi-factor authentication, never directly from the office network, and never from the internet.
• No outbound internet. BMCs have no reason to talk to the internet; firmware is staged on an internal repository.
• Documented addresses. Every management address belongs in the inventory (see Configuration and Asset Management), so that a check like the one below can catch mistakes.

import ipaddress

MANAGEMENT = ipaddress.ip_network("198.51.100.0/24")   # the isolated management network

# BMC addresses from the asset inventory
bmcs = {
    "db01": "198.51.100.11",
    "db02": "198.51.100.12",
    "vm07": "203.0.113.47",     # someone used the shared LOM port on the server LAN
    "vm08": "198.51.100.12",    # copy-paste error in the inventory?
    "fw-01": "198.51.100.200",
}

seen = {}
for host, address in sorted(bmcs.items()):
    ip = ipaddress.ip_address(address)
    if ip not in MANAGEMENT:
        print(f"{host}: {ip} is OUTSIDE the management network")
    if ip in seen:
        print(f"{host}: {ip} duplicates the address of {seen[ip]}")
    seen[ip] = host
print(f"checked {len(bmcs)} BMCs against {MANAGEMENT}")

vm07: 203.0.113.47 is OUTSIDE the management network
vm08: 198.51.100.12 duplicates the address of db02
checked 5 BMCs against 198.51.100.0/24

Securing BMCs

A BMC has more power over a server than the administrator account of its operating system: it can power the server off, boot it from an image of the attacker's choosing, change firmware settings and read the console. It runs its own firmware with its own vulnerabilities, which are patched on a different schedule from the operating system. Treat it as one of the most sensitive systems in the data center:

1. Isolate it on the management network, as above. Never expose a BMC to the internet.
2. Replace default credentials the moment a server is installed, with a unique strong password per BMC, ideally stored in a password vault, or better, use central authentication through the directory with per-person accounts (see Access Control).
3. Use roles: operators who only need the console and power control do not need administrator rights.
4. Disable what you do not use: IPMI over LAN, old protocol versions, unused services.
5. Use proper TLS certificates from your own certificate authority instead of the self-signed defaults, so clients can verify they are talking to the real BMC.
6. Keep BMC firmware updated and track it in vulnerability management like any other system.
7. Send BMC logs (logins, power actions, configuration changes) to central logging, so an unexpected power-off at night can be traced to an account.

Firmware updates through the BMC

The BMC is also the usual tool for keeping a server's other firmware current: BIOS/UEFI (see BIOS, UEFI and Boot), storage controllers, network cards, drives and the BMC itself. Vendors publish tested firmware bundles; you upload the bundle once, and the BMC applies the parts in the right order, often staging them for the next reboot.

Firmware updates are changes like any other (see Change Enablement): test them on a few servers first, move workloads off a host before it reboots, update one cluster member at a time, and record the new versions so that the fleet stays on one agreed baseline. A firmware update that fails halfway can leave a component unusable; never cut power to a server while its firmware is being written.