Introduction

Dynamic Host Configuration Protocol (DHCP) is often used on networks to allow end devices to automatically retrieve their network configuration when they first connect to the network. It basically expands on the earlier Bootstrap Protocol (BOOTP) and uses the same UDP ports, numbers 67 and 68. The protocol itself is defined in RFC 2131, and the configuration options are defined in RFC 2132.

The most common application for DHCP is to automatically set up IP addresses, netmasks, and default gateways for end devices. However, the protocol can also configure many other options, such as DNS servers, domain names, time zones, NTP servers, and many others. Some software vendors have even added their own configuration options to automatically set up key applications on end devices.

DHCP makes it possible to give a minimal common configuration to all user workstations. You can simply plug the device into the network at any point, and DHCP will take care of getting an IP address that will work at that location. This minimizes errors due to manual configuration, centralizes control over configuration information, and greatly reduces technician costs because anybody can connect a device to the network.

There are three distinct element types in a DHCP network. There must be a client and a server. If these two elements are not on the same Layer 2 network, there also must be a proxy, which usually runs on the router. The proxy is needed because the client device initially doesn't know its own IP address, so it must send out a Layer 2 broadcast to find a server that has this information. The router must relay these broadcasts to the DHCP server, then forward the responses back to the correct Layer 2 address so that the right end device gets the right configuration information.

Historically, the router's only role in BOOTP or DHCP was this proxy function. However, Cisco has recently added both DHCP client and server functionality. This chapter will show configuration examples for all three of these functions, but many of the recipes will focus on complex server configurations.

A DHCP exchange starts with a client device, such as an end user workstation. Typically, this device will boot and connect to the network with no preconfigured network information. It doesn't know its IP address, the address of its router, its subnet, or netmask. It doesn't even know the address of the server that will provide these pieces of information. The only thing it can do is send out a UDP broadcast packet looking for a server.

Most DHCP networks of any size include two or more DHCP servers for redundancy. The end devices typically just need to talk to a DHCP server at startup time, but they will not work at all without it. So redundancy is important. This also means that it is not unusual for an end device to see several responses to a DHCP request. It will generally just use the first response. However, this also underscores the importance of ensuring that all of the DHCP servers distribute the same information. Their databases of end device configuration parameters must be synchronized.

The end device requests configuration information from one of the servers. It must specify exactly what options it requires. The server does not need to respond to all of the requested options, but it cannot offer additional unrequested information to the client, even if it has additional information in its database. This is an important detail to remember—it can be very confusing when an end device has some manually configured options that are not replaced by the information on the server.

Since duplicate IP addresses can cause serious problems on a network, most DHCP servers track address conflicts. They do this by attempting to ping each IP address before telling an end device that it is safe to use the address. Many DHCP clients will also double-check that the address is not already in use by sending an ARP request before using it. However, neither of these checks is mandatory, and some DHCP clients and servers do not check before using an address.

One of the important features of DHCP is the ability to allocate IP addresses for a configurable period of time, called the lease period. If a client device wants to keep its IP address for longer than this period, it must renew the lease before it expires. Clients are free to renew their leases as often as they like.

The server can allocate IP addresses from a pool on a first-come, first-served basis, or it can associate IP addresses with end device MAC addresses to ensure that a particular client always receives the same address.