Consulta de temas

DHCP Failover States of Operation in Windows Server 2012 and Above



This article provides information on the operational states of servers in a DHCP failover relationship.



For general information on DHCP failover, including the requirements that must be met before deployment, see Information about DHCP Failover in Windows Server 2012 and Above.


For instructions for setting up a failover relationship, see How to Configure DHCP Failover in Windows Server 2012 and Above.

A server participating in a DHCP failover relationship will be in one of the operational states listed below. A brief description of each state is given, along with a list of the states to which a server may transition from the state in question.

  • STARTUP: This is the initial operational state of a server in a DHCP failover relationship. A server will not respond to DHCP clients while in this state. The server assumes that its partner is functioning and will spend a short time attempting to contact it in order to determine whether the partner's state has changed since the last contact. If the partner's state has indeed changed, the local server may have to take action (for example, retrieve database updates from the partner) prior to servicing clients.

    Possible transitions:
    A server in the STARTUP state can transition to nearly any operational state. An algorithm determines its next state based on its partner's current state (if the partner can be contacted) and its own last known operational state. Details of this algorithm can be found in section 9.3.2 of the IETF draft specification for the DHCP Failover Protocol.
  • NORMAL: In this state, the server is able to communicate with its partner and is operating according to the relationship mode and its role in the relationship.

    Possible transitions:
    • COMMUNICATIONS INTERRUPTED: Contact is lost with the partner server or the partner server transitions into the PAUSED state.
    • PARTNER DOWN: The partner server executes an orderly shutdown while communications are intact.
  • COMMUNICATIONS INTERRUPTED: When a server is unable to contact its partner, it will enter this state. Since the server has no way to know whether its partner is still running, it assumes that it is and operates in a manner designed to prevent potential conflicts, such as both servers leasing the same IP address to different clients. The behavior of a server in this state will be determined by the relationship mode and its role in the relationship:
    • In a load balancing relationship, the server, regardless of its role, will continue issuing addresses to new clients in its own address pool, as in the NORMAL state. However, it will also issue addresses from its own address pool to clients in the other server's address pool. Renewal requests from clients in the server's own address pool will be handled normally, and renewal requests from the other server's address pool will be granted a temporary lease whose duration is equal to the maximum client lead time (MCLT).
    • In a hot standby relationship, the active server will continue servicing all clients normally in this state. The standby server will begin servicing clients which don't already have leases by using the addresses in its reserve percentage, if any are available. If it runs out of reserve addresses while still in this state, it will be unable to lease addresses to new clients. Clients which have existing leases will be issued temporary renewals which have a lease duration equal to the MCLT.


    Possible transitions:
    • NORMAL: Communication with the partner is restored, and the partner is in the NORMAL, COMMUNICATIONS INTERRUPTED, or RECOVER DONE state.
    • POTENTIAL CONFLICT: Communication with the partner is restored, and the partner is in PARTNER DOWN, POTENTIAL CONFLICT, CONFLICT DONE, or RESOLUTION INTERRUPTED.
    • PARTNER DOWN: The automatic state transition interval (if enabled) expires, or an administrator manually places the server in PARTNER DOWN.
  • PARTNER DOWN: A server in the COMMUNICATIONS INTERRUPTED state will transition to the PARTNER DOWN state when one of two things happens: the state switchover interval (if configured) expires, or an administrator manually places the server in the PARTNER DOWN state. The latter can only be done on a server in the COMMUNICATIONS INTERRUPTED state and is the only way to transition a server into PARTNER DOWN if automatic state switchover is not enabled. Unlike COMMUNICATIONS INTERRUPTED, the PARTNER DOWN state implies that a server's partner is no longer operating. When a server enters the PARTNER DOWN state, a timer is set to the value of the MCLT and begins counting down. During this countdown, the server responds to clients as it would in the COMMUNICATIONS INTERRUPTED state. When the timer expires, the server, regardless of its role or the relationship mode, begins servicing all clients using the entire address pool. For this reason, both partners in a failover relationship should never be placed into the PARTNER DOWN state at the same time, as conflicts may arise.

    Possible transitions
    • POTENTIAL CONFLICT: Communication with the partner is restored, and the partner is in NORMAL, COMMUNICATIONS INTERRUPTED, PARTNER DOWN, POTENTIAL CONFLICT, RESOLUTION INTERRUPTED, or CONFLICT DONE.
    • NORMAL: Communication with the partner is restored, and the partner is in the RECOVER-DONE state.
  • POTENTIAL CONFLICT: When a server in the PARTNER DOWN state receives a message from its partner indicating that the partner is running in a state which could result in conflicts, it will enter the POTENTIAL CONFLICT state. This state indicates that communications between the servers have been restored, but conflicts may have occurred due to the previous operating state of one of the servers. Servers in the POTENTIAL CONFLICT state will not service clients. In this state, the primary server (the server designated as the "active" server in a hot standby relationship, or the server on which a load balance relationship was initially created) will request that its partner send it all updates to the binding database which have occurred since the two servers were last in contact with each other. The secondary server will simply wait in this state for such a request from the primary server.

    Possible transitions:
    • CONFLICT DONE (primary server only): The primary server received a message from the secondary server indicating that all requested updates have been sent.
    • NORMAL (secondary server only): The secondary server receives a message from the primary server indicating that all requested updates have been sent.
    • RESOLUTION INTERRUPTED: Communication with the partner is lost.
  • CONFLICT DONE: When a primary server in the POTENTIAL CONFLICT state receives a message from its partner indicating that all binding updates have been sent, it will enter the CONFLICT DONE state. A server in this state will service all clients in the same manner as it would in the COMMUNICATIONS INTERRUPTED state. In a load sharing relationship, this means that the primary server will temporarily service clients from both address pools. Only the primary server in a relationship should ever enter this state.

    Possible transitions:
    • NORMAL: The primary server receives a message from the secondary server indicating that it has transitioned to the NORMAL state.
  • RESOLUTION INTERRUPTED: A server enters this state when it loses contact with its partner while in the POTENTIAL CONFLICT state, allowing the server to respond to client requests. In this state, a server services clients as it does in the COMMUNICATIONS INTERRUPTED state.

    Possible transitions:
    • POTENTIAL CONFLICT: Communication is restored with the partner.
    • PARTNER DOWN: An administrator manually places the server in the PARTNER DOWN state.
  • RECOVER: If a server in the STARTUP state discovers that its partner entered the PARTNER DOWN state at some point after the local server was last operational, it will enter the RECOVER state. A server can also enter this state if it is made aware that it has lost its binding database. In this state, a server will not respond to client requests at all and will attempt to retrieve all necessary binding database updates (which may include the entire database) from its partner. If communications are lost while in the RECOVER state, a server will remain in this state while attempting to re-establish contact with its partner.

    Possible transitions:
    • RECOVER WAIT: A message is received from the partner indicating that all requested updates have been sent.
    • POTENTIAL CONFLICT: Communication with the partner is restored, and the partner is in POTENTIAL CONFLICT, RESOLUTION INTERRUPTED, or CONFLICT DONE.
  • RECOVER WAIT: A server which successfully receives all needed database updates in the RECOVER state will enter the RECOVER WAIT state. A server in this state ignores all client requests and simply waits for the duration of the MCLT.

    Possible transitions:
    • RECOVER DONE: The timer has expired.
  • RECOVER DONE: Once a server has been in the RECOVER WAIT state for the duration of the MCLT, it will enter the RECOVER DONE state. A server in this state will only respond to client renewal or rebinding requests; it will not service new clients. The main purpose of this state is to notify the partner server that recovery has completed. The partner can then enter the NORMAL state, after which the local server will do the same.

    Possible transitions:
    • NORMAL: A message is received from the partner indicating that the partner has entered the NORMAL or RECOVER DONE state.


