History for high availability

This reference provides a chronological history of high availability features, enhancements, and improvements implemented across various software versions. The information helps you track the evolution of high availability capabilities and understand when specific features were introduced.

Feature

Minimum Cloud-Delivered Firewall Management Center

Minimum Firewall Threat Defense

Details

High availability support for the manager access data interface

7.4

7.4

You can now use a data interface for manager access with Firewall Threat Defense high availability.

Unregistering a high-availability pair now allows you to re-register without breaking the pair

7.3

Any

When you DELETE (unregister) a high-availability pair, you no longer have to manually break the pair at the CLI and re-register standalone devices. You can now add the primary unit to a new Cloud-Delivered Firewall Management Center, and the standby unit will be discovered automatically. Re-registering the pair will still erase the configuration, and your policies will need to be re-applied.

Policy rollback support for high availability

7.2

Any

The configure policy rollback command is supported for high availability.

Config-Sync Optimization feature for faster HA peering

7.2

Any

The Config-Sync Optimization feature enables comparing the configuration of the joining unit and the active unit by exchanging config-hash values. If the hash computed on both active and joining units match, the joining unit skips full config-sync and rejoin the HA. This feature enables faster HA peering and reduces maintenance window and upgrade time.

Improvements to the upgrade workflow for clustered and high-availability devices

7.1

Any

We made improvements to the upgrade workflow for clustered and high-availability devices:

  • The upgrade wizard now correctly displays clustered and high-availability units as groups, rather than as individual devices. The system can identify, report, and preemptively require fixes for group-related issues you might have. For example, you cannot upgrade a cluster on the Firepower 4100/9300 if you have made unsynced changes on Firepower Chassis Manager.

  • We improved the speed and efficiency of copying upgrade packages to clusters and high-availability pairs. Previously, the FMC copied the package to each group member sequentially. Now, group members can GET the package from each other as part of their normal sync process.

  • You can now specify the upgrade order of data units in a cluster. The control unit always upgrades last.

Clearing routes in a high-availability group or cluster.

7.1

Any

In previous releases, the clear route command cleared the routing table on the unit only. Now, when operating in a high-availability group or cluster, the command is available on the active or control unit only, and clears the routing table on all units in the group or cluster.

FTD High Availability Hardening

6.2.3

Any

Version 6.2.3 introduces features for FTD devices in high availability:

  • Whenever active or standby FTD devices in a high-availability pair restart, the FMC may not display accurate high-availability status for either managed device. However, the status may not upgrade on the FMC because the communication between the device and the FMC is not established yet. The Refresh Node Status option on the Devices > Device Management page allows you to refresh the high-availability unit status to obtain accurate information about the active and standby device in a high-availability pair.

  • The Devices > Device Management page of the FMC UI has a new Switch Active Peer icon.

  • Version 6.2.3 includes a new REST API object, Device High Availability Pair Services, that contains four functions:

    • DELETE ftddevicehapairs

    • PUT ftddevicehapairs

    • POST ftddevicehapairs

    • GET ftddevicehapairs