DHCP in a Cloud Enabled World by Erik Lofstrand

imageIn a surprising number of our private cloud engagements we have run into an unexpected roadblock: Lack of DHCP.  Having spent a previous life in the dotcom days as a network engineer, I was really surprised to see today, as organizations and networks have matured, automation of IP assignment has not. image

Now, the first caveat to this post is that ultimately the decision is up to the customer.  Our best practices might not be suitable for your organization.  The second caveat is that automation in a cloud, means automation across the board.  You can’t deploy a cloud architecture with manual dependencies.  Particularly in something as critical, and central as network connectivity. 

This article is going to address the major resistance points customers have regarding DHCP and how a cloud focused organization can address them.  We will also provide the key configuration aspects of a healthy DHCP environment that address the concerns raised and provide a win-win scenario for the cloud endeavor.

The issue:

Overwhelmingly, the push back against DHCP falls into one of two main areas.  If there are others that you are faced with, we’d certainly like to hear about them.  There could certainly be cases where DHCP just doesn’t fit, but as you’ll see, there are ways to address them.  If DHCP is a complete show stopper in an organization, it could also be a telltale sign that your IO (infrastructure optimization) maturity is not ready to accommodate a cloud architecture. 

This is not a bad thing, Core IO maturity takes a lot of effort and an organization dedicated to its success.  Moving to a private cloud is also a process that challenges what IT organizations are used to doing.  If you’re not familiar with the Microsoft Core IO model, or for more information click here.

Issue 1
The vast majority of customers we work with who have a policy against DHCP usually have this response when asked why:  “We tried to leverage DHCP… There were lots of problems… It never worked properly… It made the entire environment (read their job security) less stable”

Issue 2
In a close second place is IP address management (IPAM).  Particularly in large organizations, IP address assignment is a different team’s, if not an entirely different organization’s from the infrastructure ownership that would be responsible for the DHCP service.  There are tools out there that handle IP Address Management, including a new feature in the upcoming release of Windows.  The reality we’ve seen, all too often, is that there just isn’t a workable solution for IPAM.  The really good ones are expensive, so companies don’t often buy them.  The main tool used in a lot of organizations for IPAM is Excel.  This highlights why DHCP would be blocked from being used.  Organizations that have to rely on tools like a spreadsheet for IPAM, can’t have DHCP running around handing out addresses for them.

So what’s the solution?  We’ll get to that in a minute, but in the interest of full disclosure we should point out the pros and cons of DHCP.  If you are facing this dilemma, this information should allow you to make an informed decision either way.

DHCP Pros:

So in searching for reliable sources to compile this list, maybe the most pertinent piece of information for you is that there really weren’t any.  Most of the information compiled here was found in various forums and other places around the web, so take it all with a grain of salt.  The goal here is to understand the necessity of DHCP in a cloud enabled environment, so pros and cons are presented to make that case with your internal teams.

The one source that I will give the most credit to is TechNet.  Not that Microsoft said it, but that someone actually sat down to provide something other than opinion.  From here the main benefits of DHCP are :

  • Reliable IP address configuration. DHCP minimizes configuration errors caused by manual IP address configuration, such as typographical errors, or address conflicts caused by the assignment of an IP address to more than one computer at the same time.
  • Reduced network administration. DHCP includes the following features to reduce network administration:
    • Centralized and automated TCP/IP configuration.
    • The ability to define TCP/IP configurations from a central location.
    • The ability to assign a full range of additional TCP/IP configuration values by means of DHCP options.
    • The efficient handling of IP address changes for clients that must be updated frequently, such as those for portable computers that move to different locations on a wireless network.
    • The forwarding of initial DHCP messages by using a DHCP relay agent, which eliminates the need for a DHCP server on every subnet.

