ASA Failover

 

Introduction to ASA Failover

Cisco ASA devices offer high availability and redundancy through failover mechanisms. These failover strategies ensure minimal disruption and continued network security operations even in the event of device or link failures. Understanding the types of failover and how they are implemented is essential for designing resilient ASA deployments.

 

Failover Types

There are three primary types of failover supported in ASA: Stateless Failover, Hardware Failover, and Stateful Failover.

Stateless Failover provides basic logical redundancy. If the primary path fails, traffic is simply rerouted through the secondary path. However, because connection states are not maintained, users may experience session drops and will have to re-establish connections.

Hardware Failover offers physical redundancy and configuration replication between devices. While this ensures that the secondary device has the correct configuration, it does not maintain active session state. Therefore, any ongoing connections will need to be re-established after failover occurs.

Stateful Failover is the most seamless option. It not only replicates configuration changes but also maintains session state information. Key components replicated during stateful failover include the ARP table, Xlate (translation) table, VPN connections, and the connection table itself. With this mode, if the active unit fails, the standby takes over without requiring connections to be re-initiated, offering a near-transparent experience for end users.

 

Failover Implementation Types

Cisco ASA supports two failover implementation modes: Active-Standby and Active-Active.

Active-Standby mode requires two ASA units, one designated as primary (active) and the other as secondary (standby). The active unit handles all traffic, while the standby remains idle but synchronized. If the active unit fails, the standby immediately takes over, ensuring continuity. This mode supports both single and multiple context environments and is typically used in environments that require simplicity and straightforward failover logic.

Active-Active mode also requires two units but mandates multiple security contexts or virtual firewalls. In this mode, each ASA unit is active for different security contexts, enabling load sharing across appliances. Both devices can pass network traffic concurrently, maximizing hardware utilization. This mode is only supported in multiple context configurations and is ideal for larger, more complex environments that demand high throughput and scalability.

Both implementation modes can operate with either stateless or stateful failover, depending on the desired level of redundancy and session persistence.

 

ASA Failover System Requirements

For Cisco ASA failover to function reliably, both hardware and software on the participating units must meet strict compatibility requirements. These ensure seamless synchronization and uninterrupted service during failover events.

Hardware Requirements

All devices in a failover pair must have matching hardware configurations. This includes using the same model of ASA appliance, having an identical number and type of interfaces, the same amount of RAM, and identical Security Services Modules (SSMs), if any are installed. A notable exception applies to flash memory: while the flash sizes may differ, the unit with smaller flash storage must still be able to accommodate the full software image and configuration files. Otherwise, synchronization will fail, disrupting failover capabilities.

 

Software Requirements

Both units must be in compatible operating modes. While ASA does allow for version mismatches during an upgrade process, it is strongly recommended to use the same software version on both devices for optimal performance and stability.

 

ASA Failover Links

The backbone of ASA failover communication is the failover link. This dedicated connection allows the two ASA units to constantly exchange status information, ensuring that failover events are detected and handled in real time.

For Stateful Failover, this link plays an even more critical role. It facilitates the synchronization of session and configuration data between the active and standby units, allowing connections to remain uninterrupted during a switchover.

The failover link performs several essential functions:

• Reports unit state (active or standby)
• Sends hello messages (keepalives) to ensure availability
• Monitors network link status
• Exchanges MAC address information for continuity
• Handles configuration replication and synchronization

It’s important to note that, by default, all data sent over failover and stateful failover links is transmitted in cleartext. To protect this sensitive communication, especially in environments where security compliance is critical, it’s recommended to encrypt failover traffic using IPsec or a secure key mechanism.

 

Types of Failover Links

Cisco ASA supports several types of failover links, depending on the platform and deployment scenario. The most commonly used method in modern deployments is the LAN-based failover link, though older models like the PIX used a dedicated serial cable option.

 

LAN-Based Failover Link

In LAN-based failover, any unused Ethernet interface on the ASA can be designated as the failover link. This offers flexibility in design and allows failover traffic to be carried over standard network infrastructure. However, there are a few important design considerations:

