Administering the IP addresses of all the hosts on your network has always been a major task, but with the advent of IP telephony and the increase in mobile workers travelling from site to site, the emphasis on getting this right has become more important. We look at some DHCP implementation guidelines.
The device acting as your DHCP server could be your Windows 2000 server, a router, or a proprietary IP address allocation or management package such as Lucent’s VitalQIP or Cisco Network Registrar. Regardless, you need to think about resilience and where you’re going to install the servers.
For redundancy, you probably need to have two DHCP servers. Most desktop OS's can cope pretty well with not getting a reply to a DHCP request, in that they will continue to use the address they had, at least until the lease expires, giving you time to sort out a failure. Unless you still have any OS/2 devices which have the unpleasant trait of resorting to an all-zeros address and behaving in a rather unfriendly manner. However, better safe than sorry, and no good network design includes single points of failure where they can possibly be avoided.
With two servers, you can either split DHCP scopes across them, or cluster the servers (using for example Windows clustering if you’re opting for the Microsoft DHCP service). If you split scopes over multiple servers, all you need to do is exclude the ranges of addresses from one server that another will be responsible for. You can use both methods for even greater resilience: this might be a good option for geographically dispersed sites, where under normal circumstances, users will get their IP addresses locally, but should the server(s) on-site fail, there’s another backup. This level of complexity is probably overkill for smaller sites though.
If you have lots of remote sites, you can have a DHCP server at each, but then the administration becomes an overhead you can live without. Centralised DHCP makes for easier management, but you’ll have to factor in WAN bandwidth requirements and ensure that your routers are configured to pass DHCP requests (broadcasts) across. As you’ll obviously also have to do where you have multiple subnets all being served by the one server.
Think about the lease times you want to use - if your users don’t move about much, or you have a wealth of addresses, you can afford a relatively long lease time. For more mobile environments, it makes sense to shorten the lease times.
There are lots of options available within the DHCP reply that you can make use of, apart from just the default router address. These are detailed in RFC 2132, and include domain name, DNS servers, boot image location, TFTP, NNTP or Web server address, TTL value, MTU size or even static routes. Most of these aren’t all that widely used, but it’s worth seeing what’s available and if you can use it to make your life easier.
If you don’t like the element of chance that is associated with the server dishing out IP addresses more or less at random, then you can manually bind IP addresses to MAC addresses. However, this is very time-consuming, prone to errors and won’t scale for a mobile workforce. What you might do as a compromise is set this up for clients that won’t be changing much (such as servers) as an alternative to manually configuring address information on the servers themselves. Remember to exclude those addresses from the scope of addresses to be dynamically assigned, and if you have to change NICs, you’ll have to remember to update your DHCP configuration too.
You’ll want to run a system that supports dynamic DNS (RFC 2136) to allow the DHCP servers or clients to update your DNS server with IP address and hostname so if the IP address changes, users can still get to it. This is relatively straightforward when it’s one package that does both DHCP and DNS - for security, you can run secure DNS (an IETF draft at present) to ensure only authorised hosts can update the server, if the two aren’t inherently linked.
Security and Management
There are concerns regarding the ease with which someone can connect to a network if DHCP is enabled - just plug in, get an IP address and you’re away. While that’s true, there are various security measures you can take to alleviate the risks this might cause, such as configuring dynamic VLANs based on 802.1x, or using IDS probes to detect and stop intruders doing anything they shouldn’t.
Similarly, some people like the certainty of knowing which IP address goes with which device, at all times. Again this can be understood, but the huge burden of manually administering potentially thousands of devices, which may be moving from site to site on a regular basis, makes DHCP really the only option. Besides, network management applications, such as Enterasys’s Spectrum or CiscoWorks User Tracking, are available to automatically map IP addresses or MAC addresses to switch ports so that you can track users down for troubleshooting.
DHCP may have some shortcomings but it’s still by far the best option when it comes to administering your IP address estate.