Learn › BMC & Server Management › First Contact
Final test: the whole First Contact chapter. Reaching a BMC over the network with ipmitool, mc info and the GUID, chassis and power state, lan print and the cipher table, the factory user table and the fleet standard (password rotation, an operator account, the anonymous slot), the SEL, the SDR and sensor thresholds, FRU, SOL and the watchdog, the two access paths, and the handover. 25 objectives on a real workstation called mgmt with a real IPMI 2.0 controller at 10.100.0.2.
This chapter covers the following topics:
What you already know. This is the first chapter of the track and it assumes nothing about IPMI. It does assume a working knowledge of a Linux shell: running a command, redirecting output into a file with >, and piping one command into another.
Objectives. After this chapter you can:
The machine. The workstation is a real Linode running Ubuntu 24.04. The controller beside it is a software IPMI 2.0 controller built on that machine at boot, on its own management bridge at 10.100.0.2. Boot takes about 3 minutes. This chapter is free; the machine is yours for 60 minutes and stops itself after 20 minutes idle. The dark boxes below are practice terminals, one command each, graded as you type; nothing before the final step needs the machine.
This chapter uses a real Linux workstation and software-emulated IPMI hardware. The protocol requests and replies are real; controller identity, sensor values and host behavior may be seeded or emulated. Supplied physical-hardware captures are labeled separately.
These five questions establish whether you need this chapter in full. Answer from what you know now. Each explanation names the section that covers the point.
>>> A server is two computers on one board. The host needs main power; the baseboard management controller needs only the standby rail a plugged-in supply provides, so it boots its own firmware and takes its own address as soon as the machine is cabled. Section 1.1.
>>> With no -I flag, ipmitool defaults to the in-band interface and looks for /dev/ipmi0, the character device the host kernel exposes for the controller on its own board. A workstation talking to another machine's controller has no such device and must name the network interface with -I lanplus. Section 1.3.
>>> Cipher suite 0 specifies none for the authentication, integrity and confidentiality algorithms. Offering a suite is distinct from allowing a session to use it. Check account, channel and cipher privilege policy; when permitted, suite 0 provides no password authentication. Section 1.7.
sel elist shows only the entries logged since the last clearsel elist resolves sensor numbers to sensor names and adds the reading against the thresholdsel list reads the log from the controller and sel elist reads a cached copyelist is an alias kept for compatibility>>> Both read the same records. sel list prints the compact form, naming sensors by number. sel elist is the extended form: it looks each sensor up in the sensor data repository, prints its name, and appends the reading that triggered the event against the threshold it crossed. Section 1.9.
>>> A user slot is a fixed row in a fixed-size table, so it is never removed. user disable clears the flag that lets the slot receive IPMI messages, which shows as the IPMI Msg column changing from true to false. Section 1.8.
A baseboard management controller, universally shortened to BMC, is a small computer soldered onto a server board. It has its own processor, its own memory, its own firmware and, on most server hardware, its own network port. It is not part of the machine you log into. It watches that machine.
The BMC runs on standby power: the trickle a plugged-in server draws from its supplies while its main power is off. Cabling a server and connecting it to mains is enough to start the BMC. It boots its own firmware, takes its own address on the management network, and begins listening, whether or not the host has ever been switched on.
The practical consequence is the reason this track exists. A machine with no operating system, no disks configured and no power applied still answers, because you are not talking to the machine. You are talking to the controller beside it.
ping sends a small packet and reports whether something sent one back. -c 2 stops after two. Run ping -c 2 10.100.0.2:
prompt: ops@mgmt:~$ answer: ping -c 2 10.100.0.2 output: PING 10.100.0.2 (10.100.0.2) 56(84) bytes of data. 64 bytes from 10.100.0.2: icmp_seq=1 ttl=64 time=0.050 ms 64 bytes from 10.100.0.2: icmp_seq=2 ttl=64 time=0.052 ms
--- 10.100.0.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1004ms rtt min/avg/max/mdev = 0.050/0.051/0.052/0.001 ms hint: The count flag takes the number of packets, then the address.
Two packets sent, two answered. Your round-trip times will differ; the counts will not.
The host at this address has no operating system installed and has never had power applied. What answered is its BMC, which has been awake since the machine was cabled.
Every command in this chapter is a question put to the small computer about the big one.
IPMI, the Intelligent Platform Management Interface, was published in 1998 by Intel, Dell, Hewlett-Packard and NEC so that one tool could manage every vendor's controller. Version 2.0, published in 2004, added the encrypted session used throughout this track. Branded controllers, Dell iDRAC, HPE iLO, Lenovo XClarity and OpenBMC among them, still answer IPMI beside their own web interfaces and Redfish.
There are exactly two ways to reach a BMC, and every later chapter depends on telling them apart.
Out-of-band means beside the operating system rather than through it. The workstation sends IPMI commands over the management network to the BMC's own port. The host is not involved and does not need to be running. This is the path that works on a machine that has never booted.
In-band means through the host. A running host kernel talks to the BMC on its own board over the KCS interface, Keyboard Controller Style, a register window between the host processor and the controller. Linux exposes it as the character device /dev/ipmi0 once the ipmi_si and ipmi_devintf modules load. This path needs a booted host, and it is the path that still works when the BMC's network port is misconfigured.
Check: if the host is off but standby power and the management network remain available, which access path can you use?
The BMC can stay available while the host is off because it receives standby power. The out-of-band path still needs the controller's management network; the in-band path needs a running host kernel.
The protocol on the out-of-band path is RMCP+, the Remote Management Control Protocol with the session extensions IPMI 2.0 added. It is carried in UDP datagrams to port 623. ipmitool names that interface lanplus.
ipmitool is the reference client. Every command in this track has the same shape: flags that say where to send the request and how to authenticate, then the request itself.
| Flag | Meaning |
|---|---|
-I lanplus | Use the RMCP+ network interface. Without it, ipmitool tries the in-band device. |
-H <address> | The controller's address. |
-U <name> | The account name on the controller. |
-P <password> | That account's password. |
-C 3 | Ask for cipher suite 3. Section 1.7 explains why this is stated rather than left to the default. |
The first error worth meeting is the one produced by leaving the interface out. Run ipmitool mc info:
prompt: ops@mgmt:~$ answer: ipmitool mc info output: Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory hint: Type the command exactly as written, with no flags at all.
With no -I, ipmitool defaults to the in-band interface and looks for the character device the host kernel would expose for a controller on its own board. This workstation is not that host, so the device does not exist and ipmitool says so.
The error is worth recognising because it is the one that appears when a command is copied from documentation written for the in-band path. It is not a network problem, an authentication problem or a controller problem. It means no interface was named.
The second error is what RMCP+ returns when the credentials are refused. Run the full command with a password that is not the controller's:
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P wrong -C 3 mc info output: Error: Unable to establish IPMI v2 / RMCP+ session hint: The full flag set with the password replaced by the word wrong.
One line, and deliberately uninformative. RMCP+ does not say whether the user name or the password was wrong, and it does not say whether the account exists. The same message covers all of it, which is correct behaviour: telling an unauthenticated caller which half of a credential was right is a disclosure.
What to check when you see it, in order: the account name, the password, and whether the account is enabled on this channel. Section 1.8 covers all three. A controller that has been brought to a standard also refuses the factory password here, which is exactly what proves the rotation worked.
Your goal: read the BMC's firmware version without changing the host.
mc info asks the management controller to identify itself. The connection options select the controller and the lab account; the last two words select the information to read.
Try it: at ops@mgmt:~$.
ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 mc infoA reply means this connection and account could read the controller. It does not prove that the host is healthy.
Check: find Firmware Revision and IPMI Version in the output. These describe the BMC, not the host's BIOS or Linux kernel.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 mc info output: Device ID : 0 Device Revision : 3 Firmware Revision : 1.05 IPMI Version : 2.0 Manufacturer ID : 0 Manufacturer Name : Unknown Product ID : 256 (0x0100) Product Name : Unknown (0x100) Device Available : yes Provides Device SDRs : yes Additional Device Support : Sensor Device SDR Repository Device SEL Device FRU Inventory Device IPMB Event Receiver Chassis Device Aux Firmware Rev Info : 0x00 0x00 0x00 0x00 hint: The full flag set with ADMIN as both the account and the password, then the mc info request.
You have identified the controller. In this lab:
Firmware Revision: 1.05 is the BMC firmware currently running.IPMI Version: 2.0 is the IPMI version the controller reports.Device Available: yes means the controller reports that it is available.Manufacturer Name: Unknown is expected for this training controller. The Linux workstation runs real commands against an IPMI emulator; it is not a physical Dell or HPE board.
The remaining capability lines describe interfaces the controller advertises. You will explore them later. For now, point to the firmware line and explain why it is not the host BIOS version.
Next: save this same response to a file so it can become part of your commissioning record.
A commissioning record is written from the controller, never by hand. The shell's > sends a command's output into a file instead of the screen, which is how every deliverable in the lab is produced.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 mc info > ~/bmc/mc-info.txt output: hint: The same command as the previous step with the shell redirection appended.
No output. That is correct: everything the command printed went into the file. cat ~/bmc/mc-info.txt prints it back.
Redirection is the pattern behind most of the lab. Nineteen of the twenty-five objectives are one of the read commands in this chapter with > ~/bmc/<name>.txt appended, and the remaining sections teach the read command rather than repeating the redirection. The grader reads each file and compares the facts in it against the controller at grading time, so any command producing the same facts scores.
A GUID, globally unique identifier, is a 128-bit value assigned to a system at manufacture. It does not change when the operating system is reinstalled, when a disk is replaced, or when the machine moves rack. Inventory systems key on it for exactly that reason.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 mc guid output: System GUID : 44454c4c-4c00-3031-8033-4c3c34333632 GUID Encoding : SMBIOS (WARNING: IPMI Specification violation!) GUID Version : Name-based using MD5 hint: mc has a guid subcommand alongside info.
Three lines. The first is the identifier itself.
GUID Encoding reports how the bytes are laid out. The warning is genuine and worth understanding: the IPMI specification orders the bytes one way and SMBIOS, the firmware table standard, orders them another. Many controllers return the SMBIOS order, and ipmitool says so rather than quietly presenting the wrong value. The identifier is still correct; only the byte order differs from what the specification asks for.
GUID Version reports how the value was generated. Name-based using MD5 means it was derived from a name rather than from a hardware address and a timestamp.
The chassis commands report the physical state of the enclosure: whether it has power, whether a fault is latched, whether the case has been opened. chassis status prints the whole set.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis status output: System Power : off Power Overload : false Power Interlock : inactive Main Power Fault : false Power Control Fault : false Power Restore Policy : always-off Last Power Event : Chassis Intrusion : inactive Front-Panel Lockout : inactive Drive Fault : false Cooling/Fan Fault : false hint: chassis has a status subcommand.
Eleven lines. Four of them are the ones read first on a machine that is behaving badly.
System Power : off is the live power state of the host, read from the controller rather than inferred.
Power Overload and Main Power Fault are latched fault flags. A supply that shut down under load leaves one of these set, and it stays set after the symptom clears, which is what makes it evidence.
Power Restore Policy : always-off says what the machine does when mains power returns after a cut. always-off leaves it off, always-on starts it, and previous restores whatever state it was in. In a hall that has just had a power event, this one field decides whether a rack comes back by itself.
Chassis Intrusion : inactive reports the case switch. On hardware that has one, an opened lid latches here.
When the answer needed is just whether the host has power, chassis power status prints one line. It is the form that goes into a script, because there is nothing to parse out of it.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power status output: Chassis Power is off hint: chassis power takes a status subcommand of its own.
One line, and it says Chassis Power is off, not System Power : off. The two commands report the same fact in different words, which matters when a script greps for one of them.
chassis power also takes on, off, cycle, reset, soft and diag. Every one of those moves the host. Chapter 2 is that chapter; this one reads and records only, and the lab is graded on the host still being off at the end.
A BMC reaches the network through a channel. A channel is a numbered communication path into the controller: channel 1 is conventionally the LAN, and other numbers cover the system interface, a serial port or an IPMB bus. Almost every network command takes the channel number as an argument, and getting it wrong is a common cause of an empty answer.
lan print prints every network parameter for one channel.
prompt: ops@mgmt:
Practice First Contact in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.