.jpeg)
The examples in this topic demonstrate behavior when a DHCP server in a DHCP failover relationship enters the communication interrupted state. In the third example, a DHCP server enters the communication interrupted state and subsequently passes from this state to the partner down state.
The communication interrupted state can occur due to interruption of the network link between DHCP failover partners, or it can occur because the DHCP Server service on a failover partner is unresponsive. The examples in this topic assume that a DHCP client can communicate with both DHCP servers in a failover relationship, but only one DHCP server is able to respond for a given time period.
Dual communication interrupted state
In the special case where there is a loss of the network connection between DHCP failover partners but each DHCP server can still respond to lease requests from local DHCP clients, such as where DHCP failover partners are in different branch offices and the link between branch offices is broken, both DHCP servers will enter the communications interrupted state.
In this scenario, both DHCP servers will renew DHCP client leases that were issued by the local DHCP server. DHCP servers will not respond to a DHCP renewal request if the lease was issued by the partner DHCP server. However, both DHCP servers will grant new IP address leases for clients that have entered a rebinding state. To avoid IP address conflicts, the two DHCP servers will each use a different portion of the free IP address pool when issuing new DHCP leases.
Dual partner down state
If the network connection between DHCP failover partners is broken for an extended period of time and a state switchover interval is configured, it is possible for both DHCP servers to enter the partner down state. This should be avoided. In this scenario, both DHCP servers will provide new IP address leases from the entire free IP address pool, resulting in possible IP address conflicts. For this reason, it is recommended to increase the state switchover interval under the following conditions:
The first lease issued by a DHCP server from a scope that belongs to a DHCP failover relationship is always for the MCLT duration. After this lease is renewed at half the lease duration (MCLT) a lease is granted for the full scope lease duration.
For information about the types of messages exchanged between DHCP failover partner servers, see DHCP Failover Communications.
The following illustration and its corresponding steps provide a detailed description of the processes involved when a DHCP client acquires a DHCP lease from DHCP servers configured for DHCP failover in hot standby mode.
A DHCP client in the INIT state broadcasts a DHCP discover message. Since DHCP2 is in standby status, it does not respond to the client. DHCP1 is in active status and responds by offering a lease to the client. The client requests a lease from DHCP1. DHCP1 provides an IP address lease to the client for the MCLT (not the full scope lease duration). DHCP1 sends a binding update (BNDUPD) message to DHCP2 letting it know about the new lease. DHCP2 responds to DHCP1 and acknowledges that it received the binding update (BNDACK). At 50% of the lease time (MCLT/2), the client requests a renewal for its lease from DHCP1. DHCP1 renews the client’s DHCP lease for the full scope lease duration. DHCP1 sends a binding update (BNDUPD) message to DHCP2 informing it of the lease renewal. DHCP2 acknowledges that it received the binding update message from DHCP1 (BNDACK). DHCP1 becomes unavailable. DHCP2 receives an error when attempting to communicate with DHCP1 or a timer expires because no messages have been received from DHCP1. DHCP2 drops the connection, enters the communication interrupted state, and switches to an active status. DHCP2 attempts and fails to reestablish a connection with DHCP1. At 50% of the scope lease time, the client requests a renewal for its lease from DHCP1, but DHCP1 is not available so the lease it not renewed. At 7/8 of the scope lease time, the client moves into a REBINDING state and broadcasts a lease renewal request. DHCP2 receives the lease request from the client and responds with a DHCPACK. The client renews its lease using the same IP address as previously assigned for the duration of the MCLT. For clients that did not previously have a lease on either the active or standby server, DHCP2 will use an IP address from the reserve percentage. For clients that previously had a lease on its failover partner, DHCP2 will renew the same IP address for the client.
The following illustration and its corresponding steps provide a detailed description of the processes involved when a DHCP client acquires a DHCP lease from DHCP servers configured for DHCP failover in load balancing mode.
A DHCP client in the INIT state broadcasts a DHCP discover message. DHCP1 and DHCP2 each compute a hash of the client ID in the range 0-255. It is determined that the hash value belongs to the hash bucket assignment for DHCP1, so only DHCP1 responds to the client. The client requests a lease from DHCP1. DHCP1 provides an IP address lease to the client for the MCLT (not the full scope lease duration). DHCP1 sends a binding update (BNDUPD) message to DHCP2 letting it know about the new lease. DHCP2 responds to DHCP1 and acknowledges that it received the binding update (BNDACK). At 50% of the lease time (MCLT/2), the client requests a renewal for its lease from DHCP1. DHCP1 renews the client’s DHCP lease for the full scope lease duration. DHCP1 sends a binding update (BNDUPD) message to DHCP2 informing it of the lease renewal. DHCP2 acknowledges that it received the binding update message from DHCP1 (BNDACK). DHCP1 becomes unavailable. DHCP2 receives an error when attempting to communicate with DHCP1 or a timer expires because no messages have been received from DHCP1. DHCP2 drops the connection, enters the communication interrupted state, and begins accepting leases requests for all clients. DHCP2 attempts and fails to reestablish a connection with DHCP1. At 50% of the scope lease time, the client requests a renewal for its lease from DHCP1, but DHCP1 is not available so the lease it not renewed. At 7/8 of the scope lease time, the client moves into a REBINDING state and broadcasts a lease renewal request. DHCP2 determines that the client belongs to DHCP1, but since DHCP2 is in communications interrupted state, it offers a temporary lease to the client for the duration of the MCLT. For clients that did not previously have a lease on either DHCP1 or DHCP2, DHCP2 will use an IP address from its assigned address pool. For clients that previously had a lease on its failover partner, DHCP2 will renew the same IP address to the client.
.jpeg)
The following illustration and its corresponding steps provide a detailed description of the processes involved when a DHCP failover partner server enters the partner down state in load balance mode.
A DHCP client in the INIT state broadcasts a DHCP discover message. DHCP1 and DHCP2 each compute a hash of the client ID in the range 0-255. It is determined that the hash value belongs to the hash bucket assignment for DHCP1, so only DHCP1 responds to the client. The client requests a lease from DHCP1. DHCP1 provides an IP address lease to the client for the MCLT (not the full scope lease duration). DHCP1 sends a binding update (BNDUPD) message to DHCP2 letting it know about the new lease. DHCP2 responds to DHCP1 and acknowledges that it received the binding update (BNDACK). At 50% of the lease time (MCLT), the client requests a renewal for its lease from DHCP1. DHCP1 renews the client’s DHCP lease for the full scope lease duration. DHCP1 sends a binding update (BNDUPD) message to DHCP2 informing it of the lease renewal. DHCP2 acknowledges that it received the binding update message from DHCP1 (BNDACK). DHCP1 becomes unavailable. DHCP2 receives an error when attempting to communicate with DHCP1 or a timer expires because no messages have been received from DHCP1. DHCP2 drops the connection, enters the communication interrupted state, and begins accepting leases requests for all clients. DHCP2 attempts and fails to reestablish a connection with DHCP1. At 50% of the scope lease time, the client requests a renewal for its lease from DHCP1, but DHCP1 is not available so the lease it not renewed. At 7/8 of the scope lease time, the client moves into a REBINDING state and broadcasts a lease renewal request. DHCP2 determines that the client belongs to DHCP1, but since DHCP2 is in communications interrupted state, it offers a temporary lease to the client for the duration of the MCLT. For clients that did not previously have a lease on either DHCP1 or DHCP2, DHCP2 will use an IP address from its assigned free address pool. For clients that previously had a lease on its failover partner, DHCP2 will renew the same IP address.
Note For clients that did not previously have a lease on either DHCP1 or DHCP2, DHCP2 will use an IP address from its assigned free IP address pool until that is exhausted, and then it will begin granting leases from the failover partner’s free IP address pool. For clients that previously had a lease, DHCP2 will renew the same IP address for the client. All leases are granted for the MCLT duration.
Note If DHCP1 was unavailable for a time shorter than the MCLT, it will transition to the RECOVER WAIT state until the MCLT duration expires. DHCP1 does not respond to lease requests while in the RECOVER WAIT state.
