Chances are you’ve heard of the Intelligent Platform Management Interface, or IPMI. And chances are very good that you view it as little more than a way to remotely reboot servers. But IPMI is oh so much more than that… wonders await you, should you just take the time to explore a little. So lets start with the basics and work outwards.

Almost any modern server is going to have a Baseboard Management Controller, or BMC for short, on the mainboard. On whitebox motherborads such as Tyan or ASUS this is normally an addon option but any purpose built server from Sun, HP, IBM, SuperMicro, etc, is going to have one on the board out of the box. The BMC acts as a hub for all the various sensor data on the board(s). In years past you might have heard of I2C and SMBus buses and sensors accessible via “lm-sensors”, the BMC is the hub for these various sensor buses. The BMC, therefore, has access to all the various sensors on a give system and therefore is rich with useful data. The most common way in which to retrieve that data is via IPMI.

IPMI can be accessed in several ways, these methods are refered to as “channels”, as in communications channels. The two most common are via the LAN (“lan”) or if your OS has an BMC driver via the local device (commonly “/dev/bmc”). Please note that in many places the acronyms MC and BMC are used interchangeably. Now, to exploit those channels the most common method is to use the Open Source “ipmitool”. This tool is found included with most OS’s (including Solaris, in /usr/sfw/bin) or can be downloaded on the IPMItool SourceForge page. Other projects exist, including OpenIPMI and GNU’s FreeIPMI. All these implementations offer a rich API for writing custom applications and CLI tools for interaction. As I said, IPMItool is by far the most common, so I’ll discuss it here.

First to clear up a common misconception… lets take a Dell PowerEdge server. Many are convinced that you need a Dell Remote Access Card (or Controller depending on who you ask), better known as a DRAC, in order to use IPMI. You do not! Service Processors (SP), such as Sun’s ILOM and ELOM (on X86, we’re ignoring SPARC here) or Dell’s DRAC, are not BMC’s, rather they are mini-computers on a card, typically running Linux, powered by “trickle” or “standby” power such that they are running even if the mainboard is not running. These cards simply act as a conduit to access the BMC and other functions of the system. The web interfaces on the SP’s, for instance, commonly are just passing IPMI commands back to the BMC. Thus, if you click “Power On” in the SP web interface your really just sending an IPMI “power on” command to the BMC. The point is, you do not need an SP to use IPMI with a system! The caviate is, depending on the architecture of the system, you may require an SP to talk to the BMC if the system is not running. For instance, on a Dell PowerEdge you can talk IPMI to the BMC without a DRAC by “Sharing” the first gigabit port, meaning that you really don’t need a DRAC at all unless you want the ability to, for instance, get SNMP data which is really just an SNMP agent on the DRAC pulling data from the BMC and returning it as OIDs and branded up as “Dell OpenManage”. To keep going with the Dell example, if you SSH onto a DRAC and use the “connect com2” command to do serial redirection, your actually doing a local IPMI Serial-over-LAN session, your just doing it inside the chassis.

Okey, so, IPMI is everywhere. So what can we do with it? Like I said, most people are familiar with this:

$ ipmitool power status
Chassis Power is on

$ ipmitool chassis status
System Power         : on
Power Overload       : false
Power Interlock      : inactive
Main Power Fault     : false
Power Control Fault  : false
Power Restore Policy : always-off
Last Power Event     : command
Chassis Intrusion    : inactive
Front-Panel Lockout  : inactive
Drive Fault          : false
Cooling/Fan Fault    : false
Front Panel Control  : none

$ ipmitool chassis power cycle
...

In the above examples I’m using the local “bmc” communications channel. The command “power” is actually a shortcut for “chassis power”, so “ipmtool power cycle” and “ipmitool chassis power cycle” are the same thing. When the “-I (channel)” is not specified, local “bmc” channel is used. Here is a LAN example. (Those above was from a Sun X4150, below are Dell 2950):

$ ipmitool -I lanplus -H 10.0.50.60 -U root -f /ipmi.pass power status
Chassis Power is on

$ ipmitool -I lanplus -H 10.0.50.60 -U root -f /ipmi.pass chassis status
System Power         : on
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
Sleep Button Disable : not allowed
Diag Button Disable  : allowed
Reset Button Disable : not allowed
Power Button Disable : allowed
Sleep Button Disabled: false
Diag Button Disabled : true
Reset Button Disabled: false
Power Button Disabled: true

