The out-of-band management network
Every managed node on the SC//Reliant™ platform carries a second, independent network path alongside the VLANs described in Networking overview. This is the out-of-band (OOB) management network: the path to each node's Baseboard Management Controller (BMC), the management processor that responds to Intelligent Platform Management Interface (IPMI) commands. Depending on the hardware vendor you may know it as the BMC, XCC (Lenovo), or iLO (HPE).
This page covers what the OOB network is for, how it is addressed, which ports it uses, and why isolation matters on it. For the procedure that configures it, see Configuring IPMI / BMC management.
Why a separate network path exists
The BMC is a management processor separate from the host operating system, with its own network interface. It remains reachable when the node's operating system is not — which is the reason the path exists at all, and what distinguishes it from every in-band path in the firewall reference tables.
The OOB path supports two operations:
- Chassis control and status. Power off, power cycle, and reset a node, and read its chassis status, without anyone at the site.
- Cluster fencing (STONITH). On an HA pair, fencing is an out-of-band operation: one node sends an IPMI command across the network to its peer's BMC. If IPMI over LAN is disabled on the target, its BMC does not answer and fencing fails.
Fencing is the consequential one. It makes the OOB path a dependency of cluster high availability rather than only a convenience for remote administration. Because a fencing failure surfaces only when a node actually needs to be fenced, a broken OOB path tends to be discovered at the worst possible moment. For background on fencing, see Pacemaker and Corosync.
Addressing model
Each node's BMC has its own IP address. Because that address belongs to the individual node rather than to a group of them, it is defined per node even though the surrounding IPMI configuration is shared across a node group — as is the BMC network's default gateway. The netmask is given in full dotted-quad form rather than as a prefix length.
The BMC interface's relationship to the node's physical NICs is set by its operating mode. The platform recognizes three: standalone (0), where the BMC uses a dedicated management port; shared (1), where it shares a NIC with the host; and failover (2). The address itself is assigned either statically or by DHCP. Typical values are standalone mode with a static address, and the platform prefills defaults that are usually correct.
The BMC interface also has an IPMI channel number — typically 1 — which identifies the network being configured and ties it to the account authorized to use it. The user on a channel is configured only after that channel's network has been configured successfully.
Ports and traffic paths
Two paths reach a node's BMC. Both appear in the firewall reference tables in Networking overview, sourced from LAN 1 on the edge appliance.
| Port | Protocol | Purpose | Encrypted |
|---|---|---|---|
| 623 | UDP | IPMI commands — chassis control, chassis status, and fencing | None |
| 443 | TCP | The BMC's own web interface | HTTPS |
Port 623 carries no encryption, as the firewall table records. The commands and credential crossing it are protected by network isolation rather than by the protocol itself, which is what makes the segmentation of this path a security control rather than a matter of tidiness.
There is also a third path, which is not a network path at all. The Keyboard Controller Style (KCS) interface is a local, in-band channel between a node's operating system and its own BMC. The platform applies BMC configuration over KCS from inside the host, so no network route to the BMC is required in order to configure it — only to use it afterwards. KCS and IPMI over LAN are separate BMC settings, usually on separate pages of the BMC interface, and enabling one does not enable the other.
Account handling
The platform maintains exactly one BMC account per node and explicitly disables every other user slot on each configuration run. An account created by hand in a BMC web interface does not survive the next run. The managed account is created at Administrator privilege, which is what gives it the chassis control and chassis status permissions fencing requires.
That single account's credential is also the credential the cluster uses to fence its peers, so it is rotated through the platform rather than on the device. Changing the password directly in a BMC web interface leaves the stored value stale, fencing keeps presenting the old credential, and the next configuration run reverts the BMC anyway. See Rotating the IPMI password.
What can go wrong at the network layer
| Symptom | Cause |
|---|---|
| Configuration fails on the BMC network step, and the user is skipped as a result | KCS is disabled, so the host cannot reach its own BMC to apply settings. Most common on Lenovo XCC, where KCS is off by default. |
| The BMC is still reachable only on its old address after a run that reported success | On HPE iLO, network settings are stored but not activated until the management controller is cold reset. Nothing has failed; the change is staged, not live. |
no matching cipher suite when connecting over the network | Lenovo XCC only — the default Standard security mode offers no cipher suite the management tooling can negotiate. On non-Lenovo hardware this error has a different cause. |
| Fencing reports success but the target node never reboots | The IPMI command is reaching the caller's fencing agent but failing at the target's BMC — typically a stale credential, IPMI over LAN disabled on the target, or the target's account lacking network access. On HPE iLO, also check that a cold reset followed the last configuration run. |
Note that these fail in different ways: the first is a hard failure, the second reports success while the path does not work, and the last two surface only on use. Each is diagnosed and resolved in the troubleshooting table of the configuration page, which indicates the hardware each fix applies to. Do not apply a vendor-specific fix to another vendor's hardware.
Related articles
- Configuring IPMI / BMC management — the procedure that configures the BMC account and network, including per-vendor prerequisites and password requirements. Note that the IPMI property applies only to platform profiles newer than 6.0.0.
- Configuring networking — the site VLAN topology and the firewall reference tables.
- Pacemaker and Corosync — how STONITH fencing uses the OOB path.
- Firewall rules and policies in RPM — building the rules that permit these paths.