Upgrade Cisco ASA software

Cisco ASA now days can run three generations of code, depending on the hardware platform and memory installed. These are 7.x, 8.x and 9.x. Not all ASAs can run any version of code. For example, “Cisco ASA 1000V cloud firewall” can only run 8.7 version. The ASASM (“ASA Service Module”) can only run 8.5 or 9.x. The new versions of ASA appliances, called “The ASA Next Generation Firewall”, the ones with an “X” in its name run only 8.6 or 9.x, except for the 5585-X which van run older code, and the “old guys”, 55xx can run 7.x,  8.0, 8.1, 8.2, 8.3, 8.4 and 9.x, but cannot run 8.5, 8.6 or 8.7. We have to know this compatibilities, because trying to upgrade 5520 from 8.2 to 8.7 would be a horrible idea. Here is the matrix from Cisco.com that can help us determine which version can be run on which platform:

ASA OS

ASDM

ASA Model:

 

ASA 5505

ASA 5510, 5520, 5540

ASA 5550

ASA 5580

ASA 5512-X, 5515-X, 5525-X, 5545-X, 5555-X

ASA 5585-X

ASASM

ASA 1000V

ASA 7.0

ASDM 5.0.Recommended: 5.0(8).

No

YES

No

No

No

No

No

No

ASA 7.1(1)

ASDM 5.1.Recommended: 5.1(2).

No

YES

No

No

No

No

No

No

ASA 7.1(2)

ASDM 5.1(2)

No

YES

YES

No

No

No

No

No

ASA 7.2

ASDM 5.2.Recommended: 5.2(4).

YES

YES

YES

No

No

No

No

No

ASA 8.0(2)

ASDM 6.0(2) and later.Recommended: 7.1(3).

YES

YES

YES

No

No

No

No

No

ASA 8.0(3)

ASDM 6.0(3) and later.Recommended: 7.1(3).

YES

YES

YES

No

No

No

No

No

ASA 8.0(4)

ASDM 6.1(3) and later.Recommended: 7.1(3).

YES

YES

YES

No

No

No

No

No

ASA 8.0(5)

ASDM 6.2(3) and later.Recommended: 7.1(3).

YES

YES

YES

No

No

No

No

No

ASA 8.1(1)

ASDM 6.1(1) and later.Recommended: 7.1(3).

No

No

No

YES

No

No

No

No

ASA 8.1(2)

ASDM 6.1(5) and later.Recommended: 7.1(3).

No

No

No

YES

No

No

No

No

ASA 8.2(1)

ASDM 6.2(1) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

No

No

No

ASA 8.2(2)

ASDM 6.2(5) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

No

No

No

ASA 8.2(3)

ASDM 6.3(4) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

YES

No

No

ASA 8.2(4)

ASDM 6.3(5) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

YES

No

No

ASA 8.2(5)

ASDM 6.4(3) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

YES

No

No

ASA 8.3(1)

ASDM 6.3(1) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

No

No

No

ASA 8.3(2)

ASDM 6.3(2) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

No

No

No

ASA 8.4(1)

ASDM 6.4(1) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

YES

No

No

ASA 8.4(2)

ASDM 6.4(5) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

YES

No

No

ASA 8.4(3)

ASDM 6.4(7) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

YES

No

No

ASA 8.4(4.1)1

ASDM 6.4(9) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

YES

No

No

ASA 8.4(5)

ASDM 7.0(2) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

YES

No

No

ASA 8.4(6)

ASDM 7.1(2.102) and later.Recommended: 7.1(3).

YES

YES

YES

YES

No

YES

No

No

ASA 8.5(1)

ASDM 6.5(1).

No

No

No

No

No

No

YES

No

ASA 8.6(1)

ASDM 6.6(1).

No

No

No

No

YES

No

No

No

ASA 8.7(1.1)2

ASDM 6.7(1).

No

No

No

No

No

No

No

YES

ASA 9.0(1)

ASDM 7.0(1) and later.Recommended: 7.1(3).

YES

YES

YES

YES

YES

YES

YES

No

ASA 9.0(2)

ASDM 7.1(2) and later.Recommended: 7.1(3).

YES

YES

YES

YES

YES

YES

YES

No

ASA 9.0(3)

ASDM 7.1(3).

YES

YES

YES

YES

YES

YES

YES

No

ASA 9.1(1)

