Configuring Out-Of-Band Management Interface from In-Band Server
Most modern x86 servers include out-of-band Management or Lights-out Management systems. These systems offer remote configuration and remote console access to a headless server normally located in a datacenter. These are typically used when first setting up a server, or perhaps when the server is hosed. The company I work for is large enough to have dedicated server operators, and in my role I rarely if ever need to access the consoles of real devices. However, I recently needed to get to the console of a device and the server was in a different continent and timezone and I couldn't access the IP address I'd been emailed :( Not a good start to the day. I remember using ipmitool to configure OOB management before, but of course I never wrote down what I did then. As this blog is really a note taking memory aid system, I'm writing it down for next time. So using ipmitool I was able to determine the IP address of the server.
1ipmiserver# ipmitool -I open lan print 1
2Set in Progress : Set Complete
3Auth Type Support : NONE MD2 MD5 PASSWORD
4Auth Type Enable : Callback :
5 : User : MD2 MD5 PASSWORD
6 : Operator : MD2 MD5 PASSWORD
7 : Admin : MD5
8 : OEM :
9IP Address Source : Static Address
10IP Address : 192.168.1.1
11Subnet Mask : 255.255.255.0
12MAC Address : 00:00:00:00:00:00
13SNMP Community String : public
14IP Header : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
15BMC ARP Control : ARP Responses Enabled, Gratuitous ARP Disabled
16Gratituous ARP Intrvl : 2.0 seconds
17Default Gateway IP : 192.168.1.254
18Default Gateway MAC : 00:00:00:00:00:00
19Backup Gateway IP : 0.0.0.0
20Backup Gateway MAC : 00:00:00:00:00:00
21802.1q VLAN ID : Disabled
22802.1q VLAN Priority : 0
23RMCP+ Cipher Suites : 0,1,2,3,4
24Cipher Suite Priv Max : XaaaaXXXXXXXXXX
25 : X=Cipher Suite Unused
26 : c=CALLBACK
27 : u=USER
28 : o=OPERATOR
29 : a=ADMIN
30 : O=OEM
31ipmiserver#
From this I noticed that the default gateway for the out-of-band was incorrect (as with all blog posts, the IPs are changed to RFC1918 private addresses here). What must have happen is that the server installation engineer had used a screen and keyboard on a trolley to configure the server, and then probably tested it from a device on the same subnet (I'm being generous here, as he/she may have never bothered testing it!) Anyway, quick man ipmitool for syntax and this was easily fixed from the in-band server with the following command:
1ipmitool -I open lan set 1 defgw ipaddr 192.168.1.1