topic Hi Phil, in Network Security

Cisco ASA 5520 upgrade 8.2.5 to 9.1.7

Alexandre.Parent92 — Tue, 12 Mar 2019 07:35:09 GMT

Hi,

I have an upgrade tonight for a customer in order to upgrade a StandAlone ASA 5520 in version 8.2.5 to 9.1.7. I have the same upgrade next week for the same customer for a Failover Pair.

I already made this kind of upgrade process from 8.2.x to 9.1.x so I know all the process since i have to make a first step from 8.2.5 to 8.4.6 and then 9.1.7. In addition this customer doesn't have any Nat Statement so normally an easy process.

But today during my routine in order to prepare the upgrade (i prefer make a double or triple check before) i found this bug :

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuh19234;jsessionid=0A693D57F1BED0C4E78355A4270FD5E

This bug is resolved in the version 8.4.7 and 8.4.6.99 .But it's not recommended by the upgrade process to make a jump from 8.2.5 to 8.4.7 and I can't find the 8.4.6.99 version.

I don't want to have any problems during my upgrade with something that i can avoid.

As I said I already done this upgrade in the past without any problems and with more complex configuration.

Did anyone as a return for this process for the last months? Should I make an additionnal step ? (8.2.5 to 8.4.5 first prior to 8.4.6 or 8.4.7)

Thanks by advance for your anwser.

There are few incidents

Dinesh Moudgil — Wed, 06 Apr 2016 11:01:08 GMT

There are few incidents reported for ASA 5520 running 8.2.5 hitting this defect.

You might want to go for additional upgrade for 8.4.x like you mentioned to avoid the defect as one can not say for sure whether you will run into this situation or not. 8.4.6.99 might be a development image so may not be available unless you want to call TAC and confirm that or get any other image in 8.4.x train.
Perhaps, adding another code in upgrade might not hurt as much as hitting the bug.

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.

Hi Alexandre, I am planning

Joe Bubba — Wed, 06 Apr 2016 14:31:13 GMT

Hi Alexandre, I am planning to execute a similar upgrade (8.2.5 Failover Pair to 9.1.7-4) and was curious on how you planned to implement this?

I understand that this exercise requires multiple jumps (8.2.5 to 8.4.6 to 9.1.7) as well as config (ACL/NAT) changes. However, in my circumstance - I will also need to upgrade from 1Gb to 2Gb RAM.

One option is to break the failover pair
upgrade the standby offline
move traffic (cables/etc) to the updated ASA
Repeat for remaining ASA
then re-establish the failover pair.

Another option is to build an upgraded ASA w/ the current config.
Replace it with the failover pair
Upgrade the pair offline
Replace upgraded pair back into the network.

The main concern I have is the multiple upgrades, config changes and RAM upgrade all in one shot.

Just curious on how you were planning to roll out your pair upgrade.

Thx

hi,

johnlloyd_13 — Wed, 06 Apr 2016 14:40:59 GMT

hi,

you could do the upgrade path:

8.2.5 > 8.4.6 > 9.1.7

see links below:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/upgrade/upgrade84.html#pgfId-50546

http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/upgrade/upgrade91.html#pgfId-61264

Hi.

Alexandre.Parent92 — Wed, 06 Apr 2016 16:02:01 GMT

Hi.

As I said my question is about a bug during the upgrade process from 8.2.5 to 8.4.6. I don't know if this bug is recent or no because I never had that bug during my previous upgrades that's why I'm asking.

Hi Phil,

Alexandre.Parent92 — Wed, 06 Apr 2016 16:30:50 GMT

Hi Phil,

This what I'm doing generally for a failover pair step by step. I always announce a disruption of service for this kind of upgrade.

- Upgrade the memory of the Secondary unit

- Upgrade the memory of the Primary Unit

- Upload all packages (8.4.6 and 9.1.7 + ASDM if required)

- Change boot option to 8.4.6 on the Primary Unit (replicated to the Secondary Unit) and save.

- Then I'm turning off both ASA.

- Reboot the Primary Unit and let it boot and migrate the configuration. Once it's done you can do the same with your Secondary Unit.

- Then you can do your test and review all your ACLs and NAT rules in order to get a clean configuration.

- Then do the same for the other steps of version.

I never had problems with this process. It just cause disruption of service of 2*15 minutes. We usually do these upgrades on non-working hour.