Onboarding an FTD HA Pair: The Version That Blocks the Cutover
A financial-services customer has taken delivery of two Secure Firewall 2130 appliances for an active/standby pair in a new data center pod. Cisco Firepower Management Center 7.2.0 at 10.10.10.10/24 is already in production. Unit A shipped with FTD 7.2.0; unit B, ordered three weeks earlier, arrived with 7.0.4 and was never upgraded. The engineer assigns an identical interface layout on both units (Ethernet1/1 outside, Ethernet1/2 inside, Ethernet1/9 reserved for the dedicated failover link), registers both management addresses, 10.10.20.11 and 10.10.20.12, to the FMC, and then creates the high-availability pair from Devices > Device Management. The task fails after roughly four minutes and the two devices are flagged in FMC as not matching. The change window is four hours long, traffic cannot slide to another site, and the customer will not accept any design that removes redundancy while the pair is being built.
1. Why did the add-HA task fail, and what sequence gets a working pair inside the four-hour window?
Read the worked answer
The blocker is the software version, not the design. An FTD high-availability pair requires both units to be the same model and to run the same FTD version; FMC validates this when the pair is created and refuses to build it otherwise, which is why the task dies after a few minutes instead of hanging. Two identical 2130s at 7.2.0 and 7.0.4 do not qualify, no matter how carefully the interfaces are matched.
Sequence that fits the window:
- Confirm nothing partially formed. Both units should still appear as standalone devices. If a half-built HA object exists, delete it and deploy so each unit returns to a clean standalone state.
- Deploy any pending configuration to unit B and take a platform backup before touching it.
- Upgrade unit B through FMC (Devices > Device Management > Upgrade) to 7.2.0. Image copy, install and reboot typically cost 30-60 minutes; start this first because everything else waits on it.
- When B returns, verify it reports the same version and build as A, that both are registered and healthy, and that no deployments are pending.
- Recreate the HA pair with A as preferred active, deploy, and perform one controlled failover while the on-site team is still available.
Do not attempt to force a mixed-version pair; it will not form and only consumes window time.
2. What do you verify between step 4 and step 5 so the second attempt does not fail for a completely different reason?
Read the worked answer
Re-check the whole HA precondition set, because a second failure in a four-hour window is expensive:
- Model and version: identical appliance model, identical FTD version and build. Mixing a 2130 with a 2140 is not supported as a pair.
- Interface parity: the same physical ports must be used on both units, with the same media type. Ethernet1/9 on A and Ethernet1/9 on B is the requirement, not merely 'a port that exists'.
- Failover link: the dedicated failover interface must be on the same port, on its own Layer 2 segment with its own subnet, carrying nothing else and not routed. Sharing it with user VLANs is a classic cause of a failed or flapping pair.
- Management reachability: both management IPs must be on the same network and reachable from the FMC over TCP 8305. If one management path is hairpinned through NAT or blocked, registration may look fine while the HA build fails.
- Time and identity: both units synchronized to the same NTP source, unique management addresses, and licensing satisfied so that neither unit is in an evaluation or out-of-compliance state.
Only when each item is confirmed should you create the pair.
3. Once the pair is built, where is the access control policy assigned, and what happens to deployments if one unit's management path fails later?
Read the worked answer
Assign the access control policy once, to the high-availability pair object in FMC, not to the individual chassis. The pair is presented as a single managed device; you do not create separate device records for A and B, and you should not manage the units individually.
Behind that abstraction, FMC deploys to each unit separately over its own management IP using the sftunnel connection on TCP 8305. The active unit applies the configuration and traffic; the standby receives and stages it so it can take over.
Consequences to plan for:
- Losing either management path breaks deployments for the whole pair even while the data plane keeps forwarding. The visible symptom is a deployment task that succeeds for one unit and times out for the other, plus a configuration mismatch between the two.
- The fix is to restore reachability to the affected management address (routing, ACL on an intermediate firewall, 8305 permitted in both directions), then redeploy and confirm both units report the same policy version.
- Verify with the FMC deployment task detail and with 'show managers' on each unit; a standby that has not received the last deployment is not a standby you want to rely on during a failover.