ASDM 7.1(1) and later.Recommended: 7.1(3).

YES

YES

YES

YES

YES

YES

YES

No

ASA 9.1(2)

ASDM 7.1(3).

YES

YES

YES

YES

YES

YES

YES

No

One thing I would like to point here out: the old platforms (5505, 5510, 5520, 5540 and 5550), contrary to what some Cisco (???) engineers said to me, *can* run the new code, as stated in the table above. Of course, with the appropriate memory upgrade.

There is another thing we must take into consideration when planning fro an upgrade – memory requirements.

ASA Model

Internal Flash Memory (Default Shipping)1 ,2

DRAM (Default Shipping)

Before Feb. 2010

After Feb. 2010 (Required for 8.3 and Higher)

5505

128 MB

256 MB

512 MB3

5510

256 MB

256 MB

1 GB

5520

256 MB

512 MB

2 GB

5540

256 MB

1 GB

2 GB

5550

256 MB

4 GB

4GB

5512-X

4 GB

N/A

4 GB

5515-X

8 GB

N/A

8 GB

5525-X

8 GB

N/A

8 GB

5545-X

8 GB

N/A

12 GB

5555-X

8 GB

N/A

16 GB

5580-20

1 GB

8 GB

8GB

5580-40

1 GB

12 GB

12 GB

5585-X with SSP-10

2 GB

N/A

6 GB

5585-X with SSP-20

2 GB

N/A

12 GB

5585-X with SSP-40

2 GB

N/A

12 GB

5585-X with SSP-60

2 GB

N/A

24 GB

ASASM

8 GB

N/A

24 GB

So, for example, if we bought the ASA5520 before February 2010, we first need a memory upgrade and then we can go for an upgrade.

Now one more important thing about upgrading. There are so called upgrade paths we must follow. We should take this seriously! What I mean by this is that if you go for an upgrade from 7.2 to 9.1 it *will* work. I mean the ASA will boot the new code, but the new code may not parse the old configuration properly and some functions may not work (or should I say will not work). I had one small configuration on the 5510, with just a few routes, ACLs with no NAT, and I did an upgrade from 7.0 to 9.1 without breaking anything. Of course this was my lab setup and again – follow the upgrade path!

What is this upgrade path? This is an array of code versions that must be applied in specific order from the current to the version we want to go to. For example, the version 8.3 is my favorite, because of the new NAT syntax and changes in how we code our ACLs. If we would like to upgrade to 8.3, we must be at version 8.2. Or should I say Cisco only supports upgrading to 8.3 from 8.2.

Now reaching 8.2 can also be tricky! Cisco names ASA versions this way: asaXYZ.bin. The “X” is the major release number, the “Y” is minor  number and the “Z” is the maintenance release number. Some rules apply when constructing the upgrade path:

  • We can upgrade from any version to any other version within the same major and minor version. For example we can go from 8.0(2) directly to 8.0(5)
  • To upgrade from one minor release to another, we cannot skip a minor release number. For instance, we cannot upgrade from 7.0 to 7.2 directly. We should go from 7.0 to 7.1 and then to 7.2
  • Upgrading from one major release to the next is possible only from the last *minor* release. For example, to upgrade from 7.x to 8.x, we must be at 7.2 which is the last minor version within the 7.x train. We cannot upgrade from 7.1 to 8.x
  • To upgrade to 8.3, we must be at 8.2
  • To upgrade to 9.x, we must be running a 8.3 or 8.4. That is if version 8.4 is available for our platform. For ASA55YY-X series, there is no 8.4, so we must be at 8.6

This can be tricky and I strongly recommend consulting the documentation on your specific versions to select a proper upgrade path.

We have now a general idea on how to do an upgrade. The most difficult task is actually going through the tables from above and figure out which version and which path we should take. The upgrade process itself is, believe it or not, very straight forward process. We will break it into two most common scenarios:

  1. Upgrading a standalone appliance
  2. Upgrading an Active/Standby failover pair

Like I said, I’m a big fan of 8.3, so here I will show how to upgrade to 8.3. I also chose this version because it brings new ways of doing NAT and ACLs and upgrading to this version does some significant configuration changes during migration.

TIP: Before installing any new version of code, after you download the code, verify its MD5/SHA1 shecksum!

1. Upgrading a standalone appliance

