RFC1542
DHCP can simplify the IP assignment problem for each
subnet, and you can create a weak kind of fault tolerance with multiple DHCP
servers per subnet, but gosh, that sounds like a lot of servers! If a DHCP
server doesn't have to be physically on the same subnet that it serves, you can
dedicate a couple of machines to handing out DHCP addresses, and they can serve
all your network's subnets.
You can do that, at least in theory. Recall how DHCP works. A
workstation broadcasts a discover message. A DHCP server responds with an IP
address in an offer message. The workstation accepts the offer and is
ready to go. But waitif 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 the
DHCP server to hear it in the first place, and most routers don't retransmit
broadcasts!
The answer is in a Request for Comments (RFC) concerning DHCP or, rather, a
predecessor to DHCP, bootp. RFC 1542 describes how a router can recognize the
special broadcasts a DHCP client generates, so that the router knows to
retransmit those broadcasts. To create DHCP servers that serve clients from
across routers, the routers must run software to make them RFC 1542 compliant,
or the routers must support bootp forwarding--both phrases mean the same. If
your routers won't cooperate, yes, you must have at least one DHCP server on
each 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 the
Multi-Protocol Routing (MPR) in the Service Pack 4 directory or with any version
of NT 4.0, you can enable bootp forwarding. In theory, that ability means you
can make an NT machine into an IP router that supports bootp forwarding, but my
success with getting NT bootp forwarding has been uneven. If you experiment with
it, 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 create
multiple scopes on one subnet on a given server--you can have multiple scopes on
one subnet, but you need separate machines running DHCP server to do it.)
Another consideration: If a DHCP server serves several subnets and its
adjacent routers support bootp forwarding, the server must expect to receive
DHCP discover broadcasts from any one of those subnets. So how does the DHCP
server know which subnet the broadcast came from--how does the server
know 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-enabled
router will retransmit (forward) a DHCP discover broadcast. But when this router
forwards the broadcast, it adds data, a note saying, "To anyone who hears
this: This is a broadcast that I originally found on a different subnet, subnet
x.y.z.a." Then, if a DHCP server receives a broadcast that was
retransmitted over one or more routers, the server will know what subnet to
direct 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 more
information about DHCP, see "Implementing and Administering DNS," page
121, and John Enck, "Take a Number," October 1995.