Fortech I.T. Solutions - SANDBOX

root@box ~]# ipmitool -I lan -U root -H 192.168.35.12 -a chassis power status

[root@box ~]# ipmitool -I lan -U root -H 192.168.35.12 -a chassis power cycle

[root@box ~]# ipmitool -I lan -U root -H 192.168.35.6 -a chassis power status

[root@box ~]# ipmitool -I lan -U root

* "Head Node" system eth0 was configured as 10.1.1.1 subnet; IPMI piggyback on this was configured as 192.168.35.29 . A virtual interface, eth0:1 was plumbed with an IP of 192.168.35.229 so it was possible to "ping" the IPMI interfaces of all (27) machines in this same physical subnet / network.

@]

I had initially followed hints from the URL, http://lonesysadmin.net/2007/06/21/how-to-configure-ipmi-on-a-dell-poweredge-running-red-hat-enterprise-linux/ , regarding setup of OpenIPMI on RHEL/ CentOS - which is a site that Dell tech support unofficially referred me to at a later time :-)


'''Basic drill:'''

'''Basic assumptions, I believe:'''

'''In my case, for illustrative example:'''

IPMI on these systems is nearly as straightforward as it ought to be. There were only a few 'annoyances' which I'll briefly mention, in case anyone else sees them / and wonders if they are alone.

Basic drill,
* if you are booting the systems anyhow, press Ctrl-E at boot time and enable IPMI; then configure a static IP for IPMI access, and set a password for "root" user.
* otherwise, you will have to install openipmi-tools to configure these parameters from command-line on each system.
* note in some cases you may have to use openipmitools to do it, even if you set at boot the parameters. For a group of 27 pe1950 systems recently configured, I found that approximately 5 machines failed to 'work' for IPMI until impi-tools was used to set parameters. ie, setting via BIOS didn't work perfectly in all cases, and I have no idea why. But at least it worked fine after ipmi-tools was used.

Basic assumptions, I believe:
* IPMI is a 'shared' interface off the first physical interface of the system
* IPMI won't be happy if that interface is trunked at the OS level with any other interface
* the easiest way to access the IPMI interface, is from other machines in the same physical subnet / as the first interfaces where IPMI is exposed.

In my case, for illustrative example:
* "Head Node" system eth0 was configured as 10.1.1.1 subnet; IPMI piggyback on this was configured as 192.168.35.1. A virtual interface, eth0:1 was plumbed with an IP of 192.168.35.201 so it was possible to "ping" the IPMI interfaces of all (27) machines in this same physical subnet / network.
* note, it seems that a machine configured thus is unable to ping its OWN IPMI interface, nor to issue commands to that interface. Presumably a feature of the virtual interface / IPMI interface and how the 'coexist'.

So, a few examples / work captures for reference:


Install IPMI Tools, and get IPMI enabled to run at boot:
[@
483 yum install OpenIPMI-tools
485 chkconfig --list ipmi
486 chkconfig --level 2345 ipmi on
487 service ipmi start
@]

Poll a nearby machine to see IPMI is behaving as expected:

[@
root@dig ~]# ipmitool -I lan -U root -H 192.168.35.12 -a chassis power status
Password: GIVE_PASSWORD_HERE
Chassis Power is on


Send the power cycle command:
[root@dig ~]# ipmitool -I lan -U root -H 192.168.35.12 -a chassis power cycle
Password: GIVE_PASSWORD_HERE
Chassis Power Control: Cycle
@]
In theory you have just power cycled the machine specified by 192.168.35.12; give it a minute to recover and it should be back following a boot cycle.

Note that if IPMI was NOT working / configured happily on a given node, you will see something like this when you try to poll IPMI status:

[@
[root@dig ~]# ipmitool -I lan -U root -H 192.168.35.6 -a chassis power status
Password:
Activate Session command failed
Error: Unable to establish LAN session
Unable to get Chassis Power Status
[root@dig ~]# ipmitool -I lan -U root

@]

In a problem case like this,

* Connect to the 'problem system'
* ensure IPMI tools are installed
* Configure local parameters directly
* then repeat your test to see if IPMI behaves when polled remotely.

Approximately as follows,

[@

/usr/bin/ipmitool -I open lan set 1 ipaddr 192.168.35.23
/usr/bin/ipmitool -I open lan set 1 defgw ipaddr 192.168.35.29
/usr/bin/ipmitool -I open lan set 1 netmask 255.255.255.0
/usr/bin/ipmitool -I open lan set 1 access on
/usr/bin/ipmitool -I open lan set 1 password @b1ggl35!
/usr/bin/ipmitool -I open user set password 2 @b1ggl35!
/usr/bin/ipmitool -I open lan print 1
@]

you should expect the last command to return output approx thus,
[@

[root@compute-0-20 ~]# /usr/bin/ipmitool -I open lan print 1
Set in Progress : Set Complete
Auth Type Support : NONE MD2 MD5 PASSWORD
Auth Type Enable : Callback : MD2 MD5
: User : MD2 MD5
: Operator : MD2 MD5
: Admin : MD2 MD5
: OEM :
IP Address Source : Static Address
IP Address : 192.168.35.23
Subnet Mask : 255.255.255.0
MAC Address : 00:22:19:4f:bd:72
SNMP Community String : public
IP Header : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
Default Gateway IP : 192.168.35.29
Default Gateway MAC : 00:00:00:00:00:00
Backup Gateway IP : 0.0.0.0
Backup Gateway MAC : 00:00:00:00:00:00
802.1q VLAN ID : Disabled
802.1q VLAN Priority : 0
RMCP+ Cipher Suites : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
Cipher Suite Priv Max : aaaaaaaaaaaaaaa
: X=Cipher Suite Unused
: c=CALLBACK
: u=USER
: o=OPERATOR
: a=ADMIN
: O=OEM
[root@compute-0-20 ~]#


and in theory, after doing this, the 'problem node' may be more responsive to remote IPMI requests from nearby machines / without complaints regarding "can't establish LAN Connection".

your mileage may vary :-)
@]