A network environment without DHCP in these days is unthinkable, without it it would take a lot of time to configure and register every node not to speak of the time needed to troubleshooting an incident. A DHCP server can be implemented on different platforms like Microsoft Windows, Linux, BSD, Unix or a peace of network equipment. With the ever growing availability demands of the network of today it is advisable to implement a redundant DHCP setup, with this in mind a software platform like Microsoft Windows/Linux/BSD or Unix is more suitable then network equipment. With these platforms you can use more options than what is possible on Network equipment like Cisco, sow it can be used better with the future needs of the organization in mind. The biggest reason is that network equipment like Cisco is not able to run a statefull redundant DHCP setup, it is only possible to configure multiple devices as standalone instance. The problem that can occur is that the same IP address can be leased to multiple clients by multiple DHCP servers.

In this post I’m going to discus why this will occur and what you can do about it sow you can run a redundant DHCP setup on Cisco network equipment. I will try to update this post when I have extra information. The principle mention in this post should be applicable to other brands of network equipment like HP/Juniper.

Feedback or useful commands are more than welcome, they can be placed int he comments below.

 

Update tracking
Date Action
2015-06-04 Initial setup
2015-06-23 Finished the post

 

. DHCP Messages

 
The following list includes the eight types of messages that can be sent between DHCP clients and servers.

DHCPDiscover
Broadcast by a DHCP client when it first attempts to connect to the network. The DHCPDiscover message requests IP address information from a DHCP server.

DHCPOffer
Broadcast by each DHCP server that receives the client DHCPDiscover message and has an IP address configuration to offer to the client. The DHCPOffer message contains an unleased IP address and additional TCP/IP configuration information, such as the subnet mask and default gateway. More than one DHCP server can respond with a DHCPOffer message. The client accepts the best offer, which for a Windows DHCP client is the first DHCPOffer message that it receives.

DHCPRequest
Broadcast by a DHCP client after it selects a DHCPOffer. The DHCPRequest message contains the IP address from the DHCPOffer that it selected. If the client is renewing or rebinding to a previous lease, this packet might be unicast directly to the server.

DHCPAck
Broadcast by a DHCP server to a DHCP client acknowledging the DHCPRequest message. At this time, the server also forwards any options. Upon receipt of the DHCPAck, the client can use the leased IP address to participate in the TCP/IP network and complete its system startup. This message is typically broadcast, because the DHCP client does not officially have an IP address that it can use at this point. If the DHCPAck is in response to a DHCPInform, then the message is unicast directly to the host that sent the DHCPInform message.

DHCPNack
Broadcast by a DHCP server to a DHCP client denying the client’s DHCPRequest message. This might occur if the requested address is incorrect because the client moved to a new subnet or because the DHCP client’s lease has expired and cannot be renewed.

DHCPDecline
Broadcast by a DHCP client to a DHCP server, informing the server that the offered IP address is declined because it appears to be in use by another computer.

DHCPRelease
Sent by a DHCP client to a DHCP server, relinquishing an IP address and canceling the remaining lease. This is unicast to the server that provided the lease.

DHCPInform
Sent from a DHCP client to a DHCP server, asking only for additional local configuration parameters; the client already has a configured IP address. This message type is also used by DHCP servers running Windows Server 2003 to detect unauthorized DHCP servers.
 
 

. DHCP Lease Process

 
A DHCP-enabled client obtains a lease for an IP address from a DHCP server. Before the lease expires, the DHCP client must renew the lease or obtain a new lease. Leases are retained in the DHCP server database for a period of time after expiration.

Obtaining a New Lease
A DHCP client initiates a conversation with a DHCP server when it is seeking a new lease, renewing a lease, rebinding, or restarting. The DHCP conversation consists of a series of DHCP messages passed between the DHCP client and DHCP servers. The following figure shows an overview of this process when the DHCP server and DHCP client are on the same subnet.
 
 
DHCP Lease Process Overview
DHCP-process
1. The DHCP client requests an IP address by broadcasting a DHCPDiscover message to the local subnet.