Let’s assume that our box is running 8.2 code, which it should before upgrading to 8.3. My configuration has some ACLs and some NAT statements, among other things. Some ACLs are actually being used, and NAT statements are not. They are only here to see how the migration process converts the configuration. Some ACLs are also placed only to show the new ACL model in the 8.3 code. After we upgrade to 8.3, we will then go for the 9.1, which is the latest version at the time this blog was written.

First we make sure we can use the 8.3, by consulting the tables from above and verify our memory requirements are fulfilled:

atest1#
atest1# show ver | i RAM
Hardware:   ASA5510, 1024 MB RAM, CPU Pentium 4 Celeron 1599 MHz
atest1#

We can see that 8.3 is supported on ASA5510 from the table one, and that we have enough RAM from the table two.

Here is our current running configuration:

atest1#
atest1# wr t
: Saved
:
ASA Version 8.2(5)
!
hostname atest1
enable password someencryptedpassword encrypted
passwd somepasswordalsoencrypted encrypted
names
!
interface Ethernet0/0
nameif outside
security-level 0
ip address 1.1.1.254 255.255.255.0
!
interface Ethernet0/1
nameif inside
security-level 100
ip address 10.1.26.111 255.255.255.0
!
interface Ethernet0/2
nameif VMWARE
security-level 75
ip address 10.1.110.100 255.255.255.0
!
interface Ethernet0/3
shutdown
no nameif
no security-level
no ip address
!
interface Management0/0
shutdown
no nameif
no security-level
no ip address
!
boot system disk0:/asa825.bin
ftp mode passive
object-group network ESXi-HOSTS
network-object host 10.0.0.51
network-object host 10.0.0.52
access-list VMWARE_IN remark vCenter Access
access-list VMWARE_IN extended permit udp host 10.1.110.3 object-group ESXi-HOSTS eq 902
access-list VMWARE_IN extended permit tcp host 10.1.110.3 object-group ESXi-HOSTS eq 902
access-list VMWARE_IN extended permit tcp host 10.1.110.3 object-group ESXi-HOSTS eq https
access-list OUTSIDE_IN extended permit tcp any 10.1.110.0 255.255.255.0 eq https
access-list OUTSIDE_IN extended deny ip any any log
pager lines 24
logging enable
logging buffered informational
mtu inside 1500
mtu VMWARE 1500
mtu outside 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-713.bin
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 192.168.0.0 255.255.255.0
static (VMWARE,outside) 1.1.1.0 10.1.110.0 netmask 255.255.255.0
access-group VMWARE_IN in interface VMWARE
route inside 10.0.0.0 255.255.255.0 10.1.26.100 1
route inside 10.1.0.0 255.255.255.0 10.1.26.100 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect icmp
inspect ip-options
!
service-policy global_policy global
prompt hostname context
no call-home reporting anonymous
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome@cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:bdd4797c9a864023ecb985b0576632af
: end
[OK]
atest1#

Although the migration process will backup our current config, I like to do that myself. I like to copy the config to both local disk and the remote location. For a local disk:

atest1#
atest1# wr
Building configuration…
Cryptochecksum: bdd4797c 9a864023 ecb985b0 576632af

3714 bytes copied in 3.350 secs (1238 bytes/sec)
[OK]
atest1#
atest1# copy run disk0:/running-config.backup

Source filename [running-config]?

Destination filename [running-config.backup]?
Cryptochecksum: bdd4797c 9a864023 ecb985b0 576632af

3714 bytes copied in 3.360 secs (1238 bytes/sec)
atest1#

First we saved our config to a startup config and then made a copy.

Now we need to change the boot section of the configuration. Currently, our ASA boots the 8.2(5) of code:

atest1#
atest1# show run boot
boot system disk0:/asa825.bin
atest1#

Now we transfer the new code from the network to the local disk:

atest1#
atest1# copy tftp: disk0:

Address or name of remote host []? 10.1.0.5

Source filename []? asa831.bin

Destination filename [asa831.bin]? asa831.bin

Accessing tftp://10.1.0.5/asa831.bin…!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Writing file disk0:asa831.bin…
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
15943680 bytes copied in 16.80 secs (996480 bytes/sec)
atest1#
atest1#

Now we need to alter the boot sequence to boot the new code:

atest1#
atest1# conf t
atest1(config)# clear config boot
atest1(config)#
atest1(config)# boot system disk0:/asa831.bin
atest1(config)#
atest1(config)# exit
atest1#
atest1# wr
Building configuration…
Cryptochecksum: 43e5a33b 804701e5 ab1bf9d4 763ae24b

3714 bytes copied in 3.370 secs (1238 bytes/sec)
[OK]
atest1#
atest1# show run boot
boot system disk0:/asa831.bin
atest1#

Finally, we reload our appliance and wait for the upgrade process to complete. After the process is done, we should pay attention to the output:

!
REAL IP MIGRATION: WARNING
In this version access-lists used in ‘access-group’, ‘class-map’,
‘dynamic-filter classify-list’, ‘aaa match’ will be migrated from
using IP address/ports as seen on interface, to their real values.
If an access-list used by these features is shared with per-user ACL
then the original access-list has to be recreated.
INFO: Note that identical IP addresses or overlapping IP ranges on
different interfaces are not detectable by automated Real IP migration.
If your deployment contains such scenarios, please verify your migrated
configuration is appropriate for those overlapping addresses/ranges.
Please also refer to the ASA 8.3 migration guide for a complete
explanation of the automated migration process.

INFO: MIGRATION – Saving the startup configuration to file

INFO: MIGRATION – Startup configuration saved to file ‘flash:8_2_5_0_startup_cfg.sav’
*** Output from config line 4, “ASA Version 8.2(5) ”

NAT migration logs:
nat (inside) 1 192.168.0.0 255.255.255.0

INFO: NAT migration completed.
Real IP migration logs:
No ACL was changed as part of Real-ip migration

INFO: MIGRATION – Saving the startup errors to file ‘flash:upgrade_startup_errors_201308160855.log’

We can see that the two files are created on the local disk:

  • 8_2_5_0_startup_cfg.sav

This file contains the old configuration, in the case something went wrong and we would like to go back.

  • upgrade_startup_errors_201308160855.log

This one contains migration error messages. These files can be viewed with the “more” command:

more disk0:/upgrade_startup_errors_201308160855.log

This will basically give us the output from the above. This file should be checked in order to see if the migration was successful or not.

IMPORTANT: the running config is NOT saved to the startup config after migration. So me must to do “write memory”, otherwise if the box gets reloaded, the process would happen again.

Here is the migrated config:

atest1#
atest1# wr t
: Saved
:
ASA Version 8.3(1)
!
hostname atest1
enable password someencryptedpassword encrypted
passwd somepasswordalsoencrypted encrypted
names
!
interface Ethernet0/0
nameif outside
security-level 0
ip address 1.1.1.254 255.255.255.0
!
interface Ethernet0/1
nameif inside
security-level 100
ip address 10.1.26.111 255.255.255.0
!
interface Ethernet0/2
nameif VMWARE
security-level 75
ip address 10.1.110.100 255.255.255.0
!
interface Ethernet0/3
shutdown
no nameif
no security-level
no ip address
!
interface Management0/0
shutdown
no nameif
no security-level
no ip address
!
boot system disk0:/asa831.bin
ftp mode passive
object network obj-192.168.0.0
subnet 192.168.0.0 255.255.255.0
object network obj-10.1.110.0
subnet 10.1.110.0 255.255.255.0
object-group network ESXi-HOSTS
network-object host 10.0.0.51
network-object host 10.0.0.52
access-list VMWARE_IN remark vCenter Access
access-list VMWARE_IN extended permit udp host 10.1.110.3 object-group ESXi-HOSTS eq 902
access-list VMWARE_IN extended permit tcp host 10.1.110.3 object-group ESXi-HOSTS eq 902
access-list VMWARE_IN extended permit tcp host 10.1.110.3 object-group ESXi-HOSTS eq https
access-list OUTSIDE_IN extended permit tcp any 10.1.110.0 255.255.255.0 eq https
access-list OUTSIDE_IN extended deny ip any any log
pager lines 24
logging enable
logging buffered informational
mtu outside 1500
mtu inside 1500
mtu VMWARE 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-713.bin
no asdm history enable
arp timeout 14400
!
object network obj-192.168.0.0
nat (inside,outside) dynamic interface
object network obj-10.1.110.0
nat (VMWARE,outside) static 1.1.1.0
access-group VMWARE_IN in interface VMWARE
route inside 10.0.0.0 255.255.255.0 10.1.26.100 1
route inside 10.1.0.0 255.255.255.0 10.1.26.100 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect icmp
inspect ip-options
!
service-policy global_policy global
prompt hostname context
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome@cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:527c19dc36bafc1da5c12066d871bd0b
: end
[OK]
atest1#

