Guide
Firewall Clustering vs HA: Choosing a Scale Model
Failover buys you a spare; clustering buys you a bigger firewall. The two answer different questions, and the blueprint expects you to know which question you are asking.
Two Secure Firewall features answer the question “what if this box is not enough” — high availability and clustering — and they answer different versions of it. Failover protects you from a box dying. Clustering protects you from a box being too small. The SNCF blueprint lists both under its high availability objective (1.3), and confusing them leads to designs that buy redundancy when the problem was capacity, or capacity when the problem was risk.
Failover: A Spare With State
Threat Defense high availability is an active/standby pair. Two identical units — same model, same software version — connect over a dedicated failover link; state replication shares that link or uses a separate one. The active unit processes all traffic. The standby holds a continuously synchronized copy of the configuration and, with stateful failover, of the connection table: TCP state, translations, and related session data replicate as they are created. When the active unit fails — or a monitored interface goes down past the configured threshold — the standby assumes the active role and the shared interface identity, and the connections whose state was replicated continue through it without being rebuilt.
The design point to internalize: a failover pair adds no capacity. The standby forwards nothing while the active is healthy. If a single unit cannot carry your traffic, a second unit in standby will not help — you have bought insurance, not throughput. What failover buys is a bounded failure: seconds of convergence instead of an outage, with sessions preserved.
Clustering: Several Boxes, One Firewall
Clustering combines multiple identical units into one logical firewall. The units elect a control unit; the rest join as data units. Configuration is made once and synchronized from the control unit, and the manager treats the cluster as one logical device. Unlike a standby, every member forwards traffic.
Two fabric pieces make that work. On hardware platforms, the design groups data interfaces as spanned EtherChannels — a single port channel per data interface, spanning every cluster member, so the adjacent switches balance flows across units as ordinary EtherChannel load balancing. And a dedicated cluster control link connects the members, carrying cluster control traffic and, critically, packets redirected between units.
Redirection exists because the switches do not understand connections. Each flow through the cluster has an owner — the unit that processes it — and a director, a unit that keeps the owner lookup for that flow. When load balancing lands a packet on a unit that does not own its connection, that unit asks the director and forwards the packet to the owner across the cluster control link. Connection state is also replicated so that flows survive a member failure. All of this overhead is why capacity does not sum: Cisco’s sizing guidance is to expect roughly 80 percent of the members’ combined throughput, not the arithmetic total — and to size the cluster control link generously, because asymmetry lands there.
One more asymmetry between the features: in a cluster, some functions are centralized — handled only by the control unit — and some features are not supported in cluster mode at all. The supported-feature list for your release is part of the design work, not an afterthought.
Choosing
Ask which failure you are engineering against. If one unit carries the load and the risk is losing it, failover is the answer: simpler, cheaper in switch configuration, and it preserves sessions — most sites need exactly this, and failover done right is its own discipline. If the load itself exceeds one unit — throughput, connection rate, or connection count — clustering is the answer, and it brings availability with it, since the cluster redistributes a failed member’s flows. The costs of clustering are operational: spanned EtherChannel design on the adjacent switches, a cluster control link to size and protect, and the centralized-feature list to respect. Do not deploy a cluster of two for redundancy alone; that is failover’s job, done with less machinery.
For the exam, place the vocabulary precisely: active/standby, stateful failover, and monitored interfaces belong to HA; control unit, data unit, spanned EtherChannel, cluster control link, owner, and director belong to clustering. Both live under SNCF objective 1.3, and the SNCF course builds each in the lab — first a failover pair you deliberately break, then a cluster you watch rebalance. The wider design context — where the firewall sits and what carries its traffic — is the catalog’s recurring theme.
Frequently Asked Questions
Does adding a standby firewall double my throughput?
No. In an active/standby failover pair only the active unit forwards traffic; the standby holds synchronized configuration and connection state so it can take over, but it contributes no capacity. A failover pair's throughput is one unit's throughput. Scaling capacity across multiple units is what clustering is for.
Can I mix different firewall models in an HA pair or cluster?
No. Both failover and clustering require units of the same model with matching software versions and interface configuration. Capacity planning has to be done with identical units in mind — you cannot pair a small appliance with a large one and average the difference.
What happens to existing connections when a cluster member fails?
Clustering replicates connection state so that flows whose state was replicated can be recovered by the units holding their backup state, with new packets redirected to the new owner; features that do not replicate state rebuild instead. The cluster heals around the loss with the remaining capacity; sizing should assume the cluster still carries the load with one member gone.