Some other benefits pulled from elsewhere:

  • IT Automation requires IP automation
    DHCP is a straightforward way to dynamically provision machines with an IP address.
    Other automation tools, like PXE, leverage DHCP
  • Better DNS Integration. 
    One of the caveats to assigning static IPs addresses in the datacenter was DNS.  If I need to reach a server by name, the DNS record and IP address could be different.  Fortunately, dynamic DNS has matured along with DHCP and the two, particularly in a Windows environment work very well and maintaining the correct information.  In practice, we don’t see issues here today.
  • Enables Flexibility.  
    As pointed out above, dynamic addressing creates portability of machines across subnets.  This can be particularly important in clouds that serve dev and test functions that need to be moved between different subnets.
  • Potential Cost Savings. 
    By eliminating the manual task of managing, assigning, and troubleshooting IP conflicts, overburdened IT shops can focus their time on other priorities.
  • Baseline for the Future of IPv6. 
    With IPv6 around the corner, managing a static IPv6 infrastructure will be daunting for even the brightest IP Gurus in the business.  I could probably still recount the entire IP nomenclature I managed back in the day.  Ask me to scale that by 4 times (32 bit IPv4 vs 128bit IPv6 addresses) and I give up.  Building and managing a DHCP infrastructure today will prepare you for the evolution to IPv6 in the future.

DHCP Cons:

There is always a downside to any technology.  Here are some for DHCP, mostly compiled from talking with customers, but also found the same in various forum sites.

  • DHCP is not secure. 
    So the argument is this, if I allow any device to connect to my network to receive an IP address my network security is compromised.  While this is a true statement, my personal opinion is that your network security was compromised before the IP address was assigned by allowing an unauthorized user to connect in the first place.  But security is a flag often raised, so you need to understand the concern.
  • DHCP adds network complexity. 
    Building and maintaining a resilient DHCP infrastructure requires planning, testing, maintenance and support.  All of these things add costs to the network both in hard dollars and IT resources.
  • DHCP creates an additional failure point in the datacenter. 
    If a server does not receive an IP address, critical services could become unavailable.
    DHCP becomes a critical service, and must be restored immediately in a DR / Business Continuity scenario.
  • DHCP becomes an IP black box.   
    By allowing dynamic IP addresses, how am I supposed to keep my memorized list of server addresses intact?  
    The networks I managed all had static addresses, at least partly for this reason.

The Solution:

So if DHCP is so necessary in building a cloud, and we are more comfortable, in theory, with static IP addresses, how do we solve this problem?  The answer is to do both.  Leverage DHCP in your environments that have a need for it.  We already do this on most desktops.  For critical services like DHCP, DNS and Active Directory, use static addresses to protect the key components of the environment.  For the same reason, there are a lot of best practices around keeping a portion of these services running on physical hardware as well.

And for the other services, particularly those running in your cloud?  Leverage DHCP, with IP address reservations.  So the key in every conversation with customers that overwhelmingly addresses issue number 2 above is that they now can leverage better tools than Excel to manage IP addresses and still have 100% control over which server gets what address.  This fits perfectly into automation scenarios as well.

A common OS deployment from bare metal would follow this path:


The figure shows the following process flow: request submitted with MAC address from vendor manifest >> Routed to IPAM team for address assignment and approval >> orchestration engine provisions DHCP reservation >> Orchestration engine provisions machine

Additionally, the IPAM team can get reservation data via Powershell from Windows DHCP servers.  While there is not native module prior to the next release of Windows, scripts like this show how it can be done.  This can also be integrated in the orchestration so that the workflow reports back to the IPAM team on a regular basis reservation data like when an address was last used.  This will give them the ability to proactively manage their IP pools better than before and could still even use Excel as their interface.  Decommissioning of IP Addresses would work just as easily, by reversing the workflow logic. 

Once a machine is deprovisioned, the orchestration engine would remove the reservation from DHCP and report back to the IPAM Team that it is now available.  Some additional steps might include DNS updates, leveraging static MAC addresses in a virtualized environment, and any network device provisioning such as firewall rules or router table entries.  All-in-all, DHCP with reservations gives the stability and control of static addresses but in an automated fashion that is conducive to cloud deployment strategies.