• Isolated Broadcast Domain: If a switch is used to connect the failover interfaces, it must be on a dedicated VLAN or network segment with no other devices present. This isolates failover traffic, preventing interference or security concerns.
• Direct Cable Connection: Alternatively, a crossover Ethernet cable can be used to connect the two ASA units directly. This setup avoids the need for a switch entirely.
• Cable Type Flexibility: ASA devices support Auto-MDI/MDIX on copper Ethernet ports, which means they can automatically detect and adjust for cable type. As a result, either a crossover or straight-through Ethernet cable can be used for direct connections.

 

Serial Failover Link (Legacy)

For legacy PIX firewall devices, failover was handled using a serial cable. While no longer relevant for modern ASA deployments, it’s worth mentioning for historical context or environments still running old hardware.

 

Stateful Failover Link

To fully leverage stateful failover on ASA devices, administrators must configure a stateful failover link—a dedicated channel used to transfer session state information between the active and standby units. This ensures that active sessions, NAT tables, and VPN connections remain intact during a failover.

There are three main options to configure the stateful failover link, and regardless of the method, the goal is the same: to synchronize runtime data such as connection tables and VPN tunnels, providing uninterrupted service during a failover transition.

 

Device Initialization Behavior

Device roles (active vs. standby) are determined during initialization, and the process varies depending on the order and timing of device boot:

• If both units power on simultaneously, the primary unit assumes the active role and the secondary unit becomes standby.
• If a unit boots without detecting a peer, it defaults to the active state.
• If a unit detects an existing active peer on the network, it becomes the standby unit.

It’s also important to understand that MAC addresses on ASA units are tied to the active IP addresses. An exception occurs when the secondary unit becomes active; in that case, MAC-to-IP mapping may change. To prevent this inconsistency—especially in environments with strict Layer 2 policies—it’s best practice to manually configure static MAC addresses.

 

Failover Triggers

Failover events are triggered under several conditions, including:

• Hardware failure on the active unit
• Power loss
• Software crash or unresponsiveness
• Manual intervention using the no failover active command on the current active unit
• Use of the failover active command on the standby unit
• A monitored interface goes down

These triggers are monitored continuously over the failover link, ensuring near-instantaneous response in the event of a critical failure.

 

What Is Not Replicated in Stateful Failover

Despite its robustness, stateful failover does not replicate everything. The following data and elements are not synchronized between ASA devices:

• Operating system images (OS)
• AnyConnect client images
• CSD (Cisco Secure Desktop) images
• ASDM (Adaptive Security Device Manager) images
• Smart tunnel configurations
• Port forwarding rules
• Custom plugins
• Java applets
• IPv6 clientless or AnyConnect sessions
• Citrix authentication sessions (users must reauthenticate after failover)

For these elements, manual synchronization or re-authentication may be required post-failover. Admins should factor this into their operational planning and user experience expectations.

 

Failover Health Monitoring

Cisco ASA uses two key mechanisms to monitor the health of failover peers: Unit Health Monitoring and Interface Monitoring. These tests help determine whether failover should occur due to an unresponsive or failed device.

 

Unit Health Monitoring

ASA devices monitor each other by sending periodic hello messages over the failover link. If a unit fails to receive three consecutive hello messages, it initiates further tests to determine whether the peer is down. The monitoring includes interface-level hello messages to validate the operational status of each physical link. This helps distinguish between a total unit failure and a simple link-level issue.

 

Interface Monitoring

Interface health is determined through several checks:

• Link Up/Link Down: The ASA checks the physical status of each monitored interface. If a link appears operational, the appliance proceeds with deeper tests.
• Network Activity Test: ASA counts received packets for a short interval (typically up to 5 seconds). If no packets are seen, it assumes the interface is idle and starts further diagnostics.
• ARP Test: The device inspects the ARP cache for the two most recently learned entries. It then monitors for ARP replies and packet traffic for up to 5 seconds. If no activity is detected, a ping test is triggered.
• Broadcast Ping Test: This test sends out broadcast ping requests. The unit then listens for return packets and tallies the response count for up to 5 seconds to verify if the interface is truly inactive.

These layered checks ensure accurate detection of real failures versus transient network conditions, preventing unnecessary failover events.

 

Failover Configuration Limitations

There are some constraints to be aware of when deploying ASA failover:

• ASA devices cannot use DHCP- or PPPoE-assigned IP addresses for failover configurations. Static addressing is required for reliable peer-to-peer communication and role assignment.

 

Active/Standby Failover in ASA

The Active/Standby failover model is one of the most commonly deployed high-availability options in ASA environments. It functions by designating one ASA as the active device that handles all traffic while the standby unit waits passively, ready to take over in case of failure.

To successfully implement this architecture, both ASA units must be physically connected to the same Layer 2 segment. This connection facilitates the failover link—often referred to as the “FO link”—which is responsible for tasks such as:

• Sending heartbeat signals to detect peer status
• Replicating configurations
• Sharing cryptographic materials like RSA keys and certificates

In addition to the failover link, a stateful link must also be established, which is likewise required to be a Layer 2 connection. This link is used to replicate dynamic runtime data between the two units, including:

• Connection and translation (xlate) tables
• ARP and routing tables
• VPN peer session information

In many setups, the same physical or logical interface is used for both failover and stateful links, though they can also be separated for greater resiliency.

Only the active ASA unit processes and forwards traffic, and the default gateway should always point to this active device. When failover occurs, IP and MAC addresses from the active unit are assumed by the standby unit, ensuring continuity. However, if the original active ASA is still technically online (such as in a DCI failure between sites), it may continue forwarding traffic—leading to split-brain scenarios. This is why robust Layer 2 Data Center Interconnect (DCI) is essential when deploying across geographic locations.

 

Hardware Requirements for Active/Standby Failover

For the high-availability pair to operate seamlessly, both ASAs must meet strict hardware parity:

• Same ASA model
• Identical CPU and RAM
• Matching hardware modules (e.g., SSMs)

Without this consistency, synchronization issues can occur, degrading failover performance or causing compatibility errors.

 

Failover Logic and Health Checks

Failover decisions are made based on device health. Each ASA continuously monitors its own and its peer’s health through heartbeat messages and interface monitoring. If the currently active ASA becomes less healthy (due to hardware failure, interface down events, or software instability), the standby unit will assume the active role.

However, when deployed across data centers, there’s a significant caveat: if the Layer 2 DCI link fails, the ASAs can no longer communicate to determine relative health. In such cases, the original active ASA will remain active in its current state to prevent “split brain” conditions—where both units might incorrectly believe they are the active device and attempt to forward traffic simultaneously.

 

Primary vs. Active: Understanding the Roles

It’s important to distinguish between primary/secondary and active/standby roles in a failover pair. The primary unit is the preferred device based on configuration, but active simply means the ASA currently handling traffic. For instance, if the primary device fails, the secondary will become active. If the primary comes back online later, it will assume the standby role by default—there is no automatic preemption.

Each ASA has an active IP address and MAC, but if a new unit is introduced into the topology (e.g., to replace a failed ASA), it will have a different MAC address. This change may lead to brief blackholing due to MAC address learning delays. To prevent this, administrators can manually assign virtual MAC addresses in the configuration.

Also, it’s worth reiterating: failover is stateless by default. If you want to maintain session continuity during failover, you must configure stateful failover on the active device.

 

Active-Standby Step-by-Step Configuration

Below is a basic setup for Active/Standby failover using GigabitEthernet0/3 for the FO (failover) and stateful links.

Primary Device Configuration:

failover
failover lan unit primary
failover lan interface FO g0/3
failover key key
failover link FO g0/3
failover interface ip FO 192.168.12.1 255.255.255.0 standby 192.168.12.2

 

Secondary Device Configuration:

failover
failover lan unit secondary
failover lan interface FO g0/3
failover key key
failover link FO g0/3
failover interface ip FO 192.168.12.1 255.255.255.0 standby 192.168.12.2

 

You also need to configure standby IPs for all production interfaces. For example:

interface g0/0
nameif outside
security-level 0
ip address 192.0.2.1 255.255.255.0 standby 192.0.2.3

 

To manually failover to the standby device, use:

no failover active

 

Enhancing and Securing Failover Behavior

The failover command supports multiple optional parameters to fine-tune behavior:

• interface-policy: Handle interface-specific failure behavior
• ipsec: Enables IPSec tunneling for secure FO communication
• key: Assigns a shared key for basic encryption between peers
• mac: Sets a static MAC to avoid learning delays
• mac-notification: Enables MAC address movement tracking
• polltime: Configures heartbeat timing
• replication: Enables HTTP state replication (port 80 not replicated by default)
• standby: Enforces command execution only on standby
• timeout: Sets timeout values for asymmetric routed sessions

 

Example to enable HTTP state replication:

failover replication http

 

To configure polling frequency:

failover polltime unit 5 msec 800
failover polltime interface 500

 

To execute a command remotely from one ASA to the other:

failover exec active # Runs on the active unit
failover exec mate # Runs on the peer unit
failover exec standby # Runs on the standby unit

 

If you want to disable monitoring of a specific interface:

no monitor-interface interface_name

This configuration gives you a production-ready Active/Standby ASA deployment, with options for high availability, secure failover links, and smooth administrative control.

 

Active vs. Standby vs. Primary vs. Secondary

• Active: The ASA currently handling traffic. All configurations are pushed from the active device.
• Standby: The backup device, which mirrors all configuration but doesn’t forward traffic unless a failover event occurs.
• Primary and Secondary refer to the priority in becoming the active device. These roles don’t affect traffic directly but influence the election outcome during boot or failover.

 

Failover Link Configuration – ASA1 and ASA2

Start by ensuring that both ASAs are on the same VLAN for the failover interface. Below is an example where interface g0/2 is used for the failover LAN link:

ASA1 (Primary):

interface g0/2
no shut

failover lan interface Fail g0/2
failover interface ip Fail 10.100.100.1 255.255.255.0 standby 10.100.100.2
failover lan unit primary
failover key cisco123
failover

ASA2 (Secondary):

interface g0/2
no shut

failover lan interface Fail g0/2
failover interface ip Fail 10.100.100.1 255.255.255.0 standby 10.100.100.2
failover lan unit secondary
failover key cisco123
failover

 

Interface Configuration

Assign IP addresses with standby values on all interfaces. For example:

interface g0/0
ip address 192.1.20.10 255.255.255.0 standby 192.1.20.11

interface g0/1
ip address 10.11.11.10 255.255.255.0 standby 10.11.11.11

 

Stateful Failover (Optional)

You can designate a separate interface for stateful failover, or reuse the failover interface.

failover link SF g0/2
failover interface ip SF 10.200.200.1 255.255.255.0 standby 10.200.200.2

 

Inside, Outside, and Secondary Inside Interface Setup (Example for ASA1)

interface g0/0
nameif inside
ip address 192.168.10.1 255.255.255.0 standby 192.168.10.2
no shut

interface g0/3
nameif inside2
security-level 100
ip address 192.168.20.1 255.255.255.0 standby 192.168.20.2
no shut

interface g0/2
nameif outside
ip address 101.1.1.100 255.255.255.0 standby 101.1.1.101
no shut

 

PAT and ACLs

Configure dynamic NAT with PAT and basic ACLs for ICMP testing:

nat (inside,outside) source dynamic any pat-pool interface
nat (inside2,outside) source dynamic any pat-pool interface

access-list out permit icmp any 192.168.10.0 255.255.255.0
access-list out permit icmp any 192.168.20.0 255.255.255.0
access-group out in interface outside

Basic VPN Configuration

crypto ikev1 policy 1
authentication pre-share
encryption 3des
hash sha
group 2
exit

crypto ipsec ikev1 transform-set t-set esp-3des esp-sha-hmac
crypto dynamic-map d-map 10 set ikev1 transform-set t-set
crypto dynamic-map d-map 10 set reverse-route
crypto map test 10 ipsec-isakmp dynamic d-map
crypto map test interface outside

crypto ikev1 enable outside

ip local pool admin 192.168.100.100-192.168.100.254

tunnel-group admin type ipsec-ra
tunnel-group admin general-attributes
address-pool admin
tunnel-group admin ipsec-attributes
ikev1 pre-shared-key admin

username admin password cisco123

 

NAT Exemptions for VPN

object network 192.168.10.0
subnet 192.168.10.0 255.255.255.0

object network 192.168.20.0
subnet 192.168.20.0 255.255.255.0

object network 192.168.100.0
subnet 192.168.100.0 255.255.255.0