The DHCP failover draft specification also provides for PAUSED and SHUTDOWN states, which are not listed here. The only purpose of these states is to inform the other server of a brief or extended outage, respectively, of its partner so that it may change its own state to either COMMUNICATIONS INTERRUPTED or PARTNER DOWN and continue servicing clients with no interruption.

The diagram below illustrates all of the possible transitions between states. For clarity, the STARTUP, SHUTDOWN, and PAUSED states are not shown.





Quick Tips content is self-published by the Dell Support Professionals who resolve issues daily. In order to achieve a speedy publication, Quick Tips may represent only partial solutions or work-arounds that are still in development or pending further proof of successfully resolving an issue. As such Quick Tips have not been reviewed, validated or approved by Dell and should be used with appropriate caution. Dell shall not be liable for any loss, including but not limited to loss of data, loss of profit or loss of revenue, which customers may incur by following any procedure or advice set out in the Quick Tips.

Identificación del artículo: SLN291147

Última fecha de modificación: 10/01/2014 10:41 AM


Califique este artículo

Preciso
Útil
Fácil de comprender
¿Este artículo fue útil?
No
Envíenos sus comentarios
Los comentarios no pueden contener estos caracteres especiales: <>"(", ")", "\"
Disculpe, nuestro sistema de comentarios está actualmente inactivo. Vuelva a intentarlo más tarde.

Muchas gracias por sus comentarios.