Cisco Secure Firewall — HA, Clustering & Troubleshooting

① Active/Standby failover — two boxes, two links, stateful sessions

The most common FTD resilience design is Active/Standby failover (HA): two identical FTDs — same model, same software — paired so one is active and one is standby. You configure it in FMC under Device Management ▸ High Availability.

Two links do two jobs. The failover link carries heartbeats and health information. The separate stateful failover (state) link replicates the connection table, NAT translations and VPN SAs from active to standby, so live sessions survive a switchover. Monitored interfaces trigger failover: if the active loses a watched interface, the standby takes over.

What happens on failover

When the standby promotes to active, it takes over the active unit's IP and MAC addresses, so the network barely notices. Because the state link already replicated the sessions, existing connections keep flowing instead of resetting. Check status any time with show failover.

② Clustering for scale — many units, one logical firewall

When one box can't push enough throughput, you use clustering: up to 16 units act as one logical device for both scale and redundancy. Units join the cluster over the Cluster Control Link (CCL).

One unit is elected the control unit (it handles configuration and decisions for the group); the rest are data units. Traffic is spread across all units using a spanned EtherChannel, so the upstream switch sees one logical link and load-balances flows to the cluster.

HA vs clustering — pick the right tool

Use Active/Standby HA when one box has enough capacity and you just need a hot spare. Use clustering when a single appliance can't carry the load and you need to scale horizontally and keep redundancy. Clustering is about throughput; HA is about a clean standby.

③ FMC HA — protect the manager, not the data path

The data plane is only half the story — the manager needs resilience too. FMC HA is a primary/secondary FMC pair that keeps configuration in sync, so if the primary fails you still have a working management console. You can switch roles between the two when you need to.

Here is the line that trips people up in interviews: FMC HA protects the manager, not the data path. If the active FMC goes down, your FTDs keep passing traffic using their last deployed policy — what you lose is the ability to make changes, see new events centrally and deploy. To protect traffic forwarding you need device-level HA or clustering; FMC HA simply makes sure you never lose the console that drives them.

④ The troubleshooting toolkit — which engine dropped the packet?

FTD is a unified image: the LINA data plane handles routing, ACL and NAT, while Snort does deep inspection (IPS, application, file/malware). The number-one diagnostic skill is working out which engine dropped a packet.

Start with packet-tracer: it pushes a synthetic packet through the policy and tells you the exact phase that allowed or dropped it. Confirm with real capture / capture-traffic on LINA and on the Snort interface, and inspect the live show conn connection table. For Snort verdicts, use system support trace and firewall-engine-debug to see why Snort allowed or blocked.

From the box to the SIEM

In FMC, the Health Monitor and health policies flag failing units, links and processes. Connection and intrusion events (and the combined Unified Events view) show what the policy actually did, and the Message Center / Task status tracks deploys. Export everything to a SIEM via syslog and eStreamer. The rule of thumb: ACL/NAT problems live in LINA; IPS/file blocks live in Snort.