DHCP - Problems, Resources

Last week we started into the mysteries and magic that underlie Dynamic Host Configuration Protocol. This week, before we get back into the topic, Gearhead believes we have solved Gibbs' problem with his HP Pavilion 8485Z.

Gibbs had switched off the hardware acceleration and found that the video lock-up problem apparently stopped. Gearhead, in a moment of idle fooling around, and with a whisper from the hardware gods, tried something else. We changed the refresh rate from the default for the screen to the default for the built-in ATI graphics card, switched hardware acceleration back on and voila! No problems yet.

If you, gentle reader, should have even the vaguest explanation of why this should work (and note that the explanation must not include references to moon phases, lay lines or metaphysical forces), Gearhead would be most interested in knowing.

Let's assume you have set up your DHCP server (Windows NT, NetWare, Unix) and things aren't right. A machine can't get on, complains that its address is being used - the kind of stuff that just ticks you off.

Some (older) DHCP servers do not test IP addresses to see if they are in use before assigning the addresses to clients. Testing lets the server detect "rogue machines" that may have hijacked IP addresses before an IP address conflict could occur. Run an IP address scanner to see if you have conflicts (you should preferably use a computer with a static IP address to minimize potential problems), and check the DHCP server's log.

A conflict could easily occur if, as we discussed last week, you have redundant DHCP servers at either end of a WAN connection. If the servers handle what is, effectively, one address space that can be allocated even if the link fails, when the link is re-established you could have the problem of duplicate allocation.

This particular problem is not something that is handled by any DHCP server Gearhead knows of and is easily cured by better network design - the wise choice would be to use subnets at either end.

Most of the problems you encounter with DHCP revolves around issues of network design. As always, good diagnostic tools will save your bacon.

Some resources for your DHCP delectation: First, DHCP.org at www.dhcp.org/index.html. Despite being a little long in the tooth, this is a repository of all the basics you need to know about DHCP. This site also points to the key requests for content for DHCP: RFC 2131 "Dynamic Host Configuration Protocol" and RFC 2132 "DHCP Options and BOOTP Vendor Extensions."

There is also a good frequently asked questions page at www. dhcp-handbook.com/dhcp_faq.html (although it is dated 1998).

If you want to get down and dirty with code, check out the Internet Software Consortium's site at www.isc.org/ products/DHCP/, wherein you will find freely redistributable reference implementations of a DHCP server, client and a relay agent.

Next week: Who knows? Dynamically configure your thoughts to Gearhead at gh@gibbs.com.