Let’s see some differences among old and new configs, regarding the NAT:

global (outside) 1 interface
nat (inside) 1 192.168.0.0 255.255.255.0
static (VMWARE,outside) 1.1.1.0 10.1.110.0 netmask 255.255.255.0

object network obj-192.168.0.0
nat (inside,outside) dynamic interface
object network obj-10.1.110.0
nat (VMWARE,outside) static 1.1.1.0

So we see major changes with the NAT configuration in post 8.2 code.

One final thought regarding the upgrade to 8.3 is about the “NAT Control”. This feature is no longer supported, and if present in the old configuration, the migration procedure will generate many “nat” statements to compensate for “nat-control” statement. Depending on the number of interfaces, there could be *many* of these statements.

2.Upgrading an Active/Standby failover pair

Before we go to the upgrade of the HA pair, let me show you one cool feature. In order to show you the upgrade of the failover pair, I need to go back to 8.2 version on this appliance and make a failover cluster with the other one, also running the 8.2 code. How do I go back to the 8.2 code? What is the opposite of the upgrade process? The downgrade process, of course 🙂

atest1#
atest1# downgrade disk0:/asa825.bin disk0:/8_2_5_0_startup_cfg.sav
The device will reload and downgrade to the specified image.
Press [Y]es or <newline> to confirm (any other key will abort):
INFO: Boot parameters cleared
INFO: Boot system configured to be disk0:/asa825.bin
Cryptochecksum: db229929 5141cb68 e3646d31 8241ea8d

3785 bytes copied in 3.450 secs (1261 bytes/sec)
INFO: Saving disk0:/8_2_5_0_startup_cfg.sav to startup-config

We can see that the downgrade process uses the backup configuration, saves it to startup config, and boots the old code. Please make a note that the “downgrade” process can have an optional argument “activation-key”. This has to be considered if some features needs to be turned off, that are not supported in the old code. More on this some other time, I just want you to know about this.

Now both appliances have the same code and we make them a failover cluster, according to this blog post. After this, the upgrade process is fairly simple. And it won’t break any existing sessions, as the previous upgrade example would, because of the reboot.

First we make sure that both appliances runs the same and required code:

atest1/pri/act#
atest1/pri/act# show ver | i Version
Cisco Adaptive Security Appliance Software Version 8.2(5)
Device Manager Version 7.1(3)
atest1/pri/act#

Then we make sure both boxes have required image to upgrade to:

atest1/pri/act#
atest1/pri/act# dir disk0:/asa831.bin

Directory of disk0:/asa831.bin

137    -rwx  15943680    08:48:20 Aug 16 2013  asa831.bin

255426560 bytes total (71532544 bytes free)
atest1/pri/act#

Now we change the boot section:

atest1/pri/act#
atest1/pri/act# show run boot
boot system disk0:/asa825.bin
atest1/pri/act#
atest1/pri/act# conf t
atest1/pri/act(config)# clear config boot
atest1/pri/act(config)#
atest1/pri/act(config)# boot system disk0:/asa831.bin
atest1/pri/act(config)#
atest1/pri/act(config)# exit
atest1/pri/act#
atest1/pri/act# show run boot
boot system disk0:/asa831.bin
atest1/pri/act#

We must save the config:

atest1/pri/act#
atest1/pri/act# wr
Building configuration…
Cryptochecksum: 7cc155ae a74a25a9 e3bf7f84 f335c8cc

4077 bytes copied in 3.380 secs (1359 bytes/sec)
[OK]
atest1/pri/act#

Now we reload the *standby* unit from the active unit and wait for the upgrade process on the standby unit to complete:

atest1/pri/act#
atest1/pri/act# failover reload-standby
atest1/pri/act#

After the process completes, on the standby unit we can see this warning:

************WARNING****WARNING****WARNING********************************
Mate version 8.2(5) is not identical with ours 8.3(1)
************WARNING****WARNING****WARNING*********************************

Which is perfectly ok at this stage of migration. We should verify log file generated by the process (aka flash:upgrade_startup_errors_201308161228.log). From the active unit, we verify the failover status:

atest1/pri/act#
atest1/pri/act# show failover
Failover On
Failover unit Primary
Failover LAN Interface: FAILOVER Management0/0 (up)
Unit Poll frequency 1 seconds, holdtime 3 seconds
Interface Poll frequency 1 seconds, holdtime 5 seconds
Interface Policy 1
Monitored Interfaces 2 of 110 maximum
Version: Ours 8.2(5), Mate 8.3(1)
Last Failover at: 11:26:13 UTC Aug 16 2013
This host: Primary – Active
Active time: 4107 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.2(5)) status (Up Sys)
Interface outside (1.1.1.254): No Link (Not-Monitored)
Interface inside (10.1.26.111): Normal
Interface VMWARE (10.1.110.100): Normal
slot 1: empty
Other host: Secondary – Standby Ready
Active time: 0 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.3(1)) status (Up Sys)
Interface outside (1.1.1.253): Normal (Not-Monitored)
Interface inside (10.1.26.112): Normal
Interface VMWARE (10.1.110.101): Normal
slot 1: empty

If the standby unit is ready, we can make it an active unit now. Then we reload the remaining unit to boot the new code:

atest1/pri/act#
atest1/pri/act# no failover active
atest1/pri/act#
Switching to Standby

atest1/pri/stby#
atest1/pri/stby# reload
Proceed with reload? [confirm]
atest1/pri/stby#

***
*** — START GRACEFUL SHUTDOWN —
Shutting down isakmp
Shutting down File system

***
*** — SHUTDOWN NOW —

Finally, after the upgrade process completes, we may make this appliance an active one again:

atest1/pri/stby#
atest1/pri/stby# failover active

Switching to Active
atest1/pri/act#

Again, very important, we must save the running config, otherwise we will go into an upgrade loop:

atest1/pri/act#
atest1/pri/act# wr
Building configuration…
Cryptochecksum: e39e070b ad8c96af 781aa92f 143d19c6

4169 bytes copied in 3.420 secs (1389 bytes/sec)
[OK]
atest1/pri/act#

And that’s it! After going through either scenario, we are running the 8.3 code, which is a requirement for going to a 9.x version, if we wanted. The steps would be exactly the same as described above. Upgrading an Active/Active failover pair is a little bit trickier but similar and not so tough.

Thanks for reading!

Advertisements
This entry was posted in ASA, Cisco, Security and tagged , , . Bookmark the permalink.

10 Responses to Upgrade Cisco ASA software

  1. Butch says:

    Since they maintain all three generations and all the different major and minor versions, what is the logical requirement from a security compliance perspective, rather than a feature perspective? In other words, if I have 8.0(3), I am safe (from a compliance/audit perspective) I’d I upgrade to 8.0(5), since Cisco would release any critical security fixes (presumably) via an 8.0(6) release, correct? Could anyone say we’re not operating safely on 8.0(5) just because we haven’t upgraded to 8.2, 8.4, 9.0, or even 9.1? Windows XP is still safe (for a few more weeks), even if we didn’t upgrade to Vista, 7, or 8…

    • Sasa says:

      Well, it seems obvious: if we don’t need the latest features – we don’t run the latest code 🙂 If we are still compliant with the desired standard, that is. There is another driver here: Cisco (as well as all other vendors) stop supporting releases that are good for us. So we have to go up. And hoping to stay compliant. I guess this pushes the industry forward. I liked 7.2 version of code, but cannot run it any more 😦

  2. Butch says:

    That’s supposed to be “I’d be safe IF I upgrade to 8.0(5) from 8.0(3)…

  3. Great post. Just one question/observation: If I want to start from scratch and configure my ASA from the default config, then I can upgrade from 7.2 to 9.x, as long as the memory is upgraded, since there will be no running config to worry about, right? I’m in the process of placing a new asa 5505 into service and might as well get the latest features and possibly a little more longevity out of the upgrade.

  4. Pingback: Upgrade Cisco Sourcefire to 6.0 | popravak

  5. Pingback: Länk 2016-06 | I'm Herman and I'm a planet smasher...

  6. viz says:

    im running 8.2 right now and need to upgrade to 8.4(5) followed by 9.1.Is is just the s/ware i need to upgrade or license/certificate will need to be changed as well ?

  7. Pingback: Upgrade Cisco Sourcefire to 6.2.0 | popravak

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s