The syntax above is fairly straight forward. I’m using the “lanplus” channel (the “lan” channel is for IPMI 1.5 commands, whereas “lanplus” is for IPMI 2.0 RMCP+), -H specifies the IP address of the IPMI interface, -U is the IPMI user (typically “root”). In recent releases of ipmitool the -P “password” option has been replaced with “-f /file”, the file contains the password in plaintext, this ensures that the IPMI password isn’t viewable via a process listing which is seen via “ps -ef” or the SNMP process tables. The default password on Dell PowerEdge servers is “calvin”, on Sun Fire servers its “changeme”, in both cases the user is “root”.

So… what else is there to see? There are two really interesting things to look at…

The first is the Sensor Data Repository (SDR). Here you will find thresholds and values for all the available sensors. Here is an example on a Sun X4100 M2:

$ ipmitool sdr elist
sys.id           | 00h | ok  | 23.0 | State Asserted
sys.intsw        | 01h | ok  | 23.0 | 
sys.psfail       | 02h | ok  | 23.0 | Predictive Failure Deasserted
sys.tempfail     | 03h | ok  | 23.0 | Predictive Failure Deasserted
sys.fanfail      | 04h | ok  | 23.0 | Predictive Failure Deasserted
mb.t_amb         | 05h | ok  |  7.0 | 34 degrees C
mb.v_bat         | 06h | ok  |  7.0 | 2.88 Volts
mb.v_+3v3stby    | 07h | ok  |  7.0 | 3.18 Volts
mb.v_+3v3        | 08h | ok  |  7.0 | 3.34 Volts
mb.v_+5v         | 09h | ok  |  7.0 | 5.02 Volts
mb.v_+12v        | 0Ah | ok  |  7.0 | 12.10 Volts
mb.v_-12v        | 0Bh | ok  |  7.0 | -12.35 Volts
mb.v_+2v5core    | 0Ch | ok  |  7.0 | 2.54 Volts
mb.v_+1v5core    | 0Dh | ok  |  7.0 | 1.53 Volts
mb.v_+1v2core    | 0Eh | ok  |  7.0 | 1.22 Volts
fp.t_amb         | 14h | ok  | 12.0 | 24 degrees C
pdb.t_amb        | 1Bh | ok  | 19.0 | 23 degrees C
io.t_amb         | 22h | ok  | 15.0 | 22 degrees C
bp.power         | 0Fh | ok  | 13.1 | State Deasserted
bp.locate        | 10h | ok  | 13.2 | State Deasserted
bp.locate.btn    | 11h | ok  | 13.2 | State Deasserted
bp.alert         | 12h | ok  | 13.3 | State Deasserted
fp.prsnt         | 13h | ok  | 12.0 | Device Present
fp.usbfail       | 15h | ok  | 12.0 | Predictive Failure Deasserted
fp.power         | 16h | ok  | 12.1 | State Asserted
fp.locate        | 17h | ok  | 12.2 | State Deasserted
fp.locate.btn    | 18h | ok  | 12.2 | State Deasserted
fp.alert         | 19h | ok  | 12.3 | State Deasserted
fp.ledbd.prsnt   | 1Ah | ok  | 12.0 | Device Present
ps0.prsnt        | 1Ch | ok  | 10.0 | Device Present
ps0.vinok        | 1Eh | ok  | 10.0 | State Asserted
ps0.pwrok        | 1Dh | ok  | 10.0 | State Asserted
ps1.prsnt        | 1Fh | ok  | 10.1 | Device Absent
ps1.vinok        | 21h | ns  | 10.1 | Disabled
ps1.pwrok        | 20h | ns  | 10.1 | Disabled
io.id0.prsnt     | 23h | ok  | 15.0 | Device Present
io.id1.prsnt     | 24h | ok  | 15.0 | Device Absent
io.hdd0.fail     | 25h | ok  |  4.0 | Predictive Failure Deasserted
io.hdd1.fail     | 26h | ok  |  4.1 | Predictive Failure Deasserted
io.hdd2.fail     | 27h | ok  |  4.2 | Predictive Failure Deasserted
io.hdd3.fail     | 28h | ok  |  4.3 | Predictive Failure Deasserted
p0.t_core        | 29h | ok  |  3.0 | 24 degrees C
p0.v_vdd         | 2Ah | ok  |  3.0 | 1.38 Volts
p0.v_vddio       | 2Bh | ok  |  3.0 | 1.85 Volts
p0.v_vtt         | 2Ch | ok  |  3.0 | 0.91 Volts
p0.fail          | 2Dh | ok  |  3.0 | Predictive Failure Deasserted
p0.d0.fail       | 2Eh | ok  | 32.0 | Predictive Failure Deasserted
p0.d1.fail       | 2Fh | ok  | 32.1 | Predictive Failure Deasserted
p0.d2.fail       | 30h | ok  | 32.2 | Predictive Failure Deasserted
p0.d3.fail       | 31h | ok  | 32.3 | Predictive Failure Deasserted
p1.t_core        | 32h | ok  |  3.1 | 21 degrees C
p1.v_vdd         | 33h | ok  |  3.1 | 1.38 Volts
p1.v_vddio       | 34h | ok  |  3.1 | 1.85 Volts
p1.v_vtt         | 35h | ok  |  3.1 | 0.91 Volts
p1.fail          | 36h | ok  |  3.1 | Predictive Failure Deasserted
p1.d0.fail       | 37h | ok  | 32.4 | Predictive Failure Deasserted
p1.d1.fail       | 38h | ok  | 32.5 | Predictive Failure Deasserted
p1.d2.fail       | 39h | ok  | 32.6 | Predictive Failure Deasserted
p1.d3.fail       | 3Ah | ok  | 32.7 | Predictive Failure Deasserted
ft0.fm0.fail     | 3Bh | ok  | 29.0 | Predictive Failure Deasserted
ft0.fm1.fail     | 3Ch | ok  | 29.1 | Predictive Failure Deasserted
ft0.fm2.fail     | 3Dh | ok  | 29.2 | Predictive Failure Deasserted
ft1.fm0.fail     | 3Eh | ok  | 29.3 | Predictive Failure Deasserted
ft1.fm1.fail     | 3Fh | ok  | 29.4 | Predictive Failure Deasserted
ft1.fm2.fail     | 40h | ok  | 29.5 | Predictive Failure Deasserted
ft0.fm0.f0.speed | 41h | ok  | 29.0 | 7900 RPM
ft0.fm2.f0.speed | 43h | ok  | 29.2 | 7200 RPM
ft0.fm1.f0.speed | 42h | ok  | 29.1 | 7400 RPM
ft1.fm0.f0.speed | 44h | ok  | 29.3 | 9200 RPM
ft1.fm1.f0.speed | 45h | ok  | 29.4 | 9100 RPM
ft1.fm2.f0.speed | 46h | ok  | 29.5 | 8400 RPM
ft0.fm0.f1.speed | 47h | ok  | 29.0 | 7800 RPM
ft0.fm1.f1.speed | 48h | ok  | 29.1 | 7400 RPM
ft0.fm2.f1.speed | 49h | ok  | 29.2 | 7100 RPM
ft1.fm0.f1.speed | 4Ah | ok  | 29.3 | 9100 RPM
ft1.fm1.f1.speed | 4Bh | ok  | 29.4 | 9000 RPM
ft1.fm2.f1.speed | 4Ch | ok  | 29.5 | 8400 RPM