One more key part of this solution is the resiliency of the DHCP infrastructure.  The majority of reasons behind issue #1 above boiled down to DHCP not being a first class network citizen.  Poor architecture, poor infrastructure, poor maintenance all were the root causes for instability in DHCP environments.  First, DCHP needs to be designed and implemented properly.  This includes designing for failure scenarios to minimize risk to the environment. 

It also means that the infrastructure teams and the network teams must collaborate to ensure that the network devices are set to forward DHCP packets around the network.  Unless there is a DHCP server in each and every subnet in an organization, you will need to enable IP helpers on your routers.  This is a must have for a healthy DHCP environment.

Below are a few best practices pulled from an older TechNet article for Windows 2003, but nonetheless still relevant:

  • Use the 80/20 design rule for balancing scope distribution of addresses where multiple DHCP servers are deployed to service the same scope.
    Using more than one DHCP server on the same subnet provides increased fault tolerance for servicing DHCP clients located on it. With two DHCP servers, if one server is unavailable, the other server can take its place and continue to lease new addresses or renew existing clients.
    A common practice when balancing a single network and scope range of addresses between two DHCP servers is to have 80 percent of the addresses distributed by one DHCP server and the remaining 20 percent provided by a second. For more information and an example of this concept, see Configuring scopes.
  • Use superscopes for multiple DHCP servers on each subnet in a LAN environment.
    When started, each DHCP client broadcasts a DHCP discover message (DHCPDISCOVER) to its local subnet to attempt to find a DHCP server. Because DHCP clients use broadcasts during their initial startup, you cannot predict which server will respond to the DHCP discover request of a client if more than one DHCP server is active on the same subnet.
    For example, if two DHCP servers service the same subnet and its clients, clients can be leased at either server. Actual leases distributed to clients can depend on which server responds first to any given client. Later, the server first selected by the client to obtain its lease might be unavailable when the client attempts to renew.
    If renewal fails, the client then delays trying to renew its lease until it enters the rebinding state. In this state, the client broadcasts to the subnet to locate a valid IP configuration and continue without interruption on the network. At this point, a different DHCP server might respond to the client request. If this occurs, the responding server might send a DHCP negative acknowledgement message (DHCPNAK) in reply. This can occur even if the original server that first leased the client is available on the network.
    To avoid these problems when using more than one DHCP server on the same subnet, use a new superscope configured similarly at all servers. The superscope should include all valid scopes for the subnet as member scopes. For configuring member scopes at each server, addresses must only be made available at one of the DHCP servers used on the subnet. For all other servers in the subnet, use exclusion ranges for the same scope ranges of addresses when configuring the corresponding scopes.
    For more information, see Using superscopes.
  • Deactivate scopes only when removing a scope permanently from service.
    Once you activate a scope, it should not be deactivated until you are ready to retire the scope and its included range of addresses from use on your network.
    Once a scope is deactivated, the DHCP server no longer accepts those scope addresses as valid addresses. This is only useful when the intention is to permanently retire a scope from use. Otherwise, deactivating a scope causes undesired DHCP negative acknowledgement messages (DHCPNAKs) to be sent to clients.
    If the intent is only to affect temporary deactivation of scope addresses, editing or modifying exclusion ranges in an active scope achieves the intended result without undesired results.
    For more information, see Manage Scopes.
  • Use server-side conflict detection on DHCP servers only when it is needed.
    Conflict detection can be used by either DHCP servers or clients to determine whether an IP address is already in use on the network before leasing or using the address.
    DHCP client computers running Windows 2000 or Windows XP that obtain an IP address use a gratuitous ARP request to perform client-based conflict detection before completing configuration and use of a server offered IP address. If the DHCP client detects a conflict, it will send a DHCP decline message (DHCPDECLINE) to the server.
    If your network includes legacy DHCP clients (clients running a version of Windows earlier than Windows 2000), you can use server-side conflict detection provided by the DHCP Server service under specific circumstances. For example, this feature might be useful during failure recovery when scopes are deleted and recreated. For more information, see DHCP Troubleshooting.
    By default, the DHCP service does not perform any conflict detection. To enable conflict detection, increase the number of ping attempts that the DHCP service performs for each address before leasing that address to a client. Note that for each additional conflict detection attempt that the DHCP service performs, additional seconds are added to the time needed to negotiate leases for DHCP clients.
    Typically, if DHCP server-side conflict detection is used, you should set the number of conflict detection attempts made by the server to use one or two pings at most. This provides the intended benefits of this feature without decreasing DHCP server performance.
    For more information, see Enable address conflict detection.
  • Reservations should be created on all DHCP servers that can potentially service the reserved client.
    You can use a client reservation to ensure that a DHCP client computer always receives the same IP address lease at startup. If you have more than one DHCP server reachable by a reserved client, add the reservation at each of your other DHCP servers.
    This allows the other DHCP servers to honor the client IP address reservation made for the reserved client. Although the client reservation is only acted upon by the DHCP server where the reserved address is part of the available address pool, you can create the same reservation on other DHCP servers that exclude this address.
    For more information, see Add a client reservation.
  • For server performance, note that DHCP is disk-intensive and purchase hardware with optimal disk performance characteristics.
    DHCP causes frequent and intensive activity on server hard disks. To provide the best performance, consider RAID solutions when purchasing hardware for your server computer that improves disk access time.
    When evaluating performance of your DHCP servers, you should evaluate DHCP as part of making a full performance evaluation of the entire server. By monitoring system hardware performance in the most demanding areas of utilization (CPU, memory, disk input/output), you obtain the best assessment of when a DHCP server is overloaded or in need of an upgrade.
    Note that the DHCP service includes several System Monitor counters that can be used to monitor service. For more information, see Monitoring DHCP server performance.
  • Keep audit logging enabled for use in troubleshooting.
    By default, the DHCP service enables audit logging of service-related events. Audit logging provides a long-term service monitoring tool that makes limited and safe use of server disk resources. For more information, see Audit logging.
    For more information on interpreting server audit log files, see Analyzing server log files.
  • Reduce lease times for DHCP clients that use Routing and Remote Access service for remote access.
    If Routing and Remote Access service is used on your network to support dial-up clients, you can adjust the lease time on scopes that service these clients to less than the default of eight days. One recommended way to support remote access clients in your scopes is to add and configure the built-in Microsoft vendor class provided for the purpose of client identification.
  • Increase the duration of scope leases for large, stable, fixed networks if available address space is plentiful.
    For small networks (for example, one physical LAN not using routers), the default lease duration of eight days is a typical period. For larger routed networks, consider increasing the length of scope leases to a longer period of time, such as 16-24 days. This can reduce DHCP-related network broadcast traffic, particularly if client computers generally remain in fixed locations and scope addresses are plentiful (at least 20 percent or more of the addresses are still available).
  • Integrate DHCP with other services, such as WINS and DNS.
    WINS and DNS can both be used for registering dynamic name-to-address mappings on your network. To provide name resolution services, you must plan for interoperability of DHCP with these services. Most network administrators implementing DHCP also plan a strategy for implementing DNS and WINS servers.
  • For routed networks, either use relay agents or set appropriate timers to prevent undesired forwarding and relay of BOOTP and DHCP message traffic.
    If you have multiple physical networks connected through routers, and you do not have a DHCP server on each network segment, the routers must be capable of relaying BOOTP and DHCP traffic. If you do not have such routers, you can set up the DHCP Relay Agent component on at least one server running Windows Server 2003 in each routed subnet. The relay agent relays DHCP and BOOTP message traffic between the DHCP-enabled clients on a local physical network and a remote DHCP server located on another physical network.
    When using relay agents, be sure to set the initial time delay in seconds that relay agents wait before relaying messages on to remote servers. For more information on DHCP relay agents, see DHCP/BOOTP Relay Agents.
  • Use the appropriate number of DHCP servers for the number of DHCP-enabled clients on your network.
    In a small LAN (for example, one physical subnet not using routers), a single DHCP server can serve all DHCP-enabled clients. For routed networks, the number of servers needed increases, depending on several factors, including the number of DHCP-enabled clients, the transmission speed between network segments, the speed of network links, whether DHCP service is used throughout your enterprise network or only on selected physical networks, and the IP address class of the network. For more information on determining how many DHCP servers to set up, see Planning DHCP networks.
  • For DNS dynamic updates performed by the DHCP service, use the default client preference settings.
    The Windows Server 2003 DHCP service can be configured to perform DNS dynamic updates for DHCP clients based on how clients request these updates to be done. This setting provides the best use of the DHCP service to perform dynamic updates on behalf of its clients as follows:
    • DHCP client computers running Windows 2000, Windows XP, or a Windows Server 2003 operating system explicitly request that the DHCP server only update pointer (PTR) resource records used in DNS for the reverse lookup and resolution of the client’s IP address to its name. These clients update their address (A) resource records for themselves.
    • Clients running earlier versions of Windows cannot make an explicit request for DNS dynamic update protocol preference. For these clients, the DHCP service updates both the PTR and the A resource records when the service is configured to do so.