2. The client is offered an address when a DHCP server responds with a DHCPOffer message containing an IP address and configuration information for lease to the client. If no DHCP server responds to the client request, the client sends DHCPDiscover messages at intervals of 0, 4, 8, 16, and 32 seconds, plus a random interval of between -1 second and 1 second. If there is no response from a DHCP server after one minute, the client can proceed in one of two ways:

a. If the client is using the Automatic Private IP Addressing (APIPA) alternate configuration, the client self-configures an IP address for its interface.

b. If the client does not support alternate configuration, such as APIPA, or if IP auto-configuration has been disabled, the client network initialization fails.

In both cases, the client begins a new cycle of DHCPDiscover messages in the background every five minutes, using the same intervals as before (0, 4, 8, 16, and 32 seconds), until it receives a DHCPOffer message from a DHCP server.

3. The client indicates acceptance of the offer by selecting the offered address and broadcasting a DHCPRequest message in response.

4. The client is assigned the address and the DHCP server broadcasts a DHCPAck message in response, finalizing the terms of the lease.

When the client receives acknowledgment, it configures its TCP/IP properties by using the DHCP option information in the reply, and completes its initialization of TCP/IP.

In rare cases, a DHCP server might return a negative acknowledgment to the client. This can happen if a client requests an invalid or duplicate address. If a client receives a negative acknowledgment (DHCPNack), the client must begin the entire lease process again.

When the DHCP client and the DHCP server are on the same IP broadcast subnet, the DHCPDiscover, DHCPOffer, DHCPRequest, and DHCPAck messages are sent to identify clients by means of IP-level broadcasts sent to the limited broadcast address and the media access control (MAC) broadcast address.

When the DHCP server and DHCP client are not on the same subnet either a router or a host on the DHCP client’s subnet must act as a DHCP relay agent to support the forwarding of DHCP messages between the DHCP client and the DHCP server.
Renewing a Lease

The DHCP client first attempts to renew its lease when 50 percent of the original lease time, known as T1, has passed. At this point the DHCP client sends a unicast DHCPRequest message to the DHCP server that originally granted its lease. If the server is available, and the lease is still available, the server responds with a unicast DHCPAck message and the lease is renewed.

If the original DHCP server is available, but the client’s current lease is no longer available, the DHCP server responds with a DHCPNack message, and the client immediately starts the process to obtain a new lease. This can happen if the client has changed subnets or if the DHCP server cannot fulfill the lease request for some other reason.

If there is no response from the DHCP server, the client waits until 87.5 percent of the lease time has passed (known as T2). At T2, the client enters the rebinding state, and broadcasts a DHCPRequest message to attempt to renew the lease from any available DHCP server. If no DHCP server is available by the time the lease expires, the client immediately unbinds itself from the existing lease and starts the process to obtain a new lease, beginning with a DHCPDiscover message.
 
 
Renewing a lease
The DHCP client first attempts to renew its lease when 50 percent of the original lease time, known as T1, has passed. At this point, the DHCP client sends a unicast DHCPRequest message to the DHCP server that originally granted its lease. If the server is available, and the lease is still available, the server responds with a unicast DHCPAck message, and the lease is renewed.

If the original DHCP server is available, but the client’s current lease is no longer available, the DHCP server responds with a DHCPNack message, and the client immediately starts the process to obtain a new lease. This can happen if the client has changed subnets or if the DHCP server cannot fulfill the lease request for some other reason.

If there is no response from the DHCP server, the client waits until 87.5 percent of the lease time, known as T2, has passed. At T2, the client enters the rebinding state, and broadcasts a DHCPRequest message to attempt to renew the lease from any available DHCP server. If no DHCP server is available by the time the lease expires, the client immediately unbinds itself from the existing lease and starts the process to obtain a new lease, beginning with a DHCPDiscover message.
 
 

. Conflict detection

 
To avoid an IP conflict in a DHCP network environment, workstation use “client conflict detection” optional servers can use “server conflict detection”.
 
Client conflict detection
Client computers running Windows Server NT4/2003/2008/2012, Windows 98/ME/2000/XP/Vista/7/8, Linux/BSD/Unix, automatically check to determine if an IP address is already in use before using it.

