Upgrading the code on an ASA pair in high availability mode is relatively straight forward but still a bit of a chore. Here is the process I follow.
First things first read the release notes for your new code version! You want to double check the important notes section for any new “gotchas” that might come up in the code and also double check the upgrade path. In my case I’m upgrading to the new interim 9.12 code so I’d check the chart:
Because I’m running version 9.8(x) code currently I can see that I dont have to do an interim upgrade first and can jump straight to the new 9.12(x) code.
The next thing to check is the version of ASDM that you are running. Make sure that it too is compatible with the new code version you’ll be installing. ASDM should be backwards compatible. If you Google “ASA Compatibility Matrix” you will find yet another chart that shows you what versions of ASDM will work with what versions of ASA code.
Next step is to download the ASA and ASDM code and upload it to your device. I usually do this using TFTP. MAKE SURE YOU DO THIS FOR BOTH DEVICES! If you’re running an active/standby setup.
One quick note on the TFTP transfer, if you’re moving quick and you just run a copy tftp flash command, be sure to actually specify the destination filename, dont leave it blank that will give you headaches down the line.
Now before you go to much further its wise to make a backup of your current config. Open ASDM and login to your device. Go to Tools, Backup and make a full backup of your ASA, just in case things go south you can quickly revert back to this to get back up and running.
Now that you have a backup saved and the new code and ASDM versions uploaded its time to get into the nitty gritty.
On your PRIMARY/ACTIVE firewall run these commands:ASA1# show running-config boot systemboot system disk0:/asaOLD-k8.binASA1# configure terminalASA1(config)# boot system disk0:/asaNEW-k8.bin
ASA1(config)# no boot system disk0:/asaOLD-k8.binASA1# show running-config boot system
boot system disk0:/asaNEW-k8.bin
With those commands you’ve set the new code version as the boot image and removed the old code version. Note that you can as a precaution do another boot system disk0 command with the old code version and it will make it the secondary boot image should the first ever fail to load. These next commands set the new ASDM version for the device.ASA1(config)# asdm image disk0:/asdm-NEW.binASA1(config)# show running-config asdm
asdm image disk0:/asdm-NEW.binASA1(config)# wr mem
Now you’ve made a backup of your original config, uploaded the new code and ASDM and set the new versions of code to run on your device. Now comes the scary part: failing over your devices and having the code install then reboot the ASA.
This command will be your best friend during this process:show failover
That command will help guide you the rest of the way.
On your PRIMARY/ACTIVE ASA run a show failover command. Make sure that you are on Primary/Active. If you are run the failover reload-standby command. Your heart may drop as you get alarm messages or your SSH connection drops or a few pings to the outside fail. Dont worry, stay calm, and be patient. You should eventually see a message like this:
Give the replication a bit of time. Try hitting enter after a bit to see if your CLI is active again. It doesnt always automatically take you back to an active session. Once you have an active session again enter in the show failover command again.
Now you should be on the Primary-Active ASA. But sometimes during the upgrade process as part of the reload you’ll see that you’re on the Secondary-Active. If this happens dont panic! Run your show failover command and look carefully.
In this case I can see that I’m on secondary – active and that the secondary is running the new code version but that the primary -standby is not. Keep in mind that Primary/Secondary denote physical ASAs, the Active/Standby status can be on either device.
This doesnt happen all of the time but it does happen so make sure you pay attention to what device you’re on. Because we can see that we’re Secondary – Active and that we’re running the new code we know that we need to now upgrade the Primary – Standby. Again the standby status there is key. So now we’ll run the failover reload-standby command again to force the standby to reload and install the new code.
BE PATIENT! This can take a bit, you may drop a ping or two to the outside dont worry give it time. You may see another status message pop up that says Beginning configuration replication: Sending to mate. Thats a good sign let it run for a bit then run your show failover command again to check on the status.
Check and make sure that both units are running the new code. If they are congratulations you’re almost done! The upgrade went as it should and you can relax. The only thing left to do at this point is to make the Primary active again. To do so run the failover active command on the Primary – Standby ASA.
After all of that make sure you can login to devices via SSH still, check that you can get in via ASDM still, check that site to sites came back online and you should be set!
For far better instructions then I can write check out this site:
https://www.petenetlive.com/KB/Article/0000733
My instructions here are really only useful if the failover goes wonky. And really only as an illustration to double check your failover status and react accordingly.