Monday July 14, 2008

ILOM and DHCP

It happens too often that at customer sites there are issues around the IP address for the Service Processor. The proper way to handle this is IMHO simple: For each server, add an entry to the DHCP server, where based on the MAC address of the SP, a known IP address will be assigned. This way, everything is controlled by a centralized DHCP configuration but still each server gets a "semi static" IP address.

Unfortunately, in many situations customers can not implement this, or they simply don't want to. The "can not" is most likely not based on technical arguments, but has mainly to do with organizational and responsibility issues.

Your second option is to set the Service Processor IP address from the BIOS. Which works fine, but sometimes it can be hard to find a monitor and keyboard in a Data Center. Or nobody is willing to give you a free static IP address. Third option is to let the SP do a DHCP request and monitor the logfiles on the DHCP server to see what address was handed out. Which won't work if the person who needs to use the SP has no access to the DHCP server.

The end result is that you can easily end up in a Catch 22. In the old days of V20/40z servers, we had those tiny LCD screens and you could even set the IP address using a few buttons on the front of the server. But the newer generation doesn't have those features anymore.

Last week, I was again confronted with this problem (on a corporate network, where I had zero privileges) and I solved it in a different way. What I did was write a little script that tries to ping every IP address in the subnet, or better in the range that is available to the DHCP server. Kind of "poor man's port scanner". The script (let's call it "pingscan.sh") is pretty primitive and looks like this.

#!/bin.sh
for i in 13 14 15 16 17 18 19 20 21 22 23 24; do
for j in 0 1 2 3 4 5 6 7 8 9; do
ping -n -t 1 192.168.1.$i$j 1
done
done

This will scan addresses from 192.168.1.130 to 192.168.1.249, adjust the values for your network. The "-t 1" and the "1" at the end (this is Solaris ping) will take care that with one second gaps, each address in the subnet will be tried. So, the script will take a few minutes to complete, depending on the range.

Fire up your server and let the SP do a DHCP request. Then run "pingscan.sh > before". And here comes the trick! Disconnect the network cable to the SP and run "pingscan.sh > after". A simple diff of the two files will show which IP address was given to the SP.

# diff before after
57c57
< 192.168.1.186 is alive
---
> no answer from 192.168.1.186

The script could be made much fancier, but this one only uses /bin/sh and can be typed in a couple of minutes. On a large and busy network it could happen that you will get multiple candidates. And of course this is not a preferred solution, because it isn't guaranteed that a week later the DHCP server won't give a different IP address. But this trick can help when you find yourself in a nasty corner. At least, it did that for me.