---
title: "Managing Failover Associations"
canonical: "https://docs.infoblox.com/space/nios85/35418381/Managing%20Failover%20Associations"
format: markdown
---
After you establish a failover association, you can monitor its status periodically to ensure that it is functioning properly. You can also delete a failover association when it is not assigned to any DHCP range.  
See the following sections on how to manage failover associations:

- *<span style="color: #0000ff">[Modifying](#ManagingFailoverAssociations-bookmark2485)</span>*[ ](#ManagingFailoverAssociations-bookmark2485)*<span style="color: #0000ff">[Failover](#ManagingFailoverAssociations-bookmark2485)</span>*[ ](#ManagingFailoverAssociations-bookmark2485)*<span style="color: #0000ff">[Associations](#ManagingFailoverAssociations-bookmark2485)</span>*
- *<span style="color: #0000ff">[Monitoring](#ManagingFailoverAssociations-bookmark2486)</span>*[ ](#ManagingFailoverAssociations-bookmark2486)*<span style="color: #0000ff">[Failover](#ManagingFailoverAssociations-bookmark2486)</span>*[ ](#ManagingFailoverAssociations-bookmark2486)*<span style="color: #0000ff">[Associations](#ManagingFailoverAssociations-bookmark2486)</span>*[ ](#ManagingFailoverAssociations-bookmark2486)
- *<span style="color: #0000ff">[Deleting](#ManagingFailoverAssociations-bookmark2488)</span>*[ ](#ManagingFailoverAssociations-bookmark2488)*<span style="color: #0000ff">[Failover](#ManagingFailoverAssociations-bookmark2488)</span>*[ ](#ManagingFailoverAssociations-bookmark2488)*<span style="color: #0000ff">[Associations](#ManagingFailoverAssociations-bookmark2488)</span>*[ ](#ManagingFailoverAssociations-bookmark2488)

Under special circumstances, you can manually adjust the configuration of a failover association. For example, when you know in advance that a peer will be out of service for an extended period of time, you can manually set the functional peer in a PARTNER-DOWN mode. This allows the functional partner to assume all leases and be able to allocate addresses to client requests in full capacity. In addition, when you suspect the databases in a failover association are not synchronized, you can consider doing a force recovery (after you consult with Infoblox Technical Support or your Infoblox representative) so the secondary server can completely rebuild its lease table with updates from the primary server.  
See the following sections on how to set a peer to the partner-down mode and perform a force recovery:

- *<span style="color: #0000ff">[Setting](#ManagingFailoverAssociations-bookmark2490)</span>*[ ](#ManagingFailoverAssociations-bookmark2490)*<span style="color: #0000ff">[a](#ManagingFailoverAssociations-bookmark2490)</span>*[ ](#ManagingFailoverAssociations-bookmark2490)*<span style="color: #0000ff">[Peer](#ManagingFailoverAssociations-bookmark2490)</span>*[ ](#ManagingFailoverAssociations-bookmark2490)*<span style="color: #0000ff">[in](#ManagingFailoverAssociations-bookmark2490)</span>*[ ](#ManagingFailoverAssociations-bookmark2490)*<span style="color: #0000ff">[the](#ManagingFailoverAssociations-bookmark2490)</span>*[ ](#ManagingFailoverAssociations-bookmark2490)*<span style="color: #0000ff">[Partner-Down](#ManagingFailoverAssociations-bookmark2490)</span>*[ ](#ManagingFailoverAssociations-bookmark2490)*<span style="color: #0000ff">[State](#ManagingFailoverAssociations-bookmark2490)</span>*[ ](#ManagingFailoverAssociations-bookmark2490)
- *<span style="color: #0000ff">[Performing](#ManagingFailoverAssociations-bookmark2491)</span>*[ ](#ManagingFailoverAssociations-bookmark2491)*<span style="color: #0000ff">[a](#ManagingFailoverAssociations-bookmark2491)</span>*[ ](#ManagingFailoverAssociations-bookmark2491)*<span style="color: #0000ff">[Force](#ManagingFailoverAssociations-bookmark2491)</span>*[ ](#ManagingFailoverAssociations-bookmark2491)*<span style="color: #0000ff">[Recovery](#ManagingFailoverAssociations-bookmark2491)</span>*[ ](#ManagingFailoverAssociations-bookmark2491)

# > Macro (anchor)

> Macro (anchor)

Modifying Failover Associations

To modify a failover association:

1. From the **Data** **Management** tab, select the **DHCP** tab -> **Members** tab -> **Failover** **Associations** ->* failover_association* checkbox, and then click the Edit icon.
2. The *DHCP* *Failover* *Association* editor contains the following tabs from which you can modify data:
  - **General**: In the **Basic** tab, modify the fields as described in *<span style="color: #0000ff">[Adding](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)*<span style="color: #0000ff">[Failover](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)*<span style="color: #0000ff">[Associations](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)</span>*[.](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)  
In the **Advanced** tab, complete the following to modify the port number you use for the failover association:
    - **Failover ****Port:** Click **Override** to enter a port number for the failover association. You can use any available port from 1 to 63999. The default is 647 for a new installation and 519 for an upgrade.
  - **Triggers**: Before editing the triggers and timers, ensure that you understand the ramification of the changes. Improper configuration of the triggers can cause the failover association to fail. For information about the fields in the **Basic** tab, see *<span style="color: #0000ff">[Adding](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)*<span style="color: #0000ff">[Failover](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)*<span style="color: #0000ff">[Associations](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360/Configuring+Failover+Associations#ConfiguringFailoverAssociations-bookmark2482)</span>*. The following are the triggers in the **Advanced** tab:
    - **Max**** Response ****Delay**** Before**** Failover(s):** Specifies how much time (in seconds) can transpire before a failover occurs when a failover peer does not receive any communication from its peer. This number should be small enough that the transient network failure does not leave the servers out of communication for a long time, but big enough that the servers are not constantly connecting and disconnecting. The default is 60 seconds.
    - **Max**** Number**** of**** Unacked**** Updates:** Specifies the number of "unacked" packets the server can send before a failover occurs. The default is 10 messages.
    - **Max**** Client**** Lead**** Time (s):** Specifies the length of time that a failover peer can renew a lease without contacting its peer. The larger the number, the longer it takes for the peer to recover IP addresses after moving to the **PARTNER-DOWN** state. The smaller the number, the more load your servers experience when they are not communicating. The default is 3600 seconds.
    - **Max ****Load**** Balancing**** Delay (s):** Specifies the cutoff after load balancing is disabled. The cutoff is based on the number of seconds since a client sent its first **DHCPDISCOVER** message. For instance, if one of the failover peers gets into a state where it is busy responding to failover messages but is not responding to other client requests, the other peer responds to the client requests when the clients retry. This does not cause a failover. The default is three seconds.
  - **Failover**** Settings:** This is valid for Microsoft Management only. Modify failover association settings. For information, see *<span style="color: #0000ff">[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360)*<span style="color: #0000ff">[Failover](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360)*<span style="color: #0000ff">[Associations](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385360)</span>*.

If you modify failover settings from secondary Microsoft server settings, the appliance does not update failover settings on NIOS for the following reasons:

> Macro (legacy-content)

# > Macro (anchor)

> Macro (anchor)

> Macro (anchor)

Monitoring Failover Associations

After you configure a failover association, the peers establish a TCP connection for communication. In a normal operational state, they send keepalive messages and database updates every time they grant a lease. However, there are times when the failover association experiences problems and goes into a state other than **NORMAL**. You can monitor the overall state of a failover association and the individual status of the peers to verify that the servers are operating and communicating properly.  
Both peers in a failover association maintain the same DHCP fingerprinting state (enabled or disabled) even when one of the peers fails or becomes operational again. Note that both peers must be in the same Grid for the fingerprinting state to stay the same. For information about DHCP fingerprinting, see *<span style="color: #0000ff">[About](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35816545/DHCP+Fingerprint+Detection#DHCPFingerprintDetection-bookmark2849)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35816545/DHCP+Fingerprint+Detection#DHCPFingerprintDetection-bookmark2849)*<span style="color: #0000ff">[DHCP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35816545/DHCP+Fingerprint+Detection#DHCPFingerprintDetection-bookmark2849)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35816545/DHCP+Fingerprint+Detection#DHCPFingerprintDetection-bookmark2849)*<span style="color: #0000ff">[Fingerprints](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35816545/DHCP+Fingerprint+Detection#DHCPFingerprintDetection-bookmark2849)</span>*.  
In this panel, you can also modify some of the data in the table. Double click a row of data, and either edit the data in the field or select an item from a drop-down list. Note that some fields are read-only. For more information about this feature, see *<span style="color: #0000ff">[Modifying](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35413897/About+the+Grid+Manager+Interface#AbouttheGridManagerInterface-ModifyingDatainTables)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35413897/About+the+Grid+Manager+Interface#AbouttheGridManagerInterface-ModifyingDatainTables)*<span style="color: #0000ff">[Data](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35413897/About+the+Grid+Manager+Interface#AbouttheGridManagerInterface-ModifyingDatainTables)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35413897/About+the+Grid+Manager+Interface#AbouttheGridManagerInterface-ModifyingDatainTables)*<span style="color: #0000ff">[in](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35413897/About+the+Grid+Manager+Interface#AbouttheGridManagerInterface-ModifyingDatainTables)</span>*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35413897/About+the+Grid+Manager+Interface#AbouttheGridManagerInterface-ModifyingDatainTables)*<span style="color: #0000ff">[Tables](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35413897/About+the+Grid+Manager+Interface#AbouttheGridManagerInterface-ModifyingDatainTables)</span>*.  
To monitor the failover association status:

1. From the **Data** **Management** tab, select the **DHCP** tab -> **Members** tab -> **IPv4** **Failover** **Associations** section. Grid Manager displays the list of failover associations and their overall status.
2. To view detailed information about a failover association, select the *failover_association* checkbox, and then click the Show Status icon.
3. In the *Failover* *Association* *Status* dialog box, Grid Manager displays the overall status of the failover association and the status of both the primary and secondary servers.

The failover association can be in one of the following states:

> Macro (legacy-content)

For each peer, Grid Manager displays the hostname or IP address, the status, and event date. The peer can be in one of the following states:

> Macro (legacy-content)

> ⚠️ **Note**
> ⚠️ 
> ⚠️ NIOS does not support **PARTNER-DOWN** and Force Recovery for a Microsoft DHCP failover association.


# > Macro (anchor)

> Macro (anchor)

Deleting Failover Associations

You cannot delete a failover association if it is currently assigned to a DHCP range. If you want to delete a failover association, ensure that it is not assigned to any DHCP range.  
To delete a failover association:

1. From the **Data** **Management** tab, select the **DHCP** tab -> **Members** tab -> **Failover** **Associations** ->* failover_association* checkbox, and then click the Delete icon.
2. In the *Delete* *Confirmation* dialog box, click **Yes**.

The appliance puts the failover association in the recycle bin, if enabled.

# > Macro (anchor)

> Macro (anchor)

> Macro (anchor)

Setting a Peer in the Partner-Down State

If one of the peers in a failover association is out of service for an extended period of time, you should consider putting the functional peer in the **PARTNER-DOWN** state. When you place the functional peer in the **PARTNER-DOWN** state, it assumes full DHCP services for the networks. Since the functional server may not receive all the updates from its peer, it extends all the leases on the MCLT. Once the following conditions are met, the functional peer provides DHCP services autonomously:

- It has reclaimed all the leases that belonged to its peer.
- The MCLT has passed.

When the peer that is offline comes back online, it synchronizes with the functional peer and reestablishes the communication before it provides DHCP services to the clients.

> ❌ **Warning**
> ❌ 
> ❌ *<span style="color: #ff0000">Before</span>* *<span style="color: #ff0000">you</span>* *<span style="color: #ff0000">put</span>* *<span style="color: #ff0000">a</span>* *<span style="color: #ff0000">peer</span>* *<span style="color: #ff0000">in</span>* *<span style="color: #ff0000">the</span>* *<span style="color: #ff0000">**partner-down**</span>* *<span style="color: #ff0000">state,</span>* *<span style="color: #ff0000">ensure that</span>* *<span style="color: #ff0000">the</span>* *<span style="color: #ff0000">other</span>* *<span style="color: #ff0000">peer</span>* *<span style="color: #ff0000">is</span>* *<span style="color: #ff0000">indeed</span>* *<span style="color: #ff0000">out</span>* *<span style="color: #ff0000">of</span>* *<span style="color: #ff0000">service.</span>* *<span style="color: #ff0000">If</span>* *<span style="color: #ff0000">both</span>* *<span style="color: #ff0000">the</span>* *<span style="color: #ff0000">primary</span>* *<span style="color: #ff0000">and</span>* *<span style="color: #ff0000">secondary</span>* *<span style="color: #ff0000">servers</span>* *<span style="color: #ff0000">are</span>* *<span style="color: #ff0000">operational</span>* *<span style="color: #ff0000">when</span>* *<span style="color: #ff0000">you</span>* *<span style="color: #ff0000">place</span>* *<span style="color: #ff0000">one</span>* *<span style="color: #ff0000">of</span>* *<span style="color: #ff0000">them</span>* *<span style="color: #ff0000">in</span>* *<span style="color: #ff0000">the</span>* *<span style="color: #ff0000">partner-down</span>* *<span style="color: #ff0000">mode,</span>* *<span style="color: #ff0000">both</span>* *<span style="color: #ff0000">servers</span>* *<span style="color: #ff0000">may</span>* *<span style="color: #ff0000">stop</span>* *<span style="color: #ff0000">issuing</span>* *<span style="color: #ff0000">leases</span>* *<span style="color: #ff0000">for</span>* *<span style="color: #ff0000">a</span>* *<span style="color: #ff0000">minimum</span>* *<span style="color: #ff0000">of</span>* *<span style="color: #ff0000">time</span>* *<span style="color: #ff0000">defined</span>* *<span style="color: #ff0000">in</span>* *<span style="color: #ff0000">the</span>* *<span style="color: #ff0000">MCLT.</span>*


To set a peer in the **PARTNER-DOWN** state:

1. From the **Data** **Management** tab, select the **DHCP** tab ->**Members** tab- > **Failover** **Associations** ->* failover_association* checkbox.
2. Expand the Toolbar and click **Set** **Partner** **Down**.
3. In the *Set* *Failover* *Association* *Partner* *Down* dialog box, select one of the following:
  - **Primary**: Select this if the secondary server is out of service.
  - **Secondary**: Select this if the primary server is out of service.

     4. Click **OK**.

> ⚠️ **Note**
> ⚠️ 
> ⚠️ You cannot place the functional peer in the **PARTNER-DOWN** state for a Microsoft DHCP failover in NIOS.

# > Macro (anchor)

> Macro (anchor)

Performing a Force Recovery

When the primary and secondary peers are not synchronized, you can perform a force recovery to set the primary server in the **PARTNER-DOWN** state while putting the secondary server in the **RECOVER** state. During a force recovery, all leases in the databases are resynchronized. When you perform a force recovery, the secondary server does not serve any DHCP leases for a minimum of the MCLT while it resynchronizes with the primary server. Before you perform a force recovery, consult with Infoblox Technical Support or your Infoblox representative to ensure that the force recovery is appropriate for the situation.  
To perform a force recovery:

1. From the **Data** **Management** tab, select the **DHCP** tab-> **Members** tab-> **Failover** **Associations** ->* failover_association* checkbox.
2. Expand the Toolbar and click **Force** **Recovery** **State**.
3. In the *Force* *Secondary* *Peer* *Recovery* *State* dialog box, click **OK**.

The appliance synchronizes the databases on the primary and secondary server> Macro (anchor)

s.

> ⚠️ **Note**
> ⚠️ 
> ⚠️ You cannot place the functional peer in the **PARTNER-DOWN** state for a force recovery in NIOS.


# > Macro (anchor)

> Macro (anchor)

Recovering DHCP Failover Associations

During a conflict resolution, when the primary peer of the DHCP failover association is in the **CONFLICT-DONE** state and the secondary peer in the **POTENTIAL-CONFLICT** state, the secondary peer might experience problems (such as restarting, network outage, etc.) and goes into an invalid state. This results in a deadlock state for the failover association, causing a DHCP service outage. When the failover association is in a deadlock state, you can perform a recovery for the failover association. You can run the recovery for one failover association at a time and when the primary member is in the **CONFLICT-DONE** state. This feature is supported for Infoblox appliances only and not for any other external DHCP servers.

> ⚠️ **Note**
> ⚠️ 
> ⚠️ When the failover recovery is in progress, the DHCP service on both peers are disabled and you cannot enable the DHCP service until the failover recovery is successfully completed. You can view the logs of the failover recovery process in the syslog and infoblox.log file.


To recover a DHCP failover association:

1. From the **Data** **Management** tab, select the **DHCP** tab-> **Members** tab -> **Failover** **Associations** ->* failover_association* checkbox.
2. Expand the Toolbar and click **Recovery** **from** **Deadlock** **State**.
3. In the *Failover* *Recovery* *Progress* dialog box, click **Start** to start the recovery of the failover association from the deadlock state.
4. In the confirmation dialog box, click **Yes**.

> ⚠️ **Note**
> ⚠️ 
> ⚠️ After you start the failover recovery, you cannot revert the changes.


Grid Manager starts the failover recovery and you can view the following information in the *Failover* *Recovery* *Progress*  
dialog box:

- **Failover** **association**: The name of the failover association.
- **Primary**: The hostname or IP address of the primary server.
- **Secondary**: The hostname or IP address of the secondary server.
- **Number** **of** **leases** **to** **be** **processed**: The total number of leases to be processed.
- **Number** **of** **leases** **processed**: The number of leases that have been processed.
- **Current** **Status**: Displays the current status of the failover recovery process. The current status can be one of the following:
  - **Pending**: The failover recovery is initiated for a failover association and the recovery process will start soon.
  - **Calculating**: The appliance calculates the total amount of leases to be processed.
  - **Applying**: The appliance looks for conflicts and tries to resolve the conflicts.
  - **Completed**: The failover recovery is completed successfully.
  - **Failed**: The failover recovery fails.

Grid Manager also displays the reason for the failure if that happens.

After successful completion of the failover recovery, you must restart both the primary and secondary peers to bring them back to the **CONFLICT-DONE** state.  
You can stop the failover recovery operation by clicking **Stop** in the *Failover* *Recovery* *Progress* dialog box before the recovery process is complete.

> ⚠️ **Note**
> ⚠️ 
> ⚠️ If for any reasons the recovery is blocked when the operation is in progress, you can cancel the current operation and start the recovery for the failover association again.