• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Chapter 8.2. Dynamic Host Configuration ... > Frequently Asked Troubleshooting Que...

Frequently Asked Troubleshooting Questions

To wrap up this coverage of DHCP and lay some common misunderstandings and "gotchas" to rest, here are a number of questions and answers regarding DHCP:

Question:I thought that Windows 2000 prevents rogue DHCP servers from being installed on my network and giving addresses to clients, but I found some clients that received addresses from an unregistered server. What's going on?
Answer:Windows 2000's version of DHCP prevents non-registered Windows 2000 servers from running the DHCP service on an Active Directory network. DHCP servers running NT 4.0 or some Unix variant will still be able to hand out addresses without authorization, however. This means that the efficacy of this security feature is quite limited. The client information will tell you which subnet the rogue server is on, and you will have to deal with the problem by finding the physical system and disabling the DHCP service on it.
Question:Assuming that leases are constantly being given out, they are also constantly expiring, and any server downtime will affect some clients. What happens then when the DHCP server becomes unavailable?
Answer:First, although leases are often given out, the most frequent activity on a stable DHCP network is actually lease renewals. On a network with a DHCP server online and with activated scopes, leases never expire because the DHCP server is always available to renew them anytime one reaches half its lease-life. If the DHCP server has not gone offline recently, every DHCP client in the network still has at least half its lease-life left. This means that if the scope's lease duration is set at three days and the DHCP server goes offline, no existing address leases will expire for at least 36 hours, or half the lease life. That is usually ample time to configure a replacement server if the original configuration was adequately documented.
Question:One of my users powered up their system on a Wednesday morning and got an IP conflict message, and now she has no network connectivity. There were no problems on Tuesday. I understood that between server-side and client-side conflict-detection, that was not supposed to be able to happen. Am I wrong?
Answer:If you think that IP conflict-detection will prevent all IP conflicts, yes, you are wrong. Conflict-detection only keeps the DHCP server from giving out an address that is already in use on the network, and both the client and the server are only able to detect a conflict through active, real-time probing. If another system has a duplicate IP address but is powered down, it is not detected. Your client will get the IP address, but when that other system is brought online, the IP conflict will rear its ugly head. What must have happened to your user is that someone manually configured a conflicting address on another system and brought the system online before your troubled user's system was brought online. Because your user's system already had a valid lease, no new conflict-detection was involved. Address renewal does not invoke the conflict-detection measures.

To take care of this problem, use ipconfig /release to release the client's IP address. This alone is not enough because the client does not actually have any network connectivity at this point to tell the server to remove its lease from the Active Lease list. As the administrator, you then have to delete that client system's lease from the DHCP server's Active Leases list. After those two things are done, reboot the client system. When it comes back online, it will broadcast a request for a DHCP address and the DHCP server will provide a new and different IP address.

Question:I think that the server running the DHCP service in my network is behaving erratically. What are my options for fixing it?
Answer:You might try compacting the database to fix any corruption that may be causing problems. If that does not work, you can back up the database and the Registry keys. Then, remove and reinstall the DHCP service, an easy variation on what was described in the "Moving the DHCP Database to a New Server" section. After doing this, reinstall whichever Service Pack you are currently running. This should solve any file problems if the trouble is not with the database itself.

If problems persist, it might be best to start relatively fresh; consider rebuilding DHCP on a different server. Leave the existing DHCP server online, but install the DHCP service on a new server and configure it using the console, from which you can view the configuration on both servers. Manually configure the new server with the same scope ranges and scope options that the original DHCP server had (provided they were not the source of your troubles), making sure to note any exclusions and reservations. Ensure that the scopes on the new server are deactivated until you are ready to bring clients on to it. When you are ready, activate the scopes on the new server and deactivate the scopes on the old server. Do not delete the scopes on the old server! When clients try to renew their leases on the old server, it will issue NACKs to them because of the presence of the deactivated scopes. It will force the clients to the new server for their leases. By the time half of the lease time has passed, you should see most of your clients in the Active Leases list on the new server.

Question:I made a reservation for a particular host on my network, and it keeps managing to get a different IP address than the one I reserved for it. What might be the cause?
Answer:Could be several things. First, if there is another DHCP server somewhere in your enterprise that is providing addresses for the subnet that your host is on, it had better have the same reservation configured. Otherwise, it might be supplying your host with illicit addresses. The big tipoff is the fact that the host in question will not show up in the Active Leases list on the server you expected to see it on.

Second, are you sure you did not make a typo when you specified the MAC address of the host? If you did (it is easy to do!), that reservation will never stick. It is possible to get the MAC address of a host by going to the Active Leases list and double-clicking an individual entry. You can do a Copy and Paste to get that exact number into the reserved address field. Alternately, if you are on the same subnet as the host, you can ping the host and then copy the MAC address of the host from your local ARP cache.



Not a subscriber?

Start A Free Trial

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint