ASA 8.3 Upgrade - What You Need to Know

Document

Aug 20, 2010 8:53 AM
Aug 20th, 2010

First Things First

First, let's make sure we get one thing clear, upgrading your ASA from 8.2 to 8.3 is NOT a Minor upgrade!  There are significant internal architectural changes around NAT and ACLs in 8.3.  And, more importantly to you (the customer) are the following:

  1. The NAT CLI commands are completely different from all previous version of ASA
  2. The IP addresses used in the ACLs are different (pre-8.3 versions used the global/translated IPs, whereas 8.3 always uses the real IPs (untranslated)
  3. A new concept of host-based objects was introduced, to allow singular hosts to be referenced by their names (previously, we had the name command, but that was more of a macro-substitution in the show running-config output).

Pre-Requsites to Upgrading

Many models of the ASA require a memory upgrade prior to upgrading the ASA to version 8.3.  Brand new ASAs from the factory (manufactured after Feb 2010) come with the upgraded memory.  However, if your ASA was manufactured before February 2010, and is one of the models below requiring a memory upgrade, then you will need to purchase the memory upgrade part prior to installing 8.3 on your ASA.

PlatformLicensePre-8.3 Memory Required8.3 Memory RequiredMemory Upgrade Part Number
5505Unlimited (inside hosts=Unlimited)256 MB512 MBASA5505-MEM-512=
5505Security Plus (failover=enabled)256 MB512 MBASA5505-MEM-512=
5505All other licenses256 MB256 MBNo Memory Upgrade Needed
5510All licenses256 MB1024 MBASA5510-MEM-1GB=
5520All licenses512 MB2048 MB *
ASA5520-MEM-2GB=
5540All licenses1024 MB2048 MB *
ASA5540-MEM-2GB=
5550All licenses4096 MB4096 MBNo Memory Upgrade Needed
5580All licenses8-16 Gb8-16 GbNo Memory Upgrade Needed

* Note:  The maximum memory supported for the ASA-5520 and ASA-5540 is 2 Gb.  If you install 4 Gb of memory in these units, they will go into a boot loop.

How to Determine How Much Memory Your ASA Has

From the CLI, you can issue the show version | include RAM  command to see how much memory your ASA has.  In the following example, it is an ASA-5520, with 512 MB of RAM, and therefore would require a memory upgrade prior to installing 8.3 on it.

ASA#

show version | include RAM

Hardware:   ASA5520, 512 MB RAM

, CPU Pentium 4 Celeron 2000 MHz

For ASDM users, you can see the amount of RAM in the ASA from the ASDM Home (Device Dashboard) page.

Why Does the ASA Need a Memory Upgrade?

This seems to be a fairly common question with customers.  Why exactly are we requiring a memory upgrade in order to run 8.3?  The reason is simple.  The memory on the ASAs have not been increased since they were originally introduced, yet as the years have gone by new features have been added which require additional memory at boot.  The more memory the base image requires, the less memory there is for things like ACLs, connections, IPSec tunnels, SSL tunnels, etc.  Additionally, as we introduce new features and customers adopt those, they consume additional memory.

Remove nat-control from your ASA Configuration

nat-control is a legacy feature which was created to help users migrate from PIX 6.x to PIX/ASA version 7.0 and higher.  In PIX 6.x, if you wanted to pass traffic between two interfaces, it was required that you have a NAT configuration which would allow it.  PIX/ASA version 7.0 removed this restriction, and made the behavior like routers.  Which is, ACLs control if traffic is permitted or not.  NAT then becomes optional.  However, in order to preserve the behavior for the PIX customers, if a PIX user upgraded from 6.x to 7.0, then the nat-control command was automatically added to the configuration.  The same is true of customers using the PIX to ASA migration tool.  Thus, there may still be a number of customers with nat-control in their configuration, and who do not need it.

What happens if I remove the nat-control command?

Answer:  Not much.  Removing the command just means that traffic can flow between interfaces without requiring a nat policy.  Therefore, the security policy of what traffic is permitted or denied is defined by your interface ACLs.

What happens if I leave the nat-control command in my configuration?

Answer:  Since 8.3 no longer supports the nat-control command, it will add equivalent nat commands to enforce a policy which requires explicit nat rules to allow traffic to pass between interfaces.  An example is shown below.  Note that the number of these rules increases exponentially with the number of interfaces on your ASA.  Thus, it is highly recommended that if your security policy (ie: ACLs) is used to control what traffic is allowed where, then you should issue no nat-control prior to upgrading to ASA version 8.3.  This will prevent the following nat rules from being created - which will block traffic between interfaces, until a more specific nat policy is defined for that traffic.

pre-8.3 Configuraiton
8.3 Configuration
nat-controlobject network obj_any
   subnet 0.0.0.0 0.0.0.0
   nat (inside,outside) dynamic obj-0.0.0.0
object network obj-0.0.0.0
   host 0.0.0.0
object network obj_any-01
   subnet 0.0.0.0 0.0.0.0
   nat (inside,mgmt) dynamic obj-0.0.0.0
object network obj_any-02
   subnet 0.0.0.0 0.0.0.0
   nat (inside,dmz) dynamic obj-0.0.0.0
object network obj_any-03
   subnet 0.0.0.0 0.0.0.0
   nat (mgmt,outside) dynamic obj-0.0.0.0
object network obj_any-04
   subnet 0.0.0.0 0.0.0.0
   nat (dmz,outside) dynamic obj-0.0.0.0
object network obj_any-05
   subnet 0.0.0.0 0.0.0.0
   nat (dmz,mgmt) dynamic obj-0.0.0.0

If you forget to issue no nat-control prior to upgrading, then it is safe to remove the all 0's objects with associated nat rules after the fact.

To view your current nat-control configuration, issue the command show run all nat-control.

How to Upgrade Your ASA to 8.3

Upgrading your ASA to 8.3 is the same process as all previous upgrades.  Just copy the image over to the flash, specify the file to boot, and then reboot your ASA.  Upon first boot, the ASA will auto convert your 8.2 configuration into the new syntax for NAT and ACLs required of 8.3.  While your CLI commands will change, your devices security policy will remain the same.

Please note that we only support upgrading to 8.3 from 8.2.  Therefore, you need to be running 8.2 on your ASA prior to upgrading to 8.3.

For ASAs in failover set, we do support upgrading from 8.2 to 8.3 with zero-downtime.  Follow the same procedure you have in the past.

Note: During the upgrade process, the ASA will save two files on disk.

  1. The current (pre-upgraded) configuration in a file named <version>_startup_cfg.sav 
    Example: disk0:/8_2_2_0_startup_cfg.sav
    This file will be critical if you need to downgrade your ASA from 8.3 to 8.2 in a future date
  2. Warning messages and Errors encountered during the upgrade process of converting your configuration to 8.3 will be saved in a file named upgrade_startup_errors_<timestamp>.log

Upgrade Paths

Cisco officially supports upgrading to ASA version 8.3 only from ASA version 8.2.  Therefore, if you are currently running a version of ASA code prior to 8.2, you will need to perform a stepwise upgrade.  Please see the table below:

Current TrainIntermediate UpgradesFinal Train
8.2none8.3
8.18.28.3
8.08.28.3
7.28.0 --> 8.28.3
7.17.2 --> 8.0 --> 8.28.3
7.07.2 --> 8.0 --> 8.28.3

Examples of Configuration Changes in 8.3

NAT

The NAT CLI configuration for 8.3 is radically different than anything than you may be used to. Therefore, for CLI users, it is recommended you ease into 8.3 with the expectation that you will have to re-learn NAT.  For those who view this as an obstacle, we would recommend that you use ASDM or CSM or some other GUI tool to configure the ASA - as the GUI configuration for 8.3 is largely the same.

That said, for CLI users, please do not upgrade to 8.3 on a Friday night just as you are getting ready to go out of town for the weekend.  Instead, it is recommend that you play with it in a lab (if you have one), or read up on the changes (see Additional Information below) before you upgrade.  Ok, with that said, let's look at some examples.

NAT Feature
pre-8.3 Configuration
8.3 Configuration
Static NATstatic (inside,outside) 209.165.201.15 10.1.1.6 netmask 255.255.255.255

Option 1 (Preferred)

object network obj-10.1.1.6
  host 10.1.1.6
  nat (inside,outside) static 209.165.201.15

Option 2

object network server_real
host 10.1.1.6
object network server_global
host 209.165.201.15

!

nat (inside,outside) source static server_real server_global

Dynamic PATnat (inside) 1 10.1.1.0 255.255.255.0
global (outside) 1 209.165.201.254

object network internal_net
  subnet 10.1.1.0 255.255.255.0

!

object network internal_net
nat (inside,outside) dynamic 209.165.201.254
Dynamic NAT with Interface Overloadnat (inside) 1 10.1.1.0 255.255.255.0
global (outside) 1 interface
global (outside) 1 209.165.201.1-209.165.201.2

object network NAT_Pool
range 209.165.201.2 209.165.201.50
object network internal_net
subnet 10.1.1.0 255.255.255.0

!

object network internal_net
nat (inside,outside) dynamic NAT_Pool interface


ACL Changes

Although the syntax of the ACLs haven't changed much (just added capabilities for new objects), the significant change is that all IP addresses listed in ACLs which are applied to an interface will be converted (on upgrade) from using global (ie: translated or post-NAT) IP addresses, to using the real IP address.  Let's look at an example.

ASA_8_3_ACL_Diagram.jpg

In the above Topology, an internal web server (with IP 10.1.1.6) is being protected by an ASA.  Clients on the Internet access this web server by its public IP address:  209.165.201.15  Prior to version 8.3, the interface ACL would permit traffic to the public IP 209.165.201.15.  But, starting with 8.3 the real IP 10.1.1.6 is used in the configuration.  Please see the configuration examples below.

1. pre-8.3 Configuration

static (inside,outside) 209.165.201.15 10.1.1.6 netmask 255.255.255.255

!

access-list outside_in extended permit tcp any host 209.165.201.15

access-group outside_in in interface outside

2. 8.3 Configuration

object network obj-10.1.1.6
  host 10.1.1.6
  nat (inside,outside) static 209.165.201.15

!

access-list outside_in extended permit tcp any host 10.1.1.6

access-group outside_in in interface outside

What to Do If You Run Into Problems with 8.3

  1. Call in to the TAC, and they can help you
  2. Check the upgrade_startup_errors_<timestamp>.log on disk0: by using the more disk0:/upgrade_startup_errors_<timestamp>.log
  3. Downgrade to 8.2 using the downgrade <image> <config> command.  This is IMPORTANT!  You must use the downgrade command, specifying the config file on disk (which the 8.3 upgrade process saved)

Refer the following video of this document---

https://supportforums.cisco.com/videos/2200

Additional Information

Average Rating: 4.9 (11 ratings)

Comments

v-bharath Mon, 08/23/2010 - 08:29

Hello David,

This Doc is awesome sir, cleared almost all my doubts.. Great job...

and thanks a lot for /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;} Kureli (kusankar) for refering this link....

d.gesch Sat, 12/11/2010 - 10:43

Hi David,

Thanks for the doc.  Another gotcha to be aware of:  If you use names in your config (and thus ACLs) in 8.2, the ACL's will not convert properly to the new style of using the real vs. mapped address in 8.3 - ouch!  You will upgrade, and not too much will work!  Make sure you enter "no names" before you do the upgrade so the conversion can work properly, and save yourself major headaches.

Belmarsad Mon, 03/14/2011 - 09:26 (reply to d.gesch)

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;}

Hello,

I have one question about your doc (For ASAs in failover set, we do support upgrading from 8.2 to 8.3 with zero-downtime) I have tried the procedure described on the link below when I upgraded from 8.2.1 to 8.2.2 (I have active/standby) and it didn’t work.

Here below what I did first as recommended by Cisco: http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/admin_swconfig.html#wp1231764

1-      I put new images and both my ASA, and changed the boot system command

2-      Reload the standby from the active, with command “failover reload-standby”

3-      So after my standby come up the failover was broken as there was two different version, I had error message seeing that the version are not the same on the failover pair.

4-      So my both ASA was in Active mode without failover

So What I did is:

1-      Disconnect the secondary from the network

2-      Reboot the primary active (come up with new version without failover) = downtime while reboot of primary

3-      Put the secondary on standby mode offline (already new version)

4-      Connected the secondary back to the network

5-      Enable again failover mode

I had exact same problem when I upgraded the licence on my failover ASA.???

So I guess that the problem will be the same if you upgrade from 8.2 to 8.3 ??

Thanks for your answer

aeryilmaz Mon, 03/21/2011 - 07:33

Hi all - I found this article was very helpful in understanding what to expect with the upgrade. I recently upgraded from 8.2(3) to 8.3(2) and thought I'd share my experience based on some of the other comments:

1. I was able to perform the zero downtime upgrade as documented by Cisco. No problems encountered.

2. I use names in my config and did not run into any problems when those were converted in the ACLs. It helps to step through the upgrade in a test environment to understand how the migration modifies the names and ACLs.

3. I stepped up to 8.3(2) by first upgrading to 8.3(1), then to 8.3(2). This is recommended by Cisco to avoid the unidirectional keyword bug.

My upgrade went smoothly with the help of all the documentation found here.

tdhb..hiq Sun, 05/22/2011 - 21:47 (reply to aeryilmaz)

Hi,

When you upgraded, did you bring up the standby unit to 8.3(1) first then the failed over then upgraded the old active one then failed back and repeated the proccess to 8.3(2)?

I am trying to upgrade from 8.0(4) to 8.3(x) with zero downtime.

Regards,
Scott

aeryilmaz Mon, 05/23/2011 - 08:42 (reply to tdhb..hiq)

Hi - yes, that is exactly how I did it. You'll get a warning about version mismatch but you can safely ignore that while performing the upgrades.

In a nutshell:

Copy new image to both units

Set the boot image

reload the standby

failover

reload the former primary (new standby)

failback


Good luck!

pari082007 Mon, 10/10/2011 - 04:11

Thanks fo this Artikel.

We also have to worry about Cisco Security Manager Update parallel to this ASA Upgarde process.

Thats a lot of fun - as always :-)

Good luck - to all of us.

scrye Wed, 10/12/2011 - 12:13

Cisco's new paradigm of always referring to the real addresses instead of the translated address was a huge mistake! This is confusing and unneeded. Does anyone have an explanation as to WHY this was done?

tochukwu_iwuora Wed, 11/23/2011 - 07:35

Hi Scyre,

Well for one, I know this was done to allow more flexibility in NAT use, in a situation where the mapped address in a NAT rule is modified there will not be any need to change the access-lists.

Hi All,

I want to upgrade a 5520 from 8.0(4) software because of certain security vulnerabilites but unfortunately I do not have up to 2GB RAM for the recent 8.4 software.

Please does anyone know how I can get the system requirements for the 8.0(5.25) Interim release. And if there are any differences in upgrade procedure or operation with this release.

Your quick response will be highly appreciated.

Thanks,

Julio Carvaja Thu, 06/13/2013 - 17:18

Hi,

I always recommend this document when someone asks about an upgrade to 8.3 or higher versions,

Good job

Julio Carvajal

Bransomar Mon, 08/19/2013 - 09:24

I inherited an active-standby failover pair that is running 7.2(4).  I need to get this pair upgraded to 8.4(5) at least, maybe higher.

Has anyone tried the following?

1. Break a failover pair, taking one offline

2. Performing all the upgrades on the offline ASA

3. Take down the active ASA and bring the upgraded ASA online as the active.

4. Upgrade the remaining ASA by installing the newest code only, no staggered upgrades.

5. Re-create the failover pair and sync the Active to the new Standby.

Seems like it would be faster than doing all the staggered upgrades and failovers on both devices.  There would be no redundancy for a period, and a short outage when swapping the active ASA's but that would be doable in my situation.

Anyone have any thoughts about this method?

Thanks

Actions

Login or Register to take actions

This Document

Posted August 20, 2010 at 8:53 AM
Stats:
Comments:18 Avg. Rating:4.9
Views:151265 Contributors:16
Shares:3

Related Content

Documents Leaderboard