After the DHCP client receives a lease from the DHCP server, the client sends an Address Resolution Protocol (ARP) request to the address that it has been assigned. If a reply to the ARP request is received, the client has detected a conflict and sends a DHCPDecline message to the DHCP server. The DHCP server attaches a BAD_ADDRESS value to the IP address in the scope for the length of the lease. The client then begins the lease process again, and is offered the next available address in the scope.

Note
ARP requests do not traverse routers. Clients use ARP requests rather than pings (ICMP Echo messages) because pings require the sender to have an IP address.
 
 
Server conflict detection
If your network includes older DHCP clients that do not perform conflict detection themselves, you can enable conflict detection on the DHCP server.

To detect conflicts, the DHCP server pings (sends an ICMP Echo message to) an IP address before offering that address to clients in a new lease. The DHCP server only pings addresses that have not been successfully and previously leased. If a client requests a lease on an IP address that it already had or is requesting a renewal, the DHCP server does not ping the IP address.

If conflict detection is enabled, an administrator-defined number of pings are sent. The server waits 1 second for a reply. Because the time required for a client to obtain a lease is equal to the number of pings used, choose this value carefully because it directly impacts the overall performance of the server. In general, one ping is sufficient.

If a response to the ping is received, a conflict is registered and that address is not offered to clients requesting a lease from the server. The DHCP server then attaches a BAD_ADDRESS value to that IP address in the scope. The DHCP server then tries to lease the next available address. If the duplicate address is removed from the network, the BAD_ADDRESS value attached to the IP address can be deleted from the scope’s list of active leases, and then the address returns to the pool. Addresses are marked as BAD_ADDRESS for the length of the lease for which the scope is configured. If the BAD_ADDRESS entry is not manually removed, it will automatically be removed after a period of time equal to the lease time for the scope.

Note
In general, use server conflict detection only as a troubleshooting aid when you suspect that duplicate IP addresses are in use on your network. Each additional conflict detection attempt adds to the time required to negotiate leases for DHCP clients.
 
 

. Redundant DHCP setup on network equipment

 
It is possible to run a DHCP service on most Cisco network equipment, however you can only run a standalone DHCP service. In a standard setup the Cisco device will store the DHCP database in it’s NVRAM, on reload the database will be empty. To avoid this problem you can configure a DHCP database agent, this is a remote place where you store the leases only for that specific device.

In a network you need to have redundancy for critical services this also true for DHCP, however supplying this on network equipment comes with a challenge. This is due to the current limitations of Cisco network equipment. It is highly recommended to run this service on a server like Windows Server 2003/2008/2012 or linux/BSD/Unix, these platforms can share DHCP lease tables by Clustering/synchronizing.
 
 
Explanation:
There is a DCHP scope for subnet 192.168.0.0/24 running on two different peaces network equipment, these are supplying the IP addresses tot the clients. If the situation is conform what is discussed in this paper there are no problems. If you have clients that for any reason won’t react to an ARP request, there eventually will be an IP conflicts.

Client A requests an IP address, DHCP server A responds first, Client A gets IP address 192.168.0.1 from DHCP server A. Now Client B request an IP address, this time DHCP Server B responds first, Client B gets IP address 192.168.0.1 from DHCP server B. Client B is sending out an ARP request, client A isn’t responding to ARP messages. Client B will accept IP address 192.168.0.1 from DHCP server B, at this time IP address 192.168.0.1 is leased both to Client A and Client B thus there is a conflict.
 
 
Solution
The solution is quite simple create a scope on both routers twice as large as to what you need, for example if you need 126 IP adresses you need to configure a scope of /24 (254 IP addresses). On DHCP server A exclude the first part of the scope (0-128) and on DHCP server B exclude the second part of the scope (129-254), this way both DHCP servers can’t supply the same IP address thus no IP conflicts will be created. In a /24 IP subnet the .0 is the netmask, .255 is the broadcast and an IP address needs to be the gateway in a HSRP setup two more IP addresses are unusable.
 
 
To exclude an IP address or range use the following global command.
ip dhcp excluded-address

Leave a Reply

Your email address will not be published. Required fields are marked *