Configuring & Upgrading ASA HA - Active/Standby

"The What?" - In this post I will cover ASA HA configuration for an Active/Standby deployment & briefly touch on an upgrade approach. Before diving in, if you want to gain a better understanding of ASA HA please see the the following post: Understanding ASA High Availability

Remember that the ASA can run in Active/Standby in single context mode only. For Active/Active the ASA must be running in multiple context mode.

"The Why?" - High availability is often desired for several reasons. A few of the main reasons are to increase reliability & uptime. In an Active/Standby HA pair the secondary ASA is considered a hot standby. Remember that we can have stateless or stateful failover as described in another post.

"The How?" - First I want to declare the difference between Active/Standby & Primary/Secondary. When pairing units, one is configured as the primary and the other unit in the pair is declared the secondary. These never change unless it is manually reconfigured. The Active role is the role taken by the ASA that is actually passing traffic, while the Standby role is the unit awaiting a failure/failover.

Once the "primary" unit is identified/defined the overview of the failover configuration building blocks looks like this:

  • On primary unit:

  • Determine a dedicated interface to be used as failover interface

  • Determine/assign failover interface IP & enable interface

  • Optionally determine if using stateful failover link

  • Determine/assign stateful failover interface IP & enable interface

  • Note you can use the same interface for failover & stateful failover interface

  • Decide if you wish to enable interface monitoring

  • Enable failover

  • On standby unit:

  • Determine a dedicated interface to be used as failover interface

  • Declare unit as secondary

  • Enable failover

Really the only configuration required on the secondary unit is the failover interface. This interface allows the unit to communicate initially with the primary unit. The only differences is the failover lan unit commands between the two.

Once the base configuration is completed, you must enable failover which is noted as the last step above. Doing so will trigger the active unit to send the configuration in run to the standby unit. During synchronization messages will appear on the active unit: 'Beginning configuration replication: Sending to mate'

Later once the HA pair is active, if you ever wish to immediately sync the Active run config to the standby peer you can do so via the following:

#write standby

When initiating this command the ASA (as of version 9.X) will trigger the run config synchronization to the standby peer & you will see the following output:

Building configuration...
INFO: Executing "write standby" will force a complete re-replication of the configuration from the Active unit to the Standby unit.
      This command is not used to save the configuration on the Standby unit.
# Beginning configuration replication: Sending to mate.
End Configuration Replication to mate

Here are a few failover triggers from an Active to the Standby unit:

  • The unit has a hardware failure or a power failure.

  • The unit has a software failure.

  • Too many monitored interfaces fail.

  • You force a failover.

Forcing failover manually:

#failover active		
#no failover active     

The first command forces failover when entered on Standby unit. The second command forces failover when entered on Primary unit.

Monitoring Active/Standby Failover:

#show failover
#show monitor-interface
#show running-config failover

The first command displays failover state information for the unit. The second command displays information on the monitor-interface. The last command displays the failover commands in run config.

Lastly, for the HA config it is important to understand Interface Monitoring & how it affects the failover policy. By default you can monitor up to 250 interfaces. Using this health feature allows the units to poll interfaces to determine if they are active & whether or not a failover should occur.

Disabling/Enabling monitoring on interfaces:

#no monitor-interface <int>
#monitor-interface <int>

Brief example of ASA HA Config:

Primary -

failover lan unit primary
failover lan interface FAILOVER GigabitEthernet0/6
failover link STATEFUL GigabitEthernet0/7
failover interface ip FAILOVER standby
failover interface ip STATEFUL standby

Secondary -

failover lan unit primary
failover lan interface FAILOVER GigabitEthernet0/6
failover link STATEFUL GigabitEthernet0/7
failover interface ip FAILOVER standby
failover interface ip STATEFUL standby

For the last part of this post, I want to share one way to issue IOS upgrades on an ASA HA pair with some helpful tips from my experiences. Note in the example below it requires physical access to the units. Make sure that your version of the ASDM image is compatible with the IOS you are upgrading to. Check Cisco's compatibility matrix.

It is important to know that you can run commands against the standby unit from the CLI of the Active unit via the following syntax:

#failover exec standby <commands>

Another very important note to remember is that IOS, ASDM, & AnyConnect images are not replicated between the two nodes so you it is best to ensure those both units have the images stored.

Below is a way to check the primary & standby units to ensure that the images are on both devices:

Primary: #dir disk0:
Standby: #failvoer exec standby dir disk0:

Next is a manual way of transferring all necessary images to the standby unit. Copy files to USB & insert the USB into the Standby unit. It should appear as disk1:.

Then using the CLI on the Primary unit you can copy the necessary images from the USB stick to disk0 via the following:

#failover exec standby copy /noconfirm disk1:/asa9-12-4-18-smp-k8.bin disk0:/asa9-12-4-18-smp-k8.bin

If you see the following error you need to make sure you have entered /noconfirm

Source filename [asa9-12-4-18-smp-k8.bin]?
?Bad filename
%Error parsing filename (No such device)

Once all images are stored on the Standby unit you can now finish the pre-upgrade prep stages via the Primary unit using ASDM.

  • Tools -> Upgrade Software from Local Computer:

  • Select ASA Image Type:

  • Browse to local file path & upload image

  • You can then set the image as the boot image:

  • Lastly you will be presented with a warning stating that the Unit needs to be reloaded to get upgraded (this can be done once you are ready or scheduled for a later date):

  • If wishing to use ASDM to issue/schedule reload:

  • Determining reload time:

A few verification items:

  • Make sure the run config is saved & replicated to the peer

  • After reboots/upgrades of both units use the following to verify:

  • Show version—This shows the current image with which the ASA is booted.

  • Show bootvar—This shows the priority of the image to be used after reload.

  • Show asdm image—This shows the current ASDM image used by ASA.

In my honest opinion you are better off prepping both units, and reloading the peer to ensure the upgrade is successful without any service interruption. Then manually force failover to the upgraded standby unit & then perform the reload on the unit that was primary.

That about wraps up configuring & upgrading an Cisco ASA HA pair running in Active/Standby. Cheers!


Recent Posts

See All

"The What?" - In this blog I want to share some valuable Digital Network Architecture Center (DNAC) tips & tricks that I have collected that are quite useful when needing to troubleshoot/perform some

In this post I want to cover the ESA Email pipeline. The email pipeline represents how emails are processed through the system from start to finish. The pipeline consists of 3 main phases: Receipt:

I recently started pursuing email security studies. Other posts have mentioned this, and a recent post shared a deeper look at SPF. In this blog I want to cover DKIM & DMARC. Starting with DKIM, it