loader-logo
Packet6 is now a Juniper Networks partner!

Cisco ASA Zero Downtime Upgrade

Cisco ASA 5512XIn this post I will describe how I upgraded the software of my Active/Standby Failover Cisco ASA 5512X from 8.6 to 9.1. Additionally, I will upgrade the ASDM to the latest version.

When upgrading the software of your Cisco ASA it’s important to read the release notes beforehand. Go through each major and minor release version. According to Cisco, you should upgrade to the latest minor release version before upgrading to the next major version.

This is important if you want to maintain a zero downtime upgrade.

A minor release upgrade is, for example, going from 8.3 to 8.4. Which means zero downtime is not supported from 8.3 to 8.6.

A major release upgrade is going from the base version to the next release. For example, 8.6 to 9.0. This would be supported for zero downtime. It would NOT be supported if you were to go from 8.6 to 9.1.

In my process, I went from 8.6 to 9.0 and then from 9.0 to 9.1.

Before we do any sort of upgrades on the ASA, we need to make a backup. After the backups, we will upload the bin file to the primary ASA and secondary ASA. The same goes for ASDM. After the bin is uploaded, you change the active and standby ASA boot system order. You can have multiple boot systems and the ASA will pick from the top. Then you reboot the ASA and it should be on the latest version.

Detailed Steps

Step 1

Back up your configuration either by TFTP or using command and copy the output:

asa#more system:running-config

Step 2

Copy ASA software to the active unit flash memory.

asa#copy tftp://192.168.100.100/asa901-smp-k8.bin disk0:/asa901-smp-k8.bin

Step 3

Copy the software to the standby unit. Use the same path as the active unit.

asa#failover exec mate copy /noconfirm tftp://192.168.100.100/asa901-smp-k8.bin disk0:/asa901-smp-k8.bin

Step 4

Copy ASDM image to the active ASA unit’s flash memory.

asa#copy tftp://192.168.100.100/asdm-711.bin disk0:/asdm-711.bin

Step 5

Copy ASDM image to the standby ASA unit. Use the same path as the active unit.

asa#failover exec mate copy /noconfirm tftp://192.168.100.100/asdm-711.bin disk0:/asdm-711.bin

Step 6

Enter global configuration mode

asa#conf t

asa(config)#

Step 7

Verify current boot images configured. ASA uses these images in order. To make the ASA boot to the new image, remove the existing entries and enter the image URLs in the order desired.

asa(config)#show running-config boot system

Step 8

Remove any existing boot image.

asa(config)#no boot system disk0:/asa861-smp-k8.bin

Step 9

Set the ASA image to boot. Repeat command for backup images.

asa(config)#boot system disk0:/asa901-smp-k8.bin
asa(config)#boot system disk0:/asa861-smp-k8.bin

Step 10

Set the ASDM image to use. Only one can be configured.

asa(config)#asdm image disk0:/asdm-711.bin

Step 11

Save settings to startup config.

wr mem

Step 12

Reload the standby unit to boot the new image. Wait for the standby to finish loading and use show failover command to verify the standby unit is in Standby Ready state.

asa#failover reload-standby

Step 13

Force the active unit to fail over to the standby unit.

asa#no failover active

Step 14

Reload the former active unit. Log into active unit

asa# reload

After upgrading to the major version, verify both ASAs have the same software version. Then you can begin the process again to upgrade to the next minor release version.

Verification

If all is good you will see the standby ASA running a newer version than the active ASA. The firewall also displays a message about the mismatch.

Running show version will determine if your ASA booted with the latest image.

After reloading both ASAs, run show failover to ensure there is an Active and a Standby.

asa# sh failover
Failover On
Failover unit Primary
Failover LAN Interface: FAILOVER GigabitEthernet0/0 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 5 of 114 maximum
failover replication http
Version: Ours 9.0(1), Mate 9.0(1)
Last Failover at: 14:51:20 PDT Jun 19 2014
This host: Primary - Active
Active time: 266969 (sec)
slot 0: ASA5512 hw/sw rev (1.0/9.0(1)) status (Up Sys)
Interface Inside (192.168.254.254): Normal (Monitored)
Interface DMZ (10.1.254.254): Normal (Monitored)
Interface OutsideTWO (172.16.254.254): Normal (Monitored)
Interface OutsideONE (172.16.253.254): Normal (Monitored)
Interface MGMT (10.10.10.254): Link Down (Monitored)
Other host: Secondary - Standby Ready
Active time: 0 (sec)
slot 0: ASA5512 hw/sw rev (1.0/9.0(1)) status (Up Sys)
Interface Inside (192.168.254.253): Normal (Monitored)
Interface DMZ (10.1.254.253): Normal (Monitored)
Interface OutsideTWO (172.16.254.253): Normal (Monitored)
Interface OutsideONE (172.16.253.253): Normal (Monitored)
Interface MGMT (10.10.10.253): Normal (Monitored)
slot 1: IPS5512 hw/sw rev (N/A/) status (Unresponsive/Up)

There is specific state information that is passed/not passed to the standby ASA. It’s important to know what these are and how they pertain to your environment. Otherwise, schedule a maintenance window outside of normal business hours.

State Information Passed:

  • NAT Table
  • TCP Connection States
  • UDP Connection States
  • ARP Table
  • HTTP Connection States
  • ISAKMP and IPSec SA table
  • SIP signalling sessions

State Information Not Passed:

  • User authentication (uauth) table.
  • Routing tables.
  • State information for Security Service Modules.
  • DHCP server address leases.
Tags:
0 Points


One thought on “Cisco ASA Zero Downtime Upgrade”

  1. John Rumball says:

    Great instructions… followed them last night for an ASA sw upgrade. A couple of comments though… you should preface the instructions with the type of connection method used to manage the ASA’s before following these instructions. For example, I manage my ASA’s inband via the inside interface. In this case, your second reload (of the former active ASA in step 14) would have just reloaded the secondary (now active) ASA, again. Instead, I just re-ran the failover reload-standby command which worked as expected. Just my two cents. 🙂 Thanks again.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.