DHCP is a very mature technology that has not changed much in many, many years Building a highly available

DHCP solution generally comes in two forms, 1) Clustering, and 2) Splitting Scopes. Let's cover the split-scope design first. While you may read about the 80/20 rule, what is more commonly implemented is a 50/50 rule. The 80/20 rule was more appropriate years ago, where you would have a design that would include a DHCP server at the remote site, and one at the main site. You would have 80% of the scope active at the remote site and 20% active at the main site. In today's modern networks, with good network links between sites, you would simply have two DHCP servers located at your main facility. In this case, you want to implement a 50/50 design. So, how do you implement this. You basically create the same scope range on both DHCP servers for each subnet you are servicing. On one server, you exclude the upper half of your range, and on the other server, you exclude the lower half of the range. This is done to ensure that you do not overlap IPs and the DHCP servers wont try to offer any conflicting IPs to the clients. This is important since both DHCP servers do not share their DB information with each other. In the case of a failure, there is not problem. The remaining DHCP server continues to respond to DHCP requests as normal. What is important is that if you have a range of 200 IPs available between both servers, try to limit your VLANs to about 100 hosts. This way, in the event of a failure, one DHCP server can handle 100% of the load. Step by step config.. See this article. Any questions about this, feel free to reply... The final part is to get your network configuration. If the DHCP servers are not on the same network segment as the clients (which they really shouldnt be or have to be), then on the VLAN that is servicing the clients, you'll need to configure the DHCP Relay Agent (also known as IP Helper) on the router. You point the relay agent to both DHCP servers. That's it. As the DHCP broadcasts are sent by your clients, the DHCP relay agent, converts those packets into unicast packets and sends them to the DHCP servers. The DHCP servers respond and the relay agent performs the reverse. So it acts like a proxy for these clients. If you want to read about the relay agent process read this article.

Load Balancing DHCP Using Split Scopes

Friday, October 28, 2011
DHCP is one of the networking services that can be very easily deployed in a fault-tolerant manner. Split-scopes are intended for scenarios where you need a highly available DHCP solution when servicing one or more subnets, but you don't want to deploy a complex DHCP cluster design. Clustering requires a shared storage solution which is usually quite expensive. In addition, in my opinion, adds an unneeded layer of complexity.

In most cases, you would only need to implement two stand-alone DHCP servers when using split-scopes. Each DHCP server can handle hundreds of scopes. With a split-scope configuration, if one server becomes unavailable, the other server will continue to lease new and renew existing IP addresses from new and/or existing clients. While the two DHCP servers do not share any DHCP database information, splitting DHCP scopes in this manner helps balance server loads. The most common design for splitting scopes is the 50/50 model. That is, one server will issue IPs from half of an IP range, while the other server will issue IP from the other half of the range. What you will find in most Microsoft documentation online is to use the 80/20 model. This model is more appropriate when deploying one DHCP server at a remote office with limited bandwidth, while deploying the other DHCP server at the main office. Now that bandwidth is not as much an issue as it was ten years ago, it is common to deploy both DHCP servers at the central office or deploy each DHCP server at a primary data center. DHCP traffic is relatively small and does not use much bandwidth, especially when you compare it to streaming video and other dominating traffic you see on networks today. When splitting a scope between two DHCP servers, start by creating the same scope to both servers. The IP range you will create will be identical on both systems. For example, if you needed to create a DHCP scope for the 192.168.1.x/24 subnet, you would create an IP Pool with a starting address of 192.168.1.1 and an ending address of 192.168.1.254 on each DHCP server (ServerA & ServerB). Next, let's assume that you require to set aside a range 54 IPs for static assignment. On ServerB, create an exclusion of 192.168.1.201 - 192.168.1.254. That will leave you with an available pool of 200 IPs that your clients can use. The next step is to exclude portions of this pool of IPs so that you do not have overlap on both servers. On ServerA, create an exclusion of 192.168.1.101 - 192.168.1.254. Then, on ServerB, create an exclusion of 192.168.1.1 - 192.168.1.100. This approach will provide you with the following configuration: DHCP Scope ServerA 192.168.1.1 - 192.168.1.254