nat (inside,outside) 1 source static 192.168.10.0 192.168.10.0 destination static 192.168.100.0 192.168.100.0
nat (inside2,outside) 2 source static 192.168.20.0 192.168.20.0 destination static 192.168.100.0 192.168.100.0

 

Advanced Failover Configuration

For ASA1 (primary):

interface g0/1
no shut
exit
failover lan unit primary
failover lan interface folan g0/1
failover interface ip folan 192.168.111.1 255.255.255.0 standby 192.168.111.2
failover

failover link folan
failover replication http
failover key key
failover polltime msec 200 holdtime msec 800

 

And on ASA2 (secondary):

interface g0/1
no shut
exit
failover lan unit secondary
failover lan interface folan g0/1
failover interface ip folan 192.168.111.1 255.255.255.0 standby 192.168.111.2
failover

 

Useful Commands

show failover
show run failover
no failover active

This full walkthrough sets you up with a reliable, scalable, and feature-rich Active/Standby ASA deployment—with optional stateful replication and VPN readiness.

 

Active-Active Failover Overview

Active-Active Failover is supported only in multiple context mode. In this design, traffic is distributed across two ASA units based on contexts, which are essentially virtual firewalls operating independently. Unlike Active/Standby where only one ASA handles all traffic, Active-Active allows one context to be active on ASA1 and another on ASA2—offering better resource utilization and scalability.

Key requirements:

• Must enable multi-context mode (mode multiple)
• Each context must be mapped to a failover group
• Only one context per failover group can be active on a given ASA

 

Active-Active Step-by-Step Configuration

1. Physical-to-Logical Interface Mapping

Start in the system context and define subinterfaces with VLAN tagging:

interface g0/0
no shut
interface g0/1
no shut
interface g0/1.1
vlan 20
interface g0/1.2
vlan 30

 

Create the contexts and map interfaces:

context SALES
allocate-interface g0/0
allocate-interface g0/1.1
config-url flash:SALES.cfg

context FINANCE
allocate-interface g0/0
allocate-interface g0/1.2
config-url flash:FIN.cfg

Repeat the same subinterface and context configuration on the second ASA.

 

2. System Context Failover Setup

On ASA1:

interface g0/2
no shut
failover lan interface Fail g0/2
failover interface ip Fail 10.100.100.1 255.255.255.0 standby 10.100.100.2
failover lan unit primary
failover key cisco123

failover group 1
preempt
primary

failover group 2
preempt
secondary

context SALES
join-failover-group 1

context FINANCE
join-failover-group 2

failover link Fail g0/2
failover

 

On ASA2:

interface g0/2
no shut
failover lan interface Fail g0/2
failover interface ip Fail 10.100.100.1 255.255.255.0 standby 10.100.100.2
failover lan unit secondary
failover key cisco123

failover group 1
preempt
secondary

failover group 2
preempt
primary

context SALES
join-failover-group 1

context FINANCE
join-failover-group 2

failover link Fail g0/2
failover

 

Interface Configuration Inside Each Context

Switch into the context configuration mode to define IPs and security zones:

changeto context SALES
interface g1/1
ip address x.x.x.x mask standby x.x.x.x
nameif inside
security-level 100
no shut

interface g1/5
ip address x.x.x.x mask standby x.x.x.x
nameif outside
security-level 0
no shut

changeto context FINANCE
interface g1/1
ip address x.x.x.x mask standby x.x.x.x
nameif inside
security-level 100
no shut

interface g1/6
ip address x.x.x.x mask standby x.x.x.x
nameif outside
security-level 0
no shut

 

NAT and Stateful Options (Optional)

Enable NAT inside the context if required:

nat (inside,outside) source dynamic any pat-pool interface

 

Then return to the system context and configure stateful failover (optional but recommended):

changeto context system
interface g1/3
no shut
failover lan unit primary
failover lan interface nameif g1/3
failover interface ip nameif x.x.x.x mask standby x.x.x.x
failover

failover link nameif
failover key key
failover polltime msec 200 holdtime msec 800

Mirror the configuration on the secondary ASA, adjusting the unit role.

 

IPv6 Support

Active-Standby and Active-Active failover work the same way for IPv6. The only difference is using IPv6 addressing in place of IPv4 on all relevant interfaces and configuration blocks.