Showing results for 
Search instead for 
Did you mean: 

Community Tech -Talk Series - Migration Best Practices for ASA 8.3/8.4






Here are few MAJOR changes one should be aware of before the migration. This would help us understand what challenges we might have to face after the migration:-


NAT Redesigned


NAT Simplification


The NAT feature has been redesigned for increased flexibility and functionality. All NAT and NAT-related commands have been redesigned.


The NAT configuration was completely redesigned to allow greater flexibility and ease of use. You can now configure NAT using auto NAT, where you configure NAT as part of the attributes of a network object, and manual NAT, where you can configure more advanced NAT options.


Real IP Address


Another change is with the way you configure Real IP addresses in access rules instead of mapped addresses.


When using NAT or PAT, you used to have to specify the mapped addresses and ports in an access list for all features that use access lists. Now, for several supported features, you must use the real, untranslated IP address and ports. (Other features continue to use the mapped IP address).


When using NAT, mapped addresses are no longer required in an access list for many features. You should always use the real, untranslated addresses when configuring these features. Using the real address means that if the NAT configuration changes, you do not need to change the access lists. These features are automatically migrated to use real IP addresses when you upgrade to 8.3, unless otherwise noted.




Let's look at an example.


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



pre-8.3 Configuration

static (inside,outside) netmask


access-list outside_in extended permit tcp any host

access-group outside_in in interface outside



8.3 Configuration

object network obj-


  nat (inside,outside) static


access-list outside_in extended permit tcp any host

access-group outside_in in interface outside


Named network objects & service objects


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).


Named Network and Service Objects—Network and service objects are automatically created for NAT.


Although you can use named network and service objects in other features, such as access lists and object groups, objects are not automatically created for any feature other than NAT.


You can now create named network objects that you can use in place of a host, a subnet, or a range of IP addresses in your configuration and named service objects that you can use in place of a protocol and port in your configuration. You can then change the object definition in one place, without having to change any other part of your configuration.




Best practices while upgrading from pre-8.3 to the 8.3/above


  • Memory Upgrade

       To run Version 8.3 in a production environment, you need to upgrade the memory on        the Cisco ASA 5505, 5510, 5520, or 5540.


       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.


  • Startup Errors

       In case the migration hasn't gone well, to view the bootup error log enter the show startup-config errors command. To view the bootup error log,            enter the show startup-config errors command. See the following sample log


  • nat-control in 8.3 doesn't exist

       The nat-control command is deprecated. To maintain the requirement that all traffic from a higher security interface to a lower security interface be        translated, a NAT rule will be inserted at the end of section 2 for each interface to disallow any remaining traffic. The nat-control command was            used for NAT configurations defined with earlier versions of the adaptive security appliance. The best practice is to use access rules for access            control instead of relying on the absence of a NAT rule to prevent traffic through the adaptive security appliance.


  • Use the downgrade command if you want to revert - During the upgrade process, the ASA will save two files on disk.


       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


       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


       When you upgrade to Version 8.3, your configuration is migrated. The old configuration is automatically stored in flash memory. For example              when you upgrade from 8.2(1) to 8.3(1), the old 8.2(1) configuration is stored in flash memory in a file called 8_2_1_0_startup_cfg.sav.


Interesting features


  • ASA 8.3.1 : Non-identical failover licenses - Failover licenses no longer need to be identical on each unit. The license used for both units is the combined license from the primary and secondary units. Note For the ASA 5505 and 5510 adaptive security appliances, both units require the Security Plus license; the Base license does not support failover, so you cannot enable failover on a standby unit that only has the Base license.


  • ASA 8.4.1 : Stateful Failover with Dynamic Routing Protocols- In the previous code, dynamic routes were not replicated to the standby device upon failover. This code has included the replication of dynamic routes. This way you will not lose routes upon failover as the information would be sent to the other device without losing it. Routes that are learned through dynamic routing protocols (such as OSPF and EIGRP) on the active unit are now maintained in a Routing Information Base (RIB) table on the standby unit. Upon a failover event, traffic on the secondary active unit now passes with minimal disruption because routes are known. Routes are synchronized only for link-up or link-down events on an active unit. If the link goes up or down on the standby unit, dynamic routes sent from the active unit may be lost. This is normal, expected behavior.


  • ASA 8.4.2 : route lookup - In earlier releases for identity NAT, proxy ARP was disabled, and a route lookup was always used to determine the egress interface. You could not configure these settings. In 8.4(2) and later, the default behavior for identity NAT was changed to match the behavior of other static NAT configurations: proxy ARP is enabled, and the NAT configuration determines the egress interface (if specified) by default. You can leave these settings as is, or you can enable or disable them discretely. Note that you can now also disable proxy ARP for regular static NAT. For pre-8.3 configurations, the migration of NAT exempt rules (the nat 0 access-list command) to 8.4(2) and later now includes the following keywords to disable proxy ARP and to use a route lookup: no-proxy-arp and route-lookup. The unidirectional keyword that was used for migrating to 8.3(2) and 8.4(1) is no longer used for migration. When upgrading to 8.4(2) from 8.3(1), 8.3(2), and 8.4(1), all identity NAT configurations will now include the no-proxy-arp and route-lookup keywords, to maintain existing functionality. The unidirectional keyword is removed.



        We modified the following commands: nat static [no-proxy-arp] [route-lookup] (object network) and nat source static [no-proxy-arp] [route-lookup]         (global).



Watch the Tech-Talk and check out the Blog specifically written on the Migration Best Practices for ASA 8.3/8.4.



Additional Information