Excluded IPs Available Pool Available IPs DHCP Scope Excluded IPs Excluded IPs Available Pool Available IPs

192.168.1.101 - 192.168.1.254 192.168.1.1 - 192.168.1.100 100 ServerB 192.168.1.1 - 192.168.1.254 192.168.1.1 - 192.168.1.100 192.168.1.201 - 192.168.1.254 192.168.1.101 - 192.168.1.200 100

Note: You also need to make identical reservations at both DHCP servers, so that either server can assign the reserved IP address, ensuring that the intended device receives the address that is reserved for its use. This is because you will not be able to force a DHCP client to use a specific DHCP server.

The DHCP Relay Agent

Friday, October 28, 2011
In networks with multiple subnets, it is not feasible to place DHCP servers on each of the subnets where clients are physically located. For a multi-segmented network, the best configuration is to place the DHCP servers in a central location. For this configuration to work effectively, DHCP messages must be able to cross IP routers. The problem is that DHCP traffic is mostly comprised of broadcast type messages which routers do not forward across interfaces. The solution is using a DHCP Relay Agent. Routers that are RFC 1542 compliant have the ability to act as DHCP Relay Agents. In addition, Windows Server Routing and Remote Access (RRAS) services also provides the ability to run DHCP Relay Agent Services. The process of obtaining an IP lease from a DHCP server can be broken down into four phases: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, AND DHCPACK. When a router configured as a Relay Agent receives a DHCP broadcast, it converts it to unicast packet with destination MAC/IP address of the configured DHCP server, and source MAC/IP of the router itself.

DHCPDISCOVER
The DHCP client sends the DHCPDISCOVER message, containing the MAC address of the DHCP client, to the broadcast IP address (255.255.255.255) and the MAC-level broadcast address (FF-FF-FF-FF-FF-FF). The DHCP Relay Agent receives and processes the DHCPDISCOVER packet. As established in RFC 1542, the DHCP Relay Agent can forward the packet to either an IP broadcast, multicast, or unicast address. In practice, DHCP Relay Agents forward DHCPDISCOVER messages to unicast IP addresses which correspond to DHCP server(s). Before forwarding the original DHCPDISCOVER message, the DHCP Relay Agent makes the following changes to the packet:

Increments the Hop Count field in the DHCP header. The DHCP Hop Count field is separate from the Time to Live (TTL) field in the IP header and is used to indicate on how many networks this DHCPDISCOVER has existed as a broadcast. When the configured maximum Hop Count is exceeded, the DHCPDISCOVER is silently discarded. This value can be configured when using a Microsoft DHCP Relay Agent. The default value is 4. Updates the Relay IP Address field (Gateway IP Address field, GIADDR) in the DHCP header. When the DHCP client sends the DHCPDISCOVER message, the Relay IP Address field is set to 0.0.0.0. If the Relay IP Address is 0.0.0.0, the DHCP Relay Agent records the IP address of the interface on which the DHCPDISCOVER message was received. If the Relay IP Address is not 0.0.0.0, the DHCP Relay Agent does not modify it. Changes the source IP address of the DHCPDISCOVER message to the IP address of the interface on which the broadcasted DHCPDISCOVER was received. Changes the destination IP address of the DHCPDISCOVER message to the configured unicast address of the DHCP server.

The DHCP Relay Agent sends the DHCPDISCOVER message as a unicasted IP packet rather than as an IP and MAC-level broadcast. If the DHCP Relay Agent is configured with multiple DHCP servers, it sends each DHCP server a copy of the DHCPDISCOVER message.

Type:

UDP

Source IP: Source Port: Destination IP: Destination Port:

0.0.0.0 68 255.255.255.255 67

DHCPOFFER
When responding to the DHCP client's request for an IP address, the DHCP server uses the Relay IP Address field in the following ways:

