分类:
2008-04-04 20:19:34
From time to time it may be desirable to have a single server on your network which provides both DHCP and NIM services. The AIX implementation of the DHCP server supports the bootp protocol which is also used by NIM for the installation of system images on remote machines. There are various pieces of documentation which describe how to configure the system and the DHCP server configuration file to support BOOTP. These instructions are adequate unless you are also trying to serve DHCP addresses to clients. In this case, configuration of the NIM machine for remote boot typically corrupts the DHCP server configuration file.
In this note, I explain the essential steps in configuring the system and DHCP configuration file, show how the configuration file becomes corrupted during the NIM configuration process and how to repair this. This note is not definitive in that I assume there are alternative approaches.
System configuration
The DHCP and BOOTP protocols use the same port number and therefore cannot coexist. By default, the bootps entry is commented out in /etc/inetd.conf. If this is not the case, there is a well-documented description on how to do this at
\_dhcpnim.html
(CSM for AIX
DHCP server configuration file (1)
Our DHCP server is configured to serve a number of client addresses on our class C subnet. The configuration file contains a network statement with an address (192.168.207.0) and range (24). The network statement must contain one (or more) subnet statements within a pair of curly braces. Subnet statements can contain options within a pair of curly braces.
Here is the relevant part of our configuration file:
network 192.168.207.0 24
{
option 3 192.168.207.1
option 6 192.168.207.2
option 28 192.168.207.255
subnet 192.168.207.0 192.168.207.52-192.168.207.62
{
# DHCP address range
}
}
The server configuration file requires two entries to enable DHCP to recognize and respond to BOOTP requests. These are:
supportBOOTP yes
supportUnlistedClients yes
and they should be external to (outside the scope of) the network statement.
NIM client configuration
I will presume that NIM has been installed and configured and that basic client configuration steps have been performed. This is covered in detail in "NIM from A-Z in AIX
s5701p1.xyz.com:bf=/tftpboot/s5701p1.xyz.com:ip=192.168.207.141:ht=ethernet:sa=192.168.207.2:sm=255.255.255.0:
It also appends an entry that looks like the following to the DHCP configuration file:
# BOOTP CLIENT: s5701p1.xyz.com
client 1 0 192.168.207.141
{
option 1 255.255.255.0
option sa 192.168.207.2
option bf "/tftpboot/s5701p1.xyz.com"
}
DHCP configuration file (2)
The client statement appended to the configuration file causes problems because the client statement must appear within the scope of a subnet statement. If you have DHCP logging turned on at the right level (WARNING?) this shows up as a syntax error in the configuration file on server start-up. Note that if you have set up the MAC address of a client (see SG24-7296 p286) then the client id_value, parameter 2 on the client statement, will contain the MAC address rather than 0.
To resolve the issue of the DHCP server managing both automatic and manual address assignment, I found it necessary to re-write the configuration file by hand. The final configuration file looks like:
network 192.168.207.0 24
{
option 3 192.168.207.1
option 6 192.168.207.2
option 28 192.168.207.255
subnet 192.168.207.0 192.168.207.52-192.168.207.62
{
# DHCP address range
}
subnet 192.168.207.0 192.168.207.141-192.168.207.141
{
# BOOTP CLIENT: s5701p1.xyz.com
option 1 255.255.255.0
option sa 192.168.207.2
option bf "/tftpboot/s5701p1.xyz.com "
}
}
supportBOOTP yes
supportUnlistedClients yes
Note the second subnet statement, within the scope of the network statement, replaces the generated client statement. Additional "manual address" clients can be supported with additional subnet statements.
If all else fails
It was not originally apparent whether the failure to boot the client machine was due to machine configuration, BOOTP, TFTP or DHCP. The client could ping the server but the BOOTP step would fail, in fact because DHCP was not configured to accept the BOOTP request.
Assuming that the /etc/bootptab entry exists and is correct (i.e. boot file exists, network addresses are correct) then the following method can be used to verify the BOOTP and TFTP steps:
# Stop the DHCP server (stopsrc -s dhcpsd)
# Start the BOOTP server in stand-alone command line mode (/usr/sbin/bootpd -s -d -d -d)
# Re-start the client network boot. This should show client progress.
# Review the diagnostics on the server. This should show the BOOTP request received and the TFTP file transfer starting.