cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1164
Views
5
Helpful
6
Replies

Moving from 8.4(1) to 9.0(2)

I need to move from ASA 8.4(1) to 9.0(2).

Reading http://www.cisco.com/en/US/docs/security/asa/asa90/release/notes/asarn90.html#wp582431 it seems to be a quite safe upgrade cause I do not have IPv6 ACL and I have only IKE v1. The following is not very understandable to me,

No  Payload Encryption for export—You can purchase some models with No  Payload Encryption. For export to some countries, payload encryption  cannot be enabled on the Cisco ASA 5500 series. The ASA software senses a  No Payload Encryption model, and disables the following features:

Unified Communications

VPN

You can still install the Strong Encryption (3DES/AES) license for use  with management connections and encrypted route messages for OSPFv3. For  example, you can use ASDM HTTPS/SSL, SSHv2, Telnet and SNMPv3. You can  also download the dynamic database for the Botnet Traffic Filer (which  uses SSL) and redirect traffic to Cloud Web Security.

Reading http://www.cisco.com/en/US/docs/security/asa/asa84/release/notes/asarn84.html#wp415084 under 'Limitations and Restrictions' I find this point moving to 8.4(2), which I also dont understand,

Currently in 8.4(2) and later, the PAT pool feature is not available as a fallback method for dynamic NAT or PAT. You can only configure the PAT pool as the primary method for dynamic PAT. For example, if you enter the following twice NAT command that configures a PAT pool (object2) for fallback when the addresses in object1 are used up, you see the following error message:

hostname(config)# nat (inside,outside) source dynamic any object1 pat-pool object2

interface round-robin

ERROR: Same mapped parameter cannot be used to do both NAT and PAT.

ERROR: NAT pool allocation failed.

You can alter this command to make it PAT-pool only by removing object1; the PAT pool is used as the primary method, instead of as a fallback method:

hostname(config)# nat (inside,outside) source dynamic any pat-pool object2 interface

round-robin

(CSCtq20634)

Is there any other point I need to consider moving from ASA 8.4(1) to 9.0(2)? any advice or upgrade experience?

Thank you

6 Replies 6

Marvin Rhoads
Hall of Fame
Hall of Fame

I would recommend avoiding 9.0 releases and going directly to 9.1.

I'm not sure if 9.0(2) has fixed it but I had some serious problems on a 5525X pair with 9.0(1) which were fixed with an upgrade to 9.1(1).

Your advice is to move to the last one? I thought it was better moving to te second-last one. Anyway do you think I can move directly from 8.4.1 to 9.1 or is it better to move from 8.4.1 to the last minor of 8.x and then from the

last minor of 8.x to 9.1 (considering also that firewall are in failover pair) ?

As regard the above questions ?

The TAC recommendation which I took was to move to 9.1(1). But that was before 9.0(2) was out so your situation may differ. I have a customer running about 10 5512-X and 5525-X on 9.1(1) with good results.

Re the upgrade path, you can go directly from 8.4(1) to either 9.0(2) or 9.1(1).

Thanks for your reply!

Is it possible to open a Cisco TAC to get advising about upgrading release ?

According to the release notes for 9.1(1) and 9.0(2), the difference between 9.0 and 9.1 is that 9.1 enabled ASA CX support; there were supposedly zero caveats resolved.  9.0(2) fixes zillions of caveats, and seems to be the recommended Cisco "upgrade" for both 9.0(1) and 9.1(1)!

I'm currently testing 9.0(2) for my own upcoming 5525-X upgrade.

You may need to turn off DNS inspection; there is an unresolved bug CSCue87407
with non-octet boundary PTR lookups which their NAT46 support introduced.  See the discussion in:

https://supportforums.cisco.com/message/3867771

-- Jim Leinweber, WI state Lab of Hygiene

Poiu - Yes you can open a TAC case proactively (assuming you have an active Smartnet contract on your ASA) requesting advice re which image to go with.

James - Yes I read the same 9.1(1) release notes and had originally decided to go with 9.0(1) on that basis. I was told by the TAC engineer that there were non-publicly released caveats that are resolved in 9.1(1). How those map to the publicized ones fixed by 9.0(2) we can only speculate. I can only say that when I loaded 9.0(1) it ran fine in a non-production environment for over a month. As soon as I put it in production with a decent load (about 30-50 Mbps throughout the day) it started rebooting on me. Luckily it was an HA pair and the reboots would force the standby to become active until it too crashed and so on over the course of a morning. As soon as I upgraded to 9.1(1) the reboots ceased and have not repeated since (over two months now)

Feature-wise you certainly don't get any benefit other than CX support (which requires the additional SSD and licensing to use) with 9.1(1).

Review Cisco Networking products for a $25 gift card