The Relay IP Address and the subnet masks of the server's configured scopes are compared through a logical AND comparison to find a scope whose network ID matches the network ID of the Relay IP Address. When a match is found, the DHCP server allocates an IP address from that scope. When sending the offer back to the client, the DHCP server sends the DHCPOFFER message to the Relay IP Address as the destination IP address.

Once received by the DHCP Relay Agent, the Relay IP Address is used to determine which interface to which the DHCPOFFER message is to be forwarded. It then forwards the DHCPOFFER message on the interface where the DHCPDISCOVER message originated from.

Type: Source IP: Source Port: Destination IP: Destination Port:

UDP DHCP Server's IP 67 DHCP Relay Agent IP 68

DHCPREQUEST
The DHCP client sends the DHCPREQUEST message, containing the MAC address of the client, to the IP broadcast address (255.255.255.255) and to the MAC broadcast address (FF-

FF-FF-FF-FF-FF). The DHCP Relay Agent receives this packet and forwards it as a unicast IP packet to the configured DHCP server or servers.

Type: Source IP: Source Port: Destination IP: Destination Port:

UDP 0.0.0.0 68 255.255.255.255 67

DHCPACK
The DHCP server initially sends the DHCPACK message to the Relay IP Address, as it did with the DHCPOFFER message. When the DHCP Relay Agent receives the DHCPACK message, it places the message back on the subnet where the DHCPREQUEST originated from.

Type: Source IP: Source Port: Destination IP: Destination Port:

UDP DHCP Server's IP 67 DHCP Relay Agent IP

68

The DHCP Process: Negotiating a Lease

Friday, October 28, 2011
The process in obtaining an IP address from a DHCP server is fairly simple and straightforward. This basic process, while taken for granted by many network administrators, is key in

understanding how clients obtain and negotiate IP leases. The process in obtaining a valid IP address from a DHCP server can be broken down into four phases. These four phases are as follows: DHCP Discover, DHCP Offer, DHCP Request, and DHCP Acknowledgement. Lets examine these phases for a client that is simply plugged into the network. When the network interface is brought online, the process begins as follows:

DHCPDISCOVER
In the first phase, the client broadcasts messages on the subnet to discover all available DHCP servers. A network administrator can configure a DHCP Relay Agent on the gateways interface for relaying the broadcast packet directly to a DHCP server in situations where a DHCP server is not physically located on the same segment as the DHCP clients. If a Relay Agent intercepts the packet, it will update the GIADDR (Gateway IP Address) field. This client creates a User Datagram Protocol (UDP) packet with the IP destination address of 255.255.255.255 (Broadcast).

Type: Source IP: Source Port: Destination IP: Destination Port:

UDP 0.0.0.0 68 255.255.255.255 67

DHCPOFFER
When a DHCP server receives an IP lease request from a client, it immediately reserves an IP address for the client and extends an IP lease offer by sending a DHCPOFFER message to the client. This message contains the client's MAC address, the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer. The DHCP server specifies the IP lease address in the YIADDR (Your IP Address) field.

Type: Source IP: Source Port:

UDP DHCP Server's IP 67

Destination IP: 255.255.255.255 (or DHCP Relay Agent IP if used) Destination Port: 68

DHCPREQUEST
A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer and broadcast a DHCP request message. Based on the Transaction ID field in the request, servers are informed whose offer the client has accepted. When other DHCP servers receive this message, they withdraw any offers that they might have made to the client and return the offered address to the pool of available addresses. Type: Source IP: Source Port: Destination IP: Destination Port: UDP 0.0.0.0 68 255.255.255.255 67

DHCPACK
When the DHCP server receives the DHCPREQUEST message from the client, the configuration processes enters its final phase. The acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the IP configuration process is completed. If the DHCP server is unable to offer the lease (especially for DHCP

requests to renew an existing lease), the DHCP server will send a DHCP Negative Acknowledgement, or DHCPNACK, back to the client. Type: Source IP: Source Port: UDP DHCP Server's IP 67