For more information, see Using DNS servers with DHCP, Enable DNS dynamic updates for clients, and Configure DNS dynamic update credentials.

  • Use the manual backup and restore methods in the DHCP server console.
    Use the Backup command on the Action menu of the DHCP console to perform full backup of the DHCP service at an interval that protects you from significant data loss. When you use the manual backup method, all DHCP server data is included in the backup, including all scope information, log files, registry keys, and DHCP server configuration information (except DNS dynamic update credentials). Do not store these backups on the same hard drive upon which the DHCP service is installed, and make sure that the access control list (ACL) for the backup folder only contains the Administrators group and DHCP Administrator groups as members. In addition to performing manual backups, backup to other locations, such as a tape drive, and make sure unauthorized persons do not have access to your backup copies. You can use Windows Backup for this purpose. For more information, see Best practices for Backup.
    When restoring the DHCP service, use a backup created with the manual Backup command or a copy of the database created with synchronous backup by the DHCP service. In addition, use the Restore command on the Action menu in the DHCP console to restore a DHCP server.
    For more information, see Backing up the DHCP database and Restoring server data.
  • Follow the recommended process for moving a DHCP server database from old server computer hardware to new hardware.
    Moving a DHCP server database can be problematic. To manage moving the server database more easily, choose and follow a process tried and used by Microsoft Product Support Services such as the following:
  • Before you install a DHCP server, identify the following:
    • The hardware and storage requirements for the DHCP server.
      For more information, see Planning DHCP networks.
    • Which computers you can immediately configure as DHCP clients for dynamic TCP/IP configuration and which computers you should manually configure with static TCP/IP configuration parameters, including static IP addresses.
      For more information, see Checklist: Configuring TCP/IP.
    • The DHCP option types and their values to be predefined for DHCP clients.