You can see that some of these are boolean failure warnings, such as “io.hdd0.fail”. By using the “elist” option the status is de-referenced, so we can see that its set as “Predictive Failure Deasserted” (with out “elist” this reports as 0x01). The fans, however output the speed and the temp sensors output the current reading.

While a full dump of the sensor repository is neat to look at, you’ll want to cherry pick values for practical purposes such as monitoring. For instance, lets get just the motherboard ambient temperature reading using “sdr”s sister command “sensor”:

$ ipmitool sensor reading "mb.t_amb"
mb.t_amb         | 34

If we want to feed this value to our monitoring application, such as Zabbix, Nagios, Cacti, and friends, we just parse that to display only the value, and we’re good to go:

$ ipmitool sensor reading "mb.t_amb" | awk '{print $3}'
34

We can apply the same method to any thing else in the SDR, allowing us to create pretty graphs and useful alerts based on voltages, fan speed, temperatures, or failure warnings. If you want greater clarity into a given sensor item, use “sensor get”, example:

$ ipmitool sensor get 'mb.t_amb'        
Locating sensor record...
--
BMC req.fn         : 0x4
BMC req.lun        : 0x0
BMC req.cmd        : 0x2d
BMC req.datalength : 0x1
BMC req.data       : 0x5 
--
--
BMC req.fn         : 0x4
BMC req.lun        : 0x0
BMC req.cmd        : 0x27
BMC req.datalength : 0x1
BMC req.data       : 0x5 
--
Sensor ID              : mb.t_amb (0x5)
 Entity ID             : 7.0
 Sensor Type (Analog)  : Temperature
 Sensor Reading        : 34 (+/- 0) degrees C
 Status                : ok
 Lower Non-Recoverable : na
 Lower Critical        : na
 Lower Non-Critical    : na
 Upper Non-Critical    : 70.000
 Upper Critical        : 75.000
 Upper Non-Recoverable : 80.000
