Failover gives you two firewalls acting as one for redundancy. Clustering takes that idea and scales it out: up to sixteen Cisco ASA units pooled into a single logical firewall that shares both the load and the state. When you outgrow what one box (or one active/standby pair) can forward, clustering is how you add throughput without adding management surface, because the whole cluster still looks and behaves like one firewall. This article is part of the Cisco ASA series, and it is written from a lab that could not run it: the virtual asav 9.24 appliance rejects the cluster commands outright. That rejection is real, we captured it, and it tells you exactly where clustering does and does not live.
What Clustering Is For
A cluster is a group of ASA units that pool their resources and act as one logical device for both configuration and traffic. You configure it once, from the control unit, and that configuration replicates to every member. Traffic is spread across all the members, so the aggregate forwarding capacity scales roughly with the number of units, and if a member fails, the connections it was handling are picked up by the survivors from replicated state. In one feature you get horizontal scale (more throughput than any single box) and resilience (loss of a member does not drop the cluster). This is a different goal from failover: failover is about surviving the loss of a unit, clustering is about surviving it and using all the units at once for capacity.
The cluster elects a control unit (sometimes called the master) that owns the configuration and coordinates the cluster; the rest are data units. You make configuration changes only on the control unit and they propagate. If the control unit fails, the cluster elects a new one from the remaining members, and forwarding continues throughout. The whole point is that no single member is special from a traffic standpoint: every unit forwards, and the control role is just coordination.
Two Interface Modes: Spanned vs Individual
How the cluster presents its interfaces to the surrounding network is the single most important design choice, and there are two modes.
Spanned EtherChannel Mode
In spanned EtherChannel mode, the interfaces of every cluster member are bundled into a single EtherChannel that spans all the units, and the surrounding switches see one Port-channel with one set of MAC and IP addresses. The switch load-balances flows across the member links using its normal EtherChannel hashing, and each flow lands on whichever unit owns that member link. The cluster is completely transparent at Layer 2 and Layer 3: neighbors see one interface, one MAC, one IP, regardless of how many units are behind it. This is the recommended and most common mode, because it needs no routing awareness of the individual units and it fails over invisibly. It does, however, depend on the surrounding switches supporting a spanned EtherChannel (often via VSS or vPC on the switch side) so the bundle can cross multiple physical chassis.
Individual Interface Mode
In individual interface mode, each cluster member has its own IP address on the data interfaces, and the network is made aware of all of them, typically through dynamic routing with equal-cost multipath so traffic is distributed across the members' addresses. The control unit owns a main cluster IP for management, but data-plane traffic reaches each member on its own address. This mode does not require spanned EtherChannel support on the switches, but it does require the surrounding Layer 3 network to participate in distributing traffic (usually via routing and ECMP), which means more routing configuration and less transparency than spanned mode. It is the choice when the switching layer cannot provide a spanned EtherChannel but the routing layer can spread the load.
The Flow Roles: Owner, Director, Forwarder
Clustering's cleverness is in how it keeps a single connection consistent across many units. Because the switch or router may deliver different packets of the same flow to different members, the cluster assigns roles per connection so exactly one unit remains authoritative:
- Owner. The unit that first received the connection's initial packet. The owner holds the full connection state and processes the flow. There is one owner per connection.
- Director. A unit chosen (by a hash of the connection) to be the backup keeper of the connection's state and the lookup authority for it. If another unit receives a packet for a connection it does not own, it asks the director who the owner is. The director also holds a backup of the state, so if the owner fails, the director can promote a new owner without dropping the connection.
- Forwarder. A unit that receives packets for a connection it does not own. It consults the director, learns the owner, and forwards the packets to the owner over the cluster control link. Forwarding is the mechanism that lets asymmetric delivery still resolve to a single authoritative owner.
These roles are per connection, not per unit: the same physical box can be the owner of one flow, the director of another, and a forwarder for a third, all at once. Together they guarantee that every connection has exactly one owner processing it and one director backing it up, no matter how the network sprays packets across the members. This is what makes the cluster behave like one stateful firewall rather than sixteen independent ones.
Connection Redistribution When Membership Changes
When a unit joins or leaves the cluster, the connection ownership has to rebalance. If a member fails, the connections it owned are recovered by their directors, which promote new owners from the surviving members using the backed-up state, so established sessions survive the loss of their owning unit. When a new member joins, the cluster begins directing new connections to it (existing connections generally stay with their current owners to avoid needless disruption). The control link, a dedicated cluster interface between all members, carries this state backup, the director lookups, and the forwarded packets, so it must have enough bandwidth and low enough latency to keep up with the cluster's load. An undersized or congested cluster control link is a classic cause of clustering instability, because everything that keeps the cluster coherent rides across it.
The Real asav Rejection
All of this is hardware territory. Our lab firewalls are virtual asav 9.24 instances, and the cluster commands are simply not in the virtual appliance's parser. Setting the interface mode and checking cluster status, this is exactly what the real device returned:
The cluster interface-mode command is rejected at the parser (the caret sits under the very first keyword), and show cluster info reports that clustering is not configured, with no commands available to configure it. This is not a licensing gate or a hidden mode; the clustering feature set is absent from asav. The honest takeaway is that ASA clustering is a physical-appliance capability, and the parser reject above is the proof.
Which Platforms Support ASA Clustering, and the Modern Answer
ASA clustering runs on specific physical ASA and Firepower models and software versions (the exact list depends on the hardware generation and release, so always check the release notes for your platform). The virtual asav is not among them. If you need scale-out on virtual or on modern hardware, the direction Cisco has invested in is FTD (Firepower Threat Defense): Firepower clustering leans on spanned EtherChannel much like ASA clustering, and FTD multi-instance lets you carve appliances into isolated logical devices. For a virtual scale-out story, FTD and its clustering and multi-instance features are where the engineering effort has gone, not asav. On the ASA virtual appliance itself, the resilience story you actually have is the one you can prove: Active/Standby failover, which the asav supports fully and which we demonstrated in this same lab with a zero-loss failover of a live traffic stream. Clustering scales beyond that, but only on the platforms that carry the feature.
Configuring a Cluster on Hardware, in Outline
On a supported physical platform, bringing up a cluster follows a repeatable shape. You set the interface mode first, because it cannot be changed while clustering is running, then define the cluster group and its control link, then bootstrap each member. The skeleton looks like this on the first (control) unit:
cluster interface-mode spanned
!
interface TenGigabitEthernet0/6
description Cluster Control Link
no shutdown
!
cluster group PINGLABZ-CL
local-unit unit-1
cluster-interface Port-channel1 ip 10.0.0.1 255.255.255.0
priority 1
enableEach additional unit gets the same cluster group configuration with its own local-unit name and control-link address, and joins the existing cluster rather than forming a new one. Once a unit runs enable in the cluster group, it discovers the others over the control link, the cluster elects a control unit by priority, and the configuration replicates outward. From that point you manage the whole cluster from the control unit, and show cluster info lists every member with its role and state. The two decisions you make up front, the interface mode and the control-link interface, are the ones that are painful to change later, so they deserve the most design thought.
How Clustering Differs From Failover
It is easy to blur clustering and failover together because both give resilience, but they answer different questions and it is worth being precise. Failover (Active/Standby) is about availability: two units, one forwarding, one waiting, and the standby exists purely to take over. You do not get more capacity from the standby; it is insurance. Clustering is about availability and capacity: every member forwards all the time, so adding a unit adds throughput, and the loss of a unit costs you that unit's share rather than everything. Failover tops out at two units; clustering scales to many. Failover state replication is a simple primary-to-standby copy; clustering state is distributed with the owner/director/forwarder roles so that any member can be lost without a single point holding all the state. If your problem is "one firewall might die," failover solves it cheaply. If your problem is "one firewall (or one pair) cannot forward enough traffic," only clustering solves it, and only on the platforms that support it.
There is also a management difference. A failover pair is configured largely as one unit with a mirrored partner; a cluster is configured once on the control unit and pushed to all members, and the cluster elects a new control unit automatically if the current one fails. The result is that a sixteen-unit cluster is no more management work than a single firewall, which is a large part of its appeal at scale.
Clustering Gotchas Worth Knowing
A few realities catch people the first time they build a cluster. The interface mode (spanned or individual) is set before clustering is enabled and cannot be flipped on a live cluster, so choosing wrong means a disruptive rebuild; decide based on whether your switching layer can provide a spanned EtherChannel. The cluster control link is not a place to economize: it carries state backups, director lookups, and every forwarded packet for asymmetric flows, so it should be high-bandwidth and ideally its own EtherChannel, and it must have consistent low latency across all members (which practically limits how far apart cluster members can sit). Not every ASA feature is supported in clustering, and some behave differently when clustered, so the feature matrix in the release notes for your platform is required reading rather than optional. Finally, clustering asymmetric traffic still costs a control-link hop through the forwarder to reach the owner, so a design that constantly sprays both directions of every flow across different members will lean hard on the control link; the more symmetric your traffic delivery, the less forwarding overhead the cluster pays. None of these apply on asav, of course, because the feature never initializes there in the first place.
Key Takeaways
- Clustering pools up to sixteen ASA units into one logical firewall that shares load and state, scaling throughput while still managing as a single device from the control unit.
- Spanned EtherChannel mode presents one interface, one MAC and IP to the network (transparent, recommended, needs VSS/vPC-style switches); individual interface mode gives each member its own IP and relies on routing/ECMP to distribute traffic.
- Per-connection roles keep the cluster coherent: the owner processes the flow, the director backs up its state and answers ownership lookups, and a forwarder relays packets it received to the owner over the control link.
- On member failure, directors promote new owners from backed-up state so connections survive; the cluster control link must be sized for state backup, lookups, and forwarded traffic.
- On asav 9.24 the feature is absent:
cluster interface-mode spannedreturns% Invalid input detected at '^' marker.andshow cluster infosays clustering is not configured. - Clustering is a physical ASA/Firepower feature; for virtual scale-out the modern answer is FTD clustering or multi-instance, and on asav itself the proven resilience is Active/Standby failover. See the Cisco ASA pillar.
