What Is DHCP Server?
The DHCP server is an IP address dispenser. It automatically assigns IP addresses to network clients who ask for service conforming to RFC1531. The most common clients are laptop and desktop computers running Microsoft Windows95, but there are many others (Macintosh, Unix, Linux, etc.). The number of clients is growing very rapidly.
HP provides a DHCP server beginning with the HP-UX 10.10 release, and it is a part of the standard networking distribution. Besides the server itself, there are tools to help you monitor and adjust your configuration, troubleshoot problems, track down clients, etc. HP also provides a DHCPclient beginning with the HP-UX 10.20 release, but that is another story.
The concept of a DHCP server is an outgrowth of the older BOOTP bootstrap protocol, which was used by diskless clients. DHCP is a faithful superset of BOOTP, and the DHCP server will transparently service older BOOTP clients even though the simple clients have no knowledge of the modern sophistication of DHCP. DHCP servers and clients from different vendors interoperate very well with each other.
Why Use DHCP Server?
The main purpose of DHCP is to reduce the labor involved for managing your network. In the bad old days, every computer that wanted to attach to a network had to be configured manually. An IP address was usually assigned by a network administrator (a human), involving a phone call and many delays. Then a long series of commands would be issued by the user to bring up the network interface (ifconfig, route, etc). In the old BOOTP world, the BOOTP clients would get all of the information from a BOOTP ser
The DHCP server is an automatic dispenser of IP addresses and other configuration information. It is highly flexible, and allows the network administrator to setup the server once and then serve many thousands of clients. It is not necessary to know who the clients are in advance. Clients can come and go as they please, and DHCP takes care of them all with no human intervention. Clients can be completely anonymous (the most popular choice), identified by class (e.g. Xterminal), or recognized by hardwar
Some secondary benefits are address recycling and network usage statistics. Some organizations will have many clients that only use an IP address for a short time, and then give it up again. The DHCP server will automatically recycle these IP addresses as they are freed, and make them available to new clients as they appear. But no client will have their address taken away involuntarily. The client gets to keep the address until the client is willing to give it up. The DHCP server will not grant a lea
The DHCP specification is very flexible, and allows users to add new and customized capabilities that the designers never imagined. It is a modern and sophisticated networking protocol.
Who Uses DHCP?
Many large Internet Service Providers use DHCP to manage their IP addresses. The clients are usually Windows95 computers in people's homes, and they connect to the network by phone lines or cable TV lines or even more exotic technologies and get their IP address and other configuration information from a DHCP server at the ISP main office. The clients usually only stay powered on for a few hours at a time, and when they are gone the addresses are recycled for other customers. The ISP might have a dozen
their customer base while minimizing investment in expensive routers and other equipment. DHCP also reduces paperwork and configuration hassles, since the customer does not need to report their hardware address to the network administrator, and the ISP does not need to step the customer through any network setup procedures.
Any organization with a network is a candidate for a DHCP server. The larger your network is, the more your organization looks like the ISP described above. Do you have employees and computers that move around frequently? Does your company periodically reorganize? Do you have users who carry their laptop computers with them everywhere they go? Are you adding subnets as the number of users grows? DHCP can help reduce the frustration.
DHCP can significantly reduce the time needed to setup a newly purchased computer. With HP-UX, just plug in the Ethernet connection and power up! The workstation or server automatically discovers the local DHCP servers on your network, negotiates a lease for an IP address, configures lan0, and brings up networking. No user input is required.
Basic Operations
A DHCP transaction begins when a client sends out a DHCPDISCOVER packet.
This is usually a broadcast packet, because the client usually has no idea what servers are available in the local area. The most basic version contains the client's hardware address and very little else.
The DHCP server receives the DHCPDISCOVER packet and determines if it has addresses available on the proper subnet. If the server is willing to grant a lease, then a DHCPOFFER packet is sent back to the client. This offer contains the proposed IP address for the client, the server's name and IP address, and possibly other options.
The DHCP client receives the DHCPOFFER packet, possibly receiving multiple offers from different servers. Most clients are not too smart about multiple offers, and are likely to just grab the first one that arrives and ignore all others. Even so, the client will usually do some sanity checking on the one offer it pays attention to, and will frequently reject offers that have very short lease time (say 10 seconds). If the client likes the offer, then it will send a DHCPREQUEST packet to the server. This
The DHCP server receives the (unicast) DHCPREQUEST packet and grants the lease to the client in all normal cases. The server marks the address as COMPLETE in the internal database of addresses, along with information about the client and the lease expiration time. The server sends a DHCPACK packet to the client, which is the official notification that the address has been granted. Most of the fields in the DHCPACK packet are simply copied from the DHCPREQUEST packet.
Suppose a client is granted a lease with a duration of two hours. When one hour has passed, if the client is still powered on, the client will send a DHCPREQUEST packet to the server (unicast) requesting that the lease be extended. The server is then required to update the lease for a new duration of two hours and send a DHCPACK packet to the client indicating this. These updates will continue for as long as the client remains powered on. Sometime after the client is powered off, the lease expiration t
It is permitted for the DHCP clients to always send a broadcast DHCPDISCOVER packet with minimal information at power-on, but many clients are smarter than this. Many clients will remember their old leases, remember the server they obtained the lease from, and send a unicast DHCPDISCOVER packet to the server asking for an updated lease expiration for the same IP address the client had before. If that IP address has not been recycled already (the usual case), then the server will offer that address to the
In the case of laptop and portable computers, it is common for the client to be powered off, moved to a new subnet (say in another building), and then powered on again. In this case, the client sends a DHCPDISCOVER packet asking for the old IP address on the old subnet, which will not work any more. The DHCP server counters by offering a new IP address on the correct subnet (where the client is now). Usually the client accepts this new address and continues happily. If the client rejects this new addre
DHCP Server Configuration
So how do you set up your DHCP server? The quick answer is to use SAM, the
System Administration Manager. SAM has helpful screens to guide you through the setup process. But you could also do the setup by hand, and experienced users with large configurations use scripts to generate and modify "/etc/bootptab" and
"/etc/dhcptab". All of the DHCP server configuration is stored in those two files (plus the bootpd line in "/etc/inetd.conf"). The bootptab file has permanent clients (infinite lease), and the dhcptab file has all others.
The dhcptab file contains groups of IP addresses that are managed by DHCP, divided into two types: POOL GROUPS and DEVICE GROUPS. The pool groups are the most common type. A pool group is a collection of IP addresses on one subnet, available for anonymous clients (most clients are anonymous). A pool group could be minimally defined by an entry like this in "/etc/dhcptab":
DHCP_POOL_GROUP:\
ba:\
pool-name=my_first_pool:\
subnet-mask=255.255.255.0 :\
addr-pool-start-address= 15.13.100.20 :\
addr-pool-last-address= 15.13.100.29 :
In this minimal example, "ba:" means the broadcast flag has been turned on. Most clients need this. For example, Win95 clients are not even listening for unicast replies, they will only receive a packet if it is broadcast. Most DHCP servers will have the broadcast flag turned on in most of their pool groups. The "pool-name" is just a label to assist the system administrator. The client never knows this name. The pool has a starting address and a last address, so the group in this
A device group is just like a pool group with the additional field called class-id. The client must match the class_id field of the group. The most common class-id is "Xterminal", which identifies a special type of device that is different from the generic Windows95 machine. The system administrator can define all sorts of additional fields and information that could be passed to this type of client:
DHCP_DEVICE_GROUP:\
class-name=MEGA_OPTION_GROUP:\
class-id="Xterminal":\
addr-pool-start-address= 192.11.22.11:\
addr-pool-last-address= 192.11.22.15 :\
subnet-mask=255.255.255.0 :\
lease-time=1000:\
lease-policy=accept-new-clients:\
allow-bootp-clients=false:\
call-on-assignment=/etc/script.assignment:\
call-on-decline=/tmp/script.decline:\
call-on-release=/tmp/script.release:\
call-on-lease-extend=/tmp/script.lease_extend:\
bf= goofy.bootfile:\
hd=/var/tmp:\
ba:\
cs=192.11.22.36:\
ds=192.99.99.99 15.13.104.13:\
gw=192.44.44.44:\
im=77.77.33.33:\
lg=123.123.123.123 55.55.55.55:\
lp=45.45.45.45:\
ns=66.66.66.66:\
rl=123.77.99.35:\
to=153:\
ts=88.99.88.99:\
vm=rfc1048:\
hn:\
bs=auto:\
md=/tmp/dumpfile.of.the.century:\
dn=cup.hp.com:\
ef=/tmp/extensions:\
nt=194.88.200.244:\
rp=/turnip/onion/carrot:\
ss=200.233.200.233:\
tr=50:\
tv=87:\
xd=77.11.1.244:\
xf=77.11.1.245:\
yd=hp.com:\
ys=9.7.5.3:
The bootpd(1m) manpage has information on all of those flags and many others, including arbitrary new ones that you can define yourself. Remember that it is only the "class-id" field that makes a DEVICE GROUP different from a POOL GROUP. All of the other fields could be present in either type.
There could be a large number of device groups on a single subnet, but the client must send the correct "class_id" field to match the device group. In practice you will have one device group per subnet for each type of device that needs service: "Xterminal", "printer", "fax", "mopier", HP-UXInstallClient", etc.
But clients that fill out the class_id field are still uncommon, and most clients are just anonymous and so fall into a pool group on the appropriate subnet.
Starting Up
The name of the DHCP daemon is "bootpd", the same BOOTP daemon that has
been around for years. All of the BOOTP and DHCP functionality is combined in this single executable, and there is not a separate daemon for DHCP. Backward compatibility is handled by always processing the BOOTP information first. A BOOTP client will always get a normal BOOTP response if it is configured in "/etc/bootptab" on the server. If nothing is found, then there are other options for the server to supply a modified DHCP reply to the BOOTP client.The bootpd daemon is a subsidiary of the
#bootps dgram udp wait root /usr/lbin/bootpd bootpd
and then execute "inetd -c" to reconfigure inetd. Your DHCP server is now open for business!
Monitoring DHCP Operation
There are four basic techniques for monitoring DHCP, and you will use them singly or in different combinations depending on your needs at the time. The most direct real-time information comes from the syslog with debugging turned up. This is only good for short periods because the size of the syslog grows rapidly, but it provides the most detail. Put the "-d5" option on the bootpd line in "/etc/inetd.conf". The debug level can be as high as 9, but level 5 is pretty verbose. Reconfi
tail -f /var/adm/syslog/syslog.log | grep bootp
The usual things to look for:
Is the client request reaching the server at all?
Does the server make a reply to the client?
Is the reply appropriate for the client?
The next debug technique is to trace the DHCP packets flowing in and out:
/usr/sbin/dhcptools -t ct=100
This turns on tracing and writes the full contents of 100 packets in a file named
"/tmp/dhcptrace". This is similar to network tracing (nettl), but easier to use because there are less extraneous packets to sift through and friendlier because many DHCP fields are decoded for you. You could always fall back to nettl or even use a hardware sniffer, but the DHCP tracing capability is very handy. Be aware that you must always use the "ct=NN" option, because the default number of packets to trace is zero. The maximum number of packets to trace is 100, which is plenty.
The next debug technique is to dump the internal state of the daemon.
/usr/sbin/dhcptools -d
This dumps dynamic info into "/tmp/dhcp.dump.other" and other stuff into
"/tmp/dhcp.dump.bootptab" and "/tmp/dhcp.dump.dhcptab".
The most basic debug technique is to simply look at the contents of
"/etc/dhcpdb". This is a less verbose version of "/tmp/dhcp.dump.dhcptab", and is continually updated by the daemon. An explanation of the contents of
"/etc/dhcpdb" is below.
PERFORMANCE TIPS
If you have a large number of DHCP clients (say 1000) and short lease times (say one hour), then your DHCP server will be receiving many hundreds of requests per hour, perhaps in bursts. Server performance can become an issue in cases like this. There are two adjustments the user can make to improve performance:
"dhcpdb-write-perf" and "ping".
The DHCP server writes a file, "/etc/dhcpdb", which is a non-volatile copy of all the outstanding leases. Writing this file is the most time consuming job that the server does. The default behavior is to write the entire file at the end of each lease transaction. This keeps the file completely up to date at all times. But the system administrator has the ability to postpone the file write, by setting a parameter in the
"/etc/dhcptab" file:
dhcpdb-write-perf=5:\
This causes the file write to be postponed for five seconds, allowing other transactions to continue (at the rate of about 100 transactions per second), tremendously speeding up the server in general. The maximum value of this parameter is 600 seconds, but the recommended range is 5 to 10.
Another time consuming server activity is the "ping", which is done before offering an address to a new client. The server waits for one full second for a ping response, and only gives the lease to the client if no response comes back. This is an extra check being done by the server, not required by the RFC. It should never be necessary on a well managed network. The ping is only done for the
DISCOVER->OFFER part of a transaction. It can be turned off with the command line option "-P", and this will speed up the server in handling DISCOVER packets.
ERRORS
There are a number of error messages that might appear in the syslog file when a client fails to get an address lease. The most popular ones are:
Reply not sent; Reason = 304 NO_GROUP_FOR_SUBNET
This is caused by a client requesting an address on a subnet not available from this DHCP server. The client gets no response from this server.
Reply not sent; Reason = 305 NO_ADDRESSES_LEFT_IN_GROUP
This is caused by a full pool group or device group. The DHCP server has handed out all of the addresses available, and there are no more right now. The client gets no response from this server.
Reply not sent; Reason = 308 HW_ADDR_LEN_ERROR
This is usually caused by an illegal packet coming from a Windows NT machine (or maybe a Synoptics hub). We don't really know what this machine is doing, it doesn't need a response from DHCP server, so we ignore it.
Reply not sent; Reason = 316 REQUEST_WITHOUT_OFFER
This could happen if the DHCP server somehow forgets about a client lease, and the client asks for a renewal. The server is saying: "Can't renew a lease that doesn't exist already". Fortunately the client will simply come back and get a brand new lease, so this error is rarely fatal. But it is an indicator of a small problem.
Here is the full list of error codes that could appear in syslog:
301 PREVIEW_SUCCESSFUL
302 PREVIEW_UNSUCCESSFUL
303 HW_ADDR_TYPE_ERROR
304 NO_GROUP_FOR_SUBNET
305 NO_ADDRESSES_LEFT_IN_GROUP
306 REJECTING_NEW_CLIENTS
307 REJECT_NEW_BOOTP_CLIENT
308 HW_ADDR_LEN_ERROR
309 UNKNOWN_SERVER_ID
310 OPEN_OF_DB_FILE_FAILED
311 CLOSE_OF_DB_FILE_FAILED
312 RENAME_OF_DB_FILE_FAILED
313 HASH_DB_INCONSISTENCY
314 WOULD_RELAY_DHCP_REQUEST
315 WOULD_DISCARD_RELAY_REQUEST
316 REQUEST_WITHOUT_OFFER
317 NAK_CLIENT
318 WRONG_SUBNET
399 UNWILLING_TO_EXTEND_LEASE
TOOLS
The HP-UX DHCP server has tools that can help the system administrator to debug problems and make adjustments while the server is running. When building the files "/etc/bootptab" and "/etc/dhcptab", it is very handy to have an automatic tool for discovering illegal entries and typographical errors. The tool for this is:
/usr/sbin/dhcptools -v
Some administrators will want to "preview" a lease for a particular client, to make sure the server is responding correctly:
dhcptools -p ht=hardware_type ha=hardware_address sn=subnet_identifier
[lt=lease_time] [rip=requested_IP_address]
An individual address lease can be reclaimed, making it available for a new client:
dhcptools -r ip=IP_address ht=hardware_type ha=hardware_address
dhcptools -R ip=IP_address ci=client_identifier
The complete internal state of the server can be dumped into files:
/usr/sbin/dhcptools -d
Callbacks
The HP DHCP server provides a wonderful facility for customization, known as callbacks. The callbacks are user defined actions that are executed for different types of transaction successes and failures. The callbacks are defined in the file
"/etc/dhcptab" like this:
call-on-unrequited="/tmp/unreq.script" :\
call-on-assignment=/etc/script.assignment:\
call-on-decline=/tmp/script.decline:\
call-on-release=/tmp/script.release:\
call-on-lease-extend=/tmp/script.lease_extend:\
call-on-discard-address=:\
Each callback passes some command line parameters (such as client hardware address, client IP address, class-id, etc) to the executable file named in
"/etc/dhcptab". The executable is typically a shell script, but it can be any executable file. The popular uses are to send mail to the network administrator or store data in a file about DHCP clients that have succeeded or failed in negotiating a lease. The uses are limited only by your imagination.
New IETF Documents on DHCP
RFC2131 DHCP 7th April, 1997 (replaces RFC1533)
RFC2132 DHCP Options and BOOTP Vendor Extensions 7th April, 199
Appendix 1:
Format of the /etc/dhcpdb file
C 152.163.65.64: 152.163.65.122 010080C798198F 1 0080C798198F 32E135A1 00
C 152.163.65.64: 152.163.65.121 010000C0ECC0D6 1 0000C0ECC0D6 32E11DA9 00
C 152.163.65.64: 152.163.65.123 00 1 08000777EDE8 FFFFFFFF 00
First, you must understand that changing the /etc/dhcpdb file by hand is strictly off limits. It won't do any good anyway, since it is only read at startup, and the daemon overwrites it frequently. This becomes very dramatic in HP-UX 10.30 or when you install PHNE_13648 (highly recommended, by the way).
So now let's talk about the individual entries. You can get a more verbose version by doing "dhcptools -d", which will dump the complete state into
/tmp/dhcp.dump.*.
The first column in /etc/dhcpdb is the state of the client or IP address, and there are three possibilities:
C complete: client has a valid lease for this address (possibly expired)
R released: client has given up this address, it can be reused
D discarded: this address cannot be used
The second field indicates which subnet/network the lease is on. These are all on the 152.163.65 subnet/network in the example above, and it is common for them all to be on the same subnet/network. The fourth part of this "IP address" is actually meaningless and may change to zero at any time.
The third field is the IP address for this client or entry.
The fourth field is the client-ID. Most clients use a client-ID that is simply hwtype+hwaddr, but some clients (Macintosh) use nothing. It is an option for the client, and they can put anything in there that they want. In the example, the third entry has no client-ID, indicated by "00" in the fourth field.
The fifth field is the hardware type, with most of today's clients being 01 for
ethernet.
The sixth field is the hardware address, the standard 6 byte ethernet ID.
The seventh field is the lease expiration time. FFFFFFFF indicates an infinite lease. It is hard for humans to read this hex field, and I am considering changing the format to something friendlier in a future release. It is taken from the gettimeofday(2) system call.
The eighth field is the hostname, as returned from a call to gethostbyaddr.
It is "00" if there is no name<->IP binding.