--
BMC req.fn         : 0x4
BMC req.lun        : 0x0
BMC req.cmd        : 0x2b
BMC req.datalength : 0x1
BMC req.data       : 0x5 
--
--
BMC req.fn         : 0x4
BMC req.lun        : 0x0
BMC req.cmd        : 0x29
BMC req.datalength : 0x1
BMC req.data       : 0x5 
--
 Assertions Enabled    : ucr+ unr+ 
 Deassertions Enabled  : ucr+ unr+ 

This output helps clarify more explicitly the various thresholds, this information is also useful to you monitoring or reporting solution. Spend some time on your platform playing with the “sdr” and “sensor” commands, hours of fun.

The second important feature is the System Event Log (SEL), it is exactly what you think it is:

$ ipmitool sel elist
 100 | 08/21/2007 | 13:25:45 | Voltage mb.v_+1v2core | Lower Non-critical going low  | Reading 0 < Threshold 1 Volts
 200 | 08/21/2007 | 13:25:45 | Voltage p0.v_vdd | Lower Non-critical going low  | Reading 0 < Threshold 1.00 Volts
 300 | 08/21/2007 | 13:25:46 | Power Supply ps0.pwrok | State Asserted
 400 | 08/21/2007 | 13:25:46 | Processor p0.fail | Predictive Failure Asserted
 500 | 08/21/2007 | 13:25:48 | Power Supply ps1.pwrok | State Asserted
 600 | 08/21/2007 | 13:25:50 | Voltage mb.v_+1v2core | Lower Non-critical going high | Reading 1.22 > Threshold 1 Volts
 700 | 08/21/2007 | 13:25:50 | Voltage p0.v_vdd | Lower Non-critical going high | Reading 1.38 > Threshold 1.00 Volts
 800 | 08/21/2007 | 13:25:52 | System Firmware Progress | Motherboard initialization | Asserted
 900 | 08/21/2007 | 13:25:52 | System Firmware Progress | Video initialization | Asserted
 a00 | 08/21/2007 | 13:25:58 | System Firmware Progress | USB resource configuration | Asserted
 b00 | 08/21/2007 | 13:26:09 | System Firmware Progress | Option ROM initialization | Asserted
 c00 | 08/21/2007 | 13:26:53 | System Firmware Progress | User-initiated system setup | Asserted
 d00 | 08/21/2007 | 13:27:11 | System Firmware Progress | Motherboard initialization | Asserted
 e00 | 08/21/2007 | 13:27:11 | System Firmware Progress | Video initialization | Asserted
 f00 | 08/21/2007 | 13:27:17 | System Firmware Progress | USB resource configuration | Asserted
