| Legal Information |
|
DHCP makes the life of a network administrator easier by automating the process of assigning IP address information to clients on your network. Servers should generally have static addresses instead of dynamic ones. However, using DHCP on your network introduces a point of failure--for what if your DHCP server suddenly dies?
With Windows 2000 and later this can be a problem because if the machine is configured as a DHCP client and its lease expires, it tries to renew its lease by communicating with a DHCP server on the network.
If no DHCP server can be found, however, the client uses Automatic Private IP Addressing (APIPA) to auto-assign itself an IP address from the reserved address range 169.254.0.0 to 169.254.255.255. And when this happens, the client can no longer communicate with other machines on the network unless they have addresses from the same range. This is a good reason why you should disable APIPA on your Windows 2000 or Windows XP client machines, if you plan on using DHCP on your network.
Because DHCP servers are so important for ensuring network communications, however, it's also a good idea to take measures to ensure their availability. To begin with, this means using high-availability hardware platforms that have RAID 0+1, hot swappable drives and power supplies, and other forms of hardware fault tolerance for your DHCP servers. This way if a power supply dies or a drive fails, you can have your DHCP server up and running again in minutes. The moral is don't skimp on hardware costs for servers that your whole network depends on.
Clustering might seem like another option, but you have to be careful here. A Windows 2000/2003 clustered DHCP server is considerably more complicated to set up than a standard DHCP server, and the hardware requirements are higher as well. Additionally, not many companies can afford the resources to dedicate a server cluster to the simple job of leasing IP addresses for their network.
Forget 80/20A common method for ensuring DHCP server availability is to install two DHCP servers on your network and use something called the 80/20 rule. The idea behind this rule is as follows:
Next, you make sure that the available addresses on server 1 are sufficient for all DHCP clients on the local subnet, and place server 2 on a neighbouring subnet. When a client tries to renew its lease by sending out a DHCP Renew message, this message typically reaches the DHCP server on the local subnet (server 1) first. But if server 1 is down then the DHCP server on the other subnet (server 2) can act as backup (provided your router is configured for BOOTP forwarding so it acts as a DHCP relay agent to pass DHCP broadcast traffic from one subnet to the next).
For the other subnet you do the opposite; that is, server 2 provides 80 percent of the addresses for the subnet it resides on and server 1 provides 20 percent for the same subnet.
The idea behind splitting the addresses 80/20 is because the 80 percent of addresses is normally sufficient for all the addresses needed on a subnet, and DHCP leases are typically three days, so if your subnet's main DHCP server goes down for a few hours then it's unlikely that more than 20 percent of the machines on that subnet will need to renew their addresses during the downtime, making the 20 percent pool of addresses sufficient.
That holds true unless it takes longer than a few hours to get your failed DHCP server working again (for example, if it fails just after working hours and your network monitoring software fails to beep you on your pager). Or unless you've configured leases shorter than three days because your network is a classroom, a conference facility, or has a lot of mobile users who connect to it remotely.
Because of considerations like these, many network administrators prefer a more conservative 50/50 rule, which actually works even better in a single subnet environment anyway, provided both servers have enough addresses scoped to cover the needs of all the clients on the network. Then if one server goes down, the other one can take up the slack for as long as it takes to get the first one up and running again.
The typical way of implementing this is to use exclusions, for example:
Server 1But you can also simply configure the scopes separately as:
Scope 10.0.0.1 to 10.0.0.250
Exclusion 10.0.0.126 to 10.0.0.250
Server 2
Scope 10.0.0.1 to 10.0.0.250
Exclusion 10.0.0.1 to 10.0.0.125
Server 1 scope 10.0.0.1 to 10.0.0.125
Server 2 scope 10.0.0.126 to 10.0.0.250Just don't let the scopes overlap when you configure them. Other Solutions
If you're really paranoid about DHCP availability on your network, you can also configure a third DHCP server that mirrors the configuration of your 80 percent server, if you're using the 80/20 rule, or one of your 50 percent servers, if you're using 50/50.
Once you've configured this server, however, keep it disconnected from the network as a hot backup DHCP server. Then if your main DHCP server goes down you can bring the backup one online to take its place. In this scenario you might ask, "Why keep the 20 percent server if you have a hot backup?" The reason is, what if your 80 percent server dies during the night and you're not around to flip the switch and connect your backup to the network?
Unless you have sophisticated network management software that can handle this situation by bringing your spare 80 percent server online, some of your clients may be out of luck if they want to connect to the network before morning comes.
Here's another interesting approach: configure both DHCP servers on your network with identical scopes. Now, normally this would cause problems because you might end up having the same address leased by both servers, causing clients to hiccup. However, if you enable address conflict detection on your DHCP servers and set it to 2, then each DHCP server will test an address three times to make sure it's not already being used before leasing it to a client. This will prevent one server from leasing an address that the other server has already leased.
The only downside to this approach is that it will make DHCP traffic on your network a bit more noisy, but DHCP traffic is so minimal anyway this will have only marginal impact on overall network performance. But why not set this to one attempt instead of two attempts? Safety--you don't want a network glitch that causes brief packet loss to ruin your setup. To configure address conflict detection on a Windows 2000 DHCP server use the Advanced tab of the properties sheet for the server in the DHCP console (Figure 1):
Figure 1. Configuring address conflict detection on a DHCP server
Finally, a setup some companies prefer is to use DHCP but create a reservation for each and every client machine on the network. That way, whenever a client leases an address using DHCP it always receives the same address from the DHCP server.
How is this different from static addressing? Well, for one thing, you don't have to walk around to every machine on your network and manually configure its IP address settings. Instead, you can do it centrally on your DHCP server, provided you know the MAC addresses of every client on your network.
One way of doing that is to begin by configuring your DHCP server with no reservations and let it lease out addresses to all the clients on your network. Then run the netsh dhcp dump command on your DHCP server to dump the DHCP database, which gives you the IP address and MAC address of each client machine.
Then, with a little ingenuity, you could write a script that uses the netsh dhcp add reservedip command to take your dumped DHCP database and create reservations for all your clients using the presently leased IP addresses. Of course, if you want clients to have specific IP addresses instead of a randomly assigned one, then you've got a lot more work ahead of you!
Why on earth would anyone want to use this all-reserved approach? Better security. Since each client always has the same IP address, it's easier to interpret address information in your firewall logs. And since you're still using DHCP you can easily make changes to your default gateway and other TCP/IP settings. You can do this without opening up the possibility of clients changing their addresses in the process.
Finally, ensuring clients always have the same address makes it easier to track the Internet usage of each user, if your company has a policy that requires this to be done.
| Search Knowledge Base | Feedback |
