ASA Active/Active Failover: Failover Groups and Asymmetric Reality

Active/Active failover is the design people reach for when Active/Standby feels wasteful: instead of one firewall doing all the work while its partner idles, both units forward traffic at the same time. It sounds like the obviously better option, but it carries a hard prerequisite (multiple context mode) and a subtle trap (asymmetric routing) that make it the wrong default for most deployments. This article is part of the Cisco ASA series, and it is written from a lab where we tried to enter the mode Active/Active needs on a real virtual ASA (asav 9.24) and the parser said no. We will show you that refusal, and then show you the capture that proves what you should be doing instead: a zero-loss Active/Standby failover on the very same pair.

How Active/Active Actually Works

Active/Active failover does not mean one giant firewall spread across two boxes. It means you split the ASA into failover groups, and each group is active on a different physical unit. A failover group is a set of security contexts (virtual firewalls). Group 1 is active on the primary unit, group 2 is active on the secondary. Traffic destined for the contexts in group 1 flows through the primary; traffic for the contexts in group 2 flows through the secondary. Both boxes forward simultaneously, so you are using hardware you would otherwise leave cold.

Each failover group still has a standby copy on the other unit. So the primary is active for group 1 and standby for group 2; the secondary is active for group 2 and standby for group 1. If the primary dies, its group 1 fails over to the secondary, which is then active for both groups (and now doing all the work, exactly as an Active/Standby pair would). When the primary recovers, group 1 can preempt back to it if you configure preemption. This is load-sharing, not load-balancing: you are statically assigning halves of your firewall to different boxes, not spreading a single flow across both.

You control which unit owns each group with primary and secondary preferences per group, and you can weight interface monitoring and polling per group as well. The mental model that helps: Active/Active is two Active/Standby pairs sharing the same two chassis, offset so each box is the active member of one pair and the standby of the other.

Why It Requires Multiple Context Mode

Here is the prerequisite that decides everything. Failover groups are built out of security contexts, and contexts only exist in multiple context mode. A single-context ASA has exactly one firewall and nothing to split into two groups, so there is no Active/Active to configure. Cisco's own documentation states it plainly: Active/Active failover is only supported in multiple context mode. That is not a soft recommendation; it is a structural dependency. No contexts, no groups; no groups, no Active/Active.

This is why any serious look at Active/Active is really a look at multiple context mode first. You have to convert the firewall to multiple mode, define your contexts, allocate interfaces to them, assign the contexts to failover group 1 or group 2, and then let the two groups land on different units. If you have never worked with contexts, start with the ASA multiple context mode fundamentals, because everything in Active/Active is built on top of them.

The Asymmetric Routing Problem (and asr-group)

Now the subtle trap. Because both units forward at once, and because the routers around them may pick different paths for the two directions of a conversation, you can end up with a flow whose outbound packets leave through the unit that owns group 1 and whose return packets arrive at the unit that owns group 2. The unit that receives the return traffic has no connection-table entry for it (the connection was built on the other unit), so it drops the return packets as out-of-state. The session breaks, and it breaks intermittently in a way that is genuinely painful to diagnose, because a simple ping might work while a stateful TCP session does not.

The ASA fixes this with asymmetric routing groups, configured with the asr-group command on the interfaces that might receive asymmetric return traffic. When a unit receives a packet for a connection it does not own, it checks the interfaces in the same asr-group on its failover peer. If the peer owns the connection, the receiving unit forwards the packet to the peer over the stateful failover link, the peer processes it against its real connection entry, and the session survives. In effect, asr-group lets the two units cover for each other's connections when the surrounding routing is not symmetric.

interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address 203.0.113.10 255.255.255.0 standby 203.0.113.11
 asr-group 1

You put the same asr-group number on the corresponding interfaces in both failover groups. It works, but notice what it costs: return traffic can now take an extra hop across the state link before it is processed, which adds latency and load, and it only papers over a routing design that is asymmetric in the first place. Many engineers who reach Active/Active for the load-sharing discover that the asymmetric-routing handling eats much of the benefit and adds operational complexity they did not want.

The Real asav Refusal

This is where the lab keeps everyone honest. To do Active/Active you must first be in multiple context mode. Our firewalls are virtual asav 9.24 instances, and the virtual appliance does not support multiple contexts at all. Checking the current mode and trying to change it, this is exactly what the real device returned:

The mode is fixed at single, and mode multiple is not a valid command on asav. Because you cannot enter multiple context mode, you cannot create failover groups, and because you cannot create failover groups, you cannot configure Active/Active. The whole feature is unreachable on the virtual appliance, and the parser tells you so at the very first step. This is consistent with Cisco's documentation that the asav does not support multiple contexts and that Active/Active requires multiple context mode. There is no workaround on asav; the honest answer is that this feature belongs to physical ASA hardware.

What You CAN Do Virtually: Zero-Loss Active/Standby

Here is the counterpoint that matters. On the exact same pair of asav instances that refused Active/Active, Active/Standby failover works completely, and it works well. We proved it. We ran a 45-packet ping stream from an inside host through the firewall to an outside address at 0.3-second intervals, and mid-stream we forced the active unit to give up the active role. The result was not a blip, not a few dropped packets during convergence. It was nothing:

Forty-five sent, forty-five received, zero percent loss, straight through a full active-unit failover. Stateful failover had already replicated the connection table to the standby, so when the standby took over the active IP and MAC, the live ICMP stream never lost a single packet. The connection did not have to be rebuilt because the standby already knew about it. That is the redundancy story you can lab on virtual today, and it is genuinely excellent.

Active/Active vs Active/Standby: Which To Choose

For most designs, Active/Standby is the right answer. It is simpler, it has no asymmetric-routing exposure, it does not force you into multiple context mode, and its failover is stateful and effectively lossless. Active/Active earns its complexity only when you genuinely need both boxes forwarding at once (typically a multi-tenant deployment already running contexts) and you have the routing discipline to keep paths symmetric or the asr-group configuration to handle them when they are not. If you are not already in multiple context mode for another reason, converting to it just to get Active/Active is usually a poor trade.

And if your ASA is virtual, the decision is made for you: Active/Active is not available, and Active/Standby is, so use it. The proof is above. On virtual, put your effort into a clean, well-monitored Active/Standby stateful failover pair rather than chasing a mode the appliance cannot enter.

Building Active/Active on a Physical ASA, Step by Step

On supported hardware the build is a sequence, and the order is what trips people up. You cannot sprinkle these commands in randomly; each step depends on the one before it. Here is the shape of it:

• Convert to multiple context mode. mode multiple reboots the firewall into the multi-context system space. This is the step that fails outright on asav.
• Create the contexts. In the system context, define each context, allocate its interfaces, and point it at its config file (typically in flash). These contexts are the tenants you will split across units.
• Configure the failover link and state link. These live in the system context and are shared by both groups. As with any ASA failover, the failover link carries hellos and config replication; the state link carries the connection table for stateful failover.
• Define failover group 1 and group 2. Set each group's unit preference (primary or secondary), polling and holdtimes, interface-monitoring policy, and optionally preempt so a recovered unit reclaims its group.
• Assign each context to a group. join-failover-group 1 or 2 inside each context. This is the line that decides which physical unit forwards that tenant's traffic.
• Enable failover on both units and let them synchronize.

A minimal skeleton for the two groups in the system context looks like this:

failover group 1
 primary
 preempt
failover group 2
 secondary
 preempt
!
context CUSTOMER-A
 join-failover-group 1
context CUSTOMER-B
 join-failover-group 2

Now group 1 (CUSTOMER-A) is active on the primary unit and group 2 (CUSTOMER-B) is active on the secondary, with each group's standby copy sitting on the opposite box. That is the entire load-sharing mechanism: two groups, offset across two chassis.

Stateful Replication Still Applies, Per Group

Active/Active does not change the fundamentals of stateful failover; it just runs them twice. Each failover group replicates its own connection table, translation table, and other stateful data to its standby copy on the peer unit over the shared state link. When group 1 fails from the primary to the secondary, the secondary already holds group 1's connection state and can carry the existing sessions without rebuilding them, exactly the way an Active/Standby pair does. The difference is only that the same state link is now carrying replication for both directions at once, which is one more reason the state link should be a high-bandwidth interface (or an EtherChannel, pre-configured on both units before failover comes up).

Interface monitoring also runs per group. Each failover group independently decides whether it should fail over based on the health of the interfaces belonging to its contexts. This means one group can fail over to the peer while the other group stays put, which is the fine-grained behavior that makes Active/Active attractive for multi-tenant designs: a fault that only affects one tenant's interfaces moves only that tenant's group, not the whole firewall.

Common Active/Active Mistakes

The failure modes cluster around the prerequisites and the routing. The first is trying to configure it in single mode and getting nowhere, because the failover-group commands do not exist until you are in multiple context mode. The second is ignoring asymmetric routing until sessions start breaking intermittently in production, then scrambling to add asr-group after the fact. The third is oversubscribing a single unit: remember that in a failure, one box carries both groups, so if each unit is already running near capacity in steady state, a failover will overload the survivor. Size each unit to carry the full load of both groups, not half. If you cannot, you have built a design that is faster in the good case and broken in the bad case, which defeats the purpose of high availability.

Key Takeaways

• Active/Active splits the firewall into two failover groups, each active on a different unit, so both boxes forward traffic (load-sharing, not load-balancing).
• It structurally requires multiple context mode, because failover groups are built from security contexts. No contexts means no Active/Active.
• Because both units forward, asymmetric routing can deliver return traffic to the wrong unit; asr-group lets units forward such traffic to the connection owner over the state link.
• On asav 9.24 the feature is unreachable: show mode is fixed at single and mode multiple returns % Invalid input detected at '^' marker.
• On the same asav pair, Active/Standby failover is fully supported and proven lossless: 45 of 45 pings survived a live failover at 0% loss.
• Choose Active/Standby for most designs and for all virtual ASAs; reserve Active/Active for physical, multi-context deployments that truly need both units active. See the multiple context mode guide and the Cisco ASA pillar.