The DHCP Design guide should also be leveraged in the planning.  To maintain a healthy DHCP environment, Microsoft has a Best Practices Analyzer along with a Management Pack for System Center Operations Manager.  With the same attention paid towards DHCP that is given to any other critical service of an organization, you will find that DHCP can provide many benefits and a considerable amount of consistency in our cloud enabled worlds.


For its detractors, DHCP is not perfect, but as part of the overall solution, it can provide a stable addressing infrastructure and leave IPAM teams in control of the organization’s address space.  If security is a concern for an organization, address the access vulnerability to your network access points with 802.1x or other controls, but DHCP is not the risk, and static IP addresses are not any more secure.  As the services that an IT organization provides become increasingly more dynamic, and deploying clouds in your organization becomes a reality, we need to make sure that the infrastructure evolves as well.  Dynamic IP addressing is a key component of this, and a well built, well managed DHCP environment will be a benefit to the organization.

Erik Lofstrand
US Private Cloud CoE Lead


Go Social with Private Cloud Architecture!
Private Cloud Architecture blog
Private Cloud Architecture Facebook page
Private Cloud Architecture Twitter account
Private Cloud Architecture LinkedIn Group
Private Cloud TechNet forums
TechNet Private Cloud Solution Hub
Private Cloud on the TechNet Wiki