Destination IP: 255.255.255.255 (or DHCP Relay Agent IP if used) Destination Port: 68

When DHCP clients already have an active lease in place, they will attempt to renew the lease at 50% of the lease time. For example, if the lease was issued for 8 days, the client will attempt to re-negotiate the lease at 4 days. If it is unsuccessful in contacting the DHCP server at that time, it will attempt again when it reaches 87.5% of the lease period. If it is unsuccessful at this point, the client will continue regularly sending DHCPREQUEST packets until the lease is expired. Once the lease expires, the client will begin the process again from the DHCPDISCOVER phase. If the client is unsuccessful in obtaining an IP, by default, it will assign itself an APIPA address (Windows clients).

Using Conflict Detection in DHCP

Friday, October 28, 2011
Using conflict detection in your IP Management design should be highly considered. 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 later that obtain an IP address use a gratuitous ARP request to perform client-based conflict detection before completing the configuration and use of a server offered IP address. If the DHCP client detects a conflict, it will send a DHCP decline message (DHCPDECLINE) back to the DHCP server that offered the IP lease. If your network includes legacy DHCP clients, that is, 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. In addition, conflict detection can be very beneficial when upgrading or migrating to a new DHCP server without having a backup of the DHCP database available. 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. If the DHCP server detects a conflict with the IP address that it offered to the DHCP client, the DHCP server will create a temporary lease called "BAD ADDRESS". This lease will be configured with a one (1) hour lease period. At the end of the lease, it is automatically removed from the scope. If you find a lease of this type re-occuring for the same IP address over a period of time, you should locate the networked node and verify that it is not configured with a static IP address that is part of a DHCP scope. If you do find this situtation, you can either re-IP that conflicting device, or create an exclusion in your DHCP scope for that particular IP address so that your DHCP server will no longer attempt to issue that IP address to other DHCP clients. To enable address conflict detection 1. Open the DHCP administrative console. 2. In the console tree, click the applicable DHCP server. 3. On the Action menu, click Properties. For Windows 2008, you first need to highlight IPv4. There is no option for configuring IPv6 scopes. 4. Click the Advanced tab. 5. For Conflict detection attempts, type a number greater than 0 (zero) and less than six, and then click OK. The number you type determines how many times the DHCP server tests an IP address before leasing it to a client.

In Summary:
When conflict detection attempts are set, the DHCP server uses the Packet Internet

Groper (ping) process to test available scope IP addresses before including these addresses in DHCP lease offers to clients.
A successful ping means the IP address is in use on the network. Therefore, the DHCP

server does not offer to lease the address to a client. If the ping request fails and times out, the IP address is not in use on the network. In this case, the DHCP server offers to lease the address to a client.
Each additional conflict detection attempt delays the DHCP server response by a second

while waiting for the ping request to time out. This increases the load on the server. A value of no greater than two (2) for ping attempts is recommended.

You will probably install more than one DHCP server so that the failure of any individual server will not prevent DHCP clients from starting. However, DHCP does not provide a way for DHCP servers to cooperate in ensuring that assigned addresses are unique. Therefore, you must carefully divide the available address pool among the DHCP servers to prevent duplicate address assignment. For balancing DHCP server usage, use the 80/20 rule to divide scope addresses between DHCP servers. Figure 4.11 is an example of the 80/20 rule.

Figure 4.11 80/20 Rule Model DHCP Server 2 is configured to lease most (about 80 percent) of the available addresses. DHCP Server 1 is configured to lease the remaining addresses (about 20 percent). This scenario allows the local DHCP server (DHCP Server 2) to respond to requests from local DHCP clients most of the time. The remote or backup DHCP server (DHCP Server 1) assigns addresses to clients on the other subnet only when the local server is not available or is out of addresses. This same rule can be used in a multiple-subnet scenario to ensure the availability of a DHCP server when a client requests a lease.