Improving on DHCP

Fault tolerance, RFC 1542, and more

Last month, I talked about how Dynamic Host Configuration Protocol (DHCP)works. For those just joining us, DHCP simplifies setting up workstations onTCP/IP. You just set up a Windows NT Server machine as a DHCP server, tell itabout your network, and your NT server can hand out unique IP addresses to eachPC on your network, greatly simplifying IP setup. The server assigns theseaddresses for a limited time, so DHCP clients (PCs that get IP addresses fromDHCP servers) lease their addresses.

DHCP is a terrific facility, with a few quirks. However, if you understandthem, you can work around them.

A New Lease
When learning DHCP, you wonder what happens when thelease runs out. Well, you're supposed to stop using the IP address. But thelease is not likely to run out. When it's half over, the DHCP client beginsrenegotiating the IP lease by sending a DHCP request to the server that issuedthe expiring IP address.

The DHCP server responds with a DHCP ACK. It contains all theinformation--domain name, DNS server, etc.--that the original DHCP ACK had. Thisinformation lets you change the Domain Name System (DNS) server, WindowsInternet Name Service (WINS) server, subnet mask, and the like, and the newinformation will periodically be updated at the clients (you can specify aperiod, but it can be no more than 50% of the lease time).

Well, you can change the information in theory. Sometimes DHCP ACKdoesn't work. Suppose you renew the lease, but the server doesn't transfer newinformation to the workstations. Your best bet is to open a command line andtype ipconfig/release and then ipconfig /renew. (No, I don't know why it doesn'talways work, but I can show you Network Monitor captures where it doesn't, andthese captures led me to the release/renew technique.)

Now, if the DHCP ACK doesn't appear, the DHCP client keeps resending theDHCP request every two minutes until the IP lease is 87.5 percent expired.(Don't you wonder where Microsoft gets these numbers?) Then the client goes backto the drawing board, broadcasting DHCP discover messages (requests for an IPaddress) until someone responds. If the lease expires, the client will stopusing the IP address, disabling the TCP/IP protocol on that workstation.

Fault Tolerance
That possibility leads me to wonder about faulttolerance. Can a backup DHCP server hand out IP addresses if the primary goesdown? Not really, unfortunately. On the same subnet, you absolutely cannot runtwo DHCP servers that assign addresses from the same range.

However, on the same subnet, you can have two DHCP servers thatassign addresses from different ranges. Suppose you have a C network,200.100.100.0, and DHCP will give out addresses 200.100.100.20 through 200.100.100.120. You can run two DHCP servers on the subnet and let one distributeaddresses .20 through .90 while letting the other pass out .91 through .120.

Notice that you create two scopes (ranges of IP addresses on asubnet) that do not overlap. If they overlap, you run into trouble, because youhave no way to make two DHCP servers coordinate which addresses to give out.Telling both servers to assign addresses in the entire .20 through .120 rangeand to talk to each other to make sure they don't give out the same address totwo clients would be nice. But that's not possible--yet (probably, Cairo, theversion of NT that will likely appear in 1998 will let you). So, you can createtwo DHCP servers on a subnet and give them scopes that don't overlap. If oneDHCP server is down when a workstation needs a lease, another one (you hope!)has an address to spare.

What happens if two machines get the same IP address? DHCP avoids that.Right after a DHCP client gets an IP lease, it tests the lease by trying to senda message to the address. A response means the DHCP server gave the client anaddress that someone else is using. The client's response is to tell the userthat it received a duplicate IP address, and then to stop using TCP/IP. Thisapproach has always seemed odd to me--why not negotiate further with the DHCPserver to get an acceptable address?

RFC1542
DHCP can simplify the IP assignment problem for eachsubnet, and you can create a weak kind of fault tolerance with multiple DHCPservers per subnet, but gosh, that sounds like a lot of servers! If a DHCPserver doesn't have to be physically on the same subnet that it serves, you candedicate a couple of machines to handing out DHCP addresses, and they can serveall your network's subnets.

You can do that, at least in theory. Recall how DHCP works. Aworkstation broadcasts a discover message. A DHCP server responds with an IPaddress in an offer message. The workstation accepts the offer and isready to go. But wait­if the initial "gimme an IP address"message is a broadcast, how can a DHCP server on another subnet hear it?A router (or perhaps several routers) has to retransmit that broadcast for theDHCP server to hear it in the first place, and most routers don't retransmitbroadcasts!

The answer is in a Request for Comments (RFC) concerning DHCP or, rather, apredecessor to DHCP, bootp. RFC 1542 describes how a router can recognize thespecial broadcasts a DHCP client generates, so that the router knows toretransmit those broadcasts. To create DHCP servers that serve clients fromacross routers, the routers must run software to make them RFC 1542 compliant,or the routers must support bootp forwarding--both phrases mean the same. Ifyour routers won't cooperate, yes, you must have at least one DHCP server oneach segment that you want to put DHCP clients on.

If you're running the NT 4.0 beta or have installed Service Pack 4(ftp.microsoft.com/bussys/winnt/winntpublic/fixes/usa/NT351/ussp4) on NT 3.51,either NT Server or Workstation can be an IP router. Also, with theMulti-Protocol Routing (MPR) in the Service Pack 4 directory or with any versionof NT 4.0, you can enable bootp forwarding. In theory, that ability means youcan make an NT machine into an IP router that supports bootp forwarding, but mysuccess with getting NT bootp forwarding has been uneven. If you experiment withit, remember that if one DHCP server is providing addresses to multiple subnets,you'll need one scope for each subnet. (The DHCP server will not let you createmultiple scopes on one subnet on a given server--you can have multiple scopes onone subnet, but you need separate machines running DHCP server to do it.)

Another consideration: If a DHCP server serves several subnets and itsadjacent routers support bootp forwarding, the server must expect to receiveDHCP discover broadcasts from any one of those subnets. So how does the DHCPserver know which subnet the broadcast came from--how does the serverknow which subnet range to draw from when assigning an IP address to a client?

The answer lies in how bootp forwarding works. A bootp forwarding-enabledrouter will retransmit (forward) a DHCP discover broadcast. But when this routerforwards the broadcast, it adds data, a note saying, "To anyone who hearsthis: This is a broadcast that I originally found on a different subnet, subnetx.y.z.a." Then, if a DHCP server receives a broadcast that wasretransmitted over one or more routers, the server will know what subnet todirect the response back to and which scope to pull a number from for its offer.

So these are the main DHCP quirks and how to work around them. For moreinformation about DHCP, see "Implementing and Administering DNS," page121, and John Enck, "Take a Number," October 1995.