1000 | 08/21/2007 | 13:27:25 | Power Supply ps0.pwrok | State Deasserted
1100 | 08/21/2007 | 13:27:27 | Power Supply ps1.pwrok | State Deasserted
1200 | Pre-Init Time-stamp   | Power Supply ps1.vinok | State Asserted
1300 | Pre-Init Time-stamp   | Entity Presence ps1.prsnt | Device Present
1400 | Pre-Init Time-stamp   | Power Supply ps0.pwrok | State Deasserted
1500 | Pre-Init Time-stamp   | Power Supply ps0.vinok | State Deasserted
1600 | Pre-Init Time-stamp   | Physical Security sys.intsw | General Chassis intrusion | Asserted
1700 | Pre-Init Time-stamp   | Entity Presence ps0.prsnt | Device Present
1800 | Pre-Init Time-stamp   | Power Supply ps1.pwrok | State Asserted
1900 | 11/14/2007 | 21:34:32 | System Firmware Progress | Motherboard initialization | Asserted
1a00 | 11/14/2007 | 21:34:32 | System Firmware Progress | Video initialization | Asserted
1b00 | 11/14/2007 | 21:34:38 | System Firmware Progress | USB resource configuration | Asserted
1c00 | 11/14/2007 | 21:35:09 | System Firmware Progress | Option ROM initialization | Asserted
1d00 | 11/14/2007 | 21:35:48 | System Firmware Progress | Motherboard initialization | Asserted
1e00 | 11/14/2007 | 21:35:48 | System Firmware Progress | Video initialization | Asserted
1f00 | 11/14/2007 | 21:35:54 | System Firmware Progress | USB resource configuration | Asserted
2000 | 11/14/2007 | 21:36:25 | System Firmware Progress | Option ROM initialization | Asserted
2100 | 11/14/2007 | 21:44:26 | System Firmware Progress | Motherboard initialization | Asserted
2200 | 11/14/2007 | 21:44:26 | System Firmware Progress | Video initialization | Asserted
2300 | 11/14/2007 | 21:44:32 | System Firmware Progress | USB resource configuration | Asserted
2400 | 11/14/2007 | 21:45:03 | System Firmware Progress | Option ROM initialization | Asserted
2500 | 11/14/2007 | 21:45:50 | System Firmware Progress | System boot initiated | Asserted
2600 | 11/14/2007 | 21:59:17 | Power Supply ps1.pwrok | State Deasserted
2700 | 11/14/2007 | 21:59:22 | Power Supply ps1.pwrok | State Asserted
2800 | 11/14/2007 | 21:59:35 | System Firmware Progress | Motherboard initialization | Asserted
2900 | 11/14/2007 | 21:59:35 | System Firmware Progress | Video initialization | Asserted
2a00 | 11/14/2007 | 21:59:41 | System Firmware Progress | USB resource configuration | Asserted
2b00 | 11/14/2007 | 22:00:12 | System Firmware Progress | Option ROM initialization | Asserted
2c00 | 11/14/2007 | 22:00:56 | System Firmware Progress | System boot initiated | Asserted
2d00 | 11/14/2007 | 22:14:01 | Power Supply ps1.pwrok | State Deasserted
2e00 | 11/14/2007 | 22:14:06 | Power Supply ps1.pwrok | State Asserted
2f00 | 11/14/2007 | 22:14:20 | System Firmware Progress | Motherboard initialization | Asserted
3000 | 11/14/2007 | 22:14:20 | System Firmware Progress | Video initialization | Asserted
3100 | 11/14/2007 | 22:14:26 | System Firmware Progress | USB resource configuration | Asserted
3200 | 11/14/2007 | 22:14:57 | System Firmware Progress | Option ROM initialization | Asserted
3300 | 11/14/2007 | 22:15:42 | System Firmware Progress | System boot initiated | Asserted
3400 | 11/14/2007 | 22:23:46 | System Firmware Progress | Motherboard initialization | Asserted
3500 | 11/14/2007 | 22:23:46 | System Firmware Progress | Video initialization | Asserted
3600 | 11/14/2007 | 22:23:52 | System Firmware Progress | USB resource configuration | Asserted
3700 | 11/14/2007 | 22:24:03 | System Firmware Progress | Option ROM initialization | Asserted
3800 | 11/14/2007 | 22:24:46 | System Firmware Progress | System boot initiated | Asserted
3900 | 11/14/2007 | 23:36:17 | Power Supply ps1.pwrok | State Deasserted
3a00 | Pre-Init Time-stamp   | Power Supply ps0.pwrok | State Deasserted
3b00 | Pre-Init Time-stamp   | Power Supply ps0.vinok | State Asserted
3c00 | Pre-Init Time-stamp   | Entity Presence ps0.prsnt | Device Present
3d00 | Pre-Init Time-stamp   | Power Supply ps0.pwrok | State Asserted
3e00 | 11/15/2007 | 01:36:22 | System Firmware Progress | Motherboard initialization | Asserted
3f00 | 11/15/2007 | 01:36:22 | System Firmware Progress | Video initialization | Asserted
4000 | 11/15/2007 | 01:36:28 | System Firmware Progress | USB resource configuration | Asserted
4100 | 11/15/2007 | 01:36:59 | System Firmware Progress | Option ROM initialization | Asserted
4200 | 11/15/2007 | 01:37:44 | System Firmware Progress | System boot initiated | Asserted

So here we see this event history of our system. Both Dell and Sun SP’s and firmware use this event log to send warnings and such, for instance if you want to clear a mysterious warning light on a Dell’s chassis just clear the SEL.

The SEL’s best friend is Platform Event Filtering (PEF). Here we can create rules which dictate alerting policy. When a given event occurs that matches a PEF rule, an alert in the form of an SNMP trap is sent, which is called a “Platform Event Trap” (PET). The default event rules list is short on Sun X4100:

$ ipmitool pef list  
 1 | active, pre-configured | 0x11 | Any | Any | Warning | OEM | OEM | Alert,OEM-defined | 2
 2 | active, pre-configured | 0x11 | Any | Any | Critical | OEM | OEM | Alert,OEM-defined | 3
 3 | active, pre-configured | 0x11 | Any | Any | Non-recoverable | OEM | OEM | Alert,OEM-defined | 4
 4 | active, pre-configured | 0x11 | Any | Any | Information | OEM | Any | Alert,OEM-defined | 1

On the Dell’s its a bit more fine grained:

$ ipmitool -I lanplus -H 10.0.50.60 -U root -f /ipmi.pass pef list
 1 | active | 0x11 | Fan | Any | Critical | Threshold | (0x01/0x0004),

But where do these traps go?  Thats defined by the PEF policy which is commonly configured via your SP, in the case of Sun systems this would be using the ELOM/ILOM interface, in the case of Dell you can do this in the BIOS.

$ ipmitool -I lanplus -H 10.0.50.60 -U root -f /ipmi.pass pef policy
 1 | 1 | Match-always | 1 | 802.3 LAN | PET | public | 0 | 0 | 0.0.0.0 | 00:00:00:00:00:00
 2 | 1 | Match-always | 1 | 802.3 LAN | PET | public | 0 | 0 | 0.0.0.0 | 00:00:00:00:00:00
 3 | 1 | Match-always | 1 | 802.3 LAN | PET | public | 0 | 0 | 0.0.0.0 | 00:00:00:00:00:00
 4 | 1 | Match-always | 1 | 802.3 LAN | PET | public | 0 | 0 | 0.0.0.0 | 00:00:00:00:00:00


While these two, SDR and SEL, are extremely useful there is one more IPMI feature that you may not even be aware of... Serial over LAN, or SoL for short.  It does what it sounds like, console serial redirection via IPMI over the LAN!  This means that in systems that once required a console server that was physically connected to each servers serial port can now be access simply using "ipmitool".  This feature was introduced in IPMI v1.5 and almost all modern generation servers support it and, as noted earlier, some SP's console redirect (such as DRAC 'connect com2') is in fact IPMI SoL in disguise.

$ ipmitool -I lanplus -H 10.0.50.60 -U root -f /ipmi.pass sol activate
[SOL Session operational.  Use ~? for help]
#  <-- this is a console prompt


The controls are those of SSH, use tilde-dot (~.) to disconnect.  IPMI SoL isn't fool proof however, I've run into several instances where 'ipmitool' would segfault and dump my connection for no repeatable reason, and I've seen this both "remotely" from another system and on a DRAC, so don't throw away all your console server just yet, but there are plenty of cases where it can sure come in handy.


So, let me recap since this is a lot to digest if your new to it:


IPMI is your friend.
Modern server motherboards possess a Baseboard Management Controller (BMC) which is the heart of your box accessed via IPMI.
SP's are not BMC's, they just provide lights out access to it.
IPMI is useful for more than checking power status and power cycling.
The IPMI Sensor Data Repository (SDR) is accessable with the IPMItool "sdr" and "sensor" commands and provide access to all system sensors.
IPMItool can be used locally and remotely, didn't buy an SP or forgot to configure LAN settings in the BIOS?  Just install IPMItool locally and see if you can say hello!
Sensor data can easily be output and formatted to be input into your monitoring solution whether it be Uptime, Nagios, Zabbix or Cacti.
The System Event Log (SEL) can provide meaningful insite into previous events that the OS may not have been aware of
Platform Event Filtering (PEF) can be used to alert on specified events from the SEL, sending Platform Event Traps (PET) in SNMP Trap format, providing a means for asynchornously alerting on error conditions.
IPMI provides remote console capability, IPMI Serial-over-LAN (SoL), which can provide a low-cost/no-cost remote console access method where no other solution may be applicable.  Can't access a system?  Try SoL before you power cycle!
Whats in that box?  IPMItool can also output a FRU list (ipmitoo fru) to assist in your auditing needs.
... and much more.


I hope this gives you a new appreciation for just what IPMI can do for you and how you might be able to exploit it.  In many cases its there, right now, waiting to be used on your servers, just because you didn't assign an IP address doesn't mean you can't use it, so please install IPMItool and give it a shot.  If you had to buy servers with out a DRAC or SP, don't dispare, you're not missing out as much as you think.