ASA 8.0 to 9.x directly ?

[eagles-nest]

Hi

Does anyone know where I can find an upgrade path advisory to see if I can go directly from 8.0(5)9 to a version 9 ?

Are there any advised intermediate steps ?  Documentation on the config migration process generally refers to going from 8.2 to 8.4

but I'm hoping to do this in one step.

Also has anyone achieved the process with zero downtime ?  I'm curious to know what happens, if anything, when I bring up one

firewall with a post 8.4 config while the other has a pre-8.4 config.

So I'm thinking I take the standby down

Reboot with, hopefully 9.x code and the config migrates.  What does the active have to say about this ?

I would then plan to failover active on the post 8.4 ASA, and take down the other.  Then either let it migrate again as it reboots or wipe it, reboot and

bring it back in to the pair as if it's a new blank config and have the current active replicate the migrated config.

Many Thanks, St.

[lcambron · Accepted solution]

Hello,

There are many different opinions about this.

From the 9.x release notes:

You can upgrade from any previous release (if  available for your model) directly to the latest release. When upgrading  to Version 9.0, because of configuration migration, you cannot perform a  downgrade; be sure to back up your configuration file in case you want  to downgrade.

If you are upgrading to Version 9.0, see the migration section in the release notes for configuration migration information.

If you are upgrading from a pre-8.3 release, see also the

Cisco ASA 5500 Migration Guide to Version 8.3 and Later

for important information about migrating your configuration.

I would prefer to upgrade first to 8.2.5 and then to 9.x

Since this is a mayor upgrade then zero-dowtime is not supported, however it is possible some times(depends on how well the upgrade goes and how complex is your config).

Failover will still work with different versions but it is not stable, you should be ok just while upgrading.

You are right about the steps:

upgrade standby,

make it active, if everything is fine:

upgrade primary, and finally make it active.

Regards,

Felipe.

[eagles-nest]

Many thanks Felipe

I think I had found the docs you refer from hence the question.  The doc below says go to v9 from any other version.

http://www.cisco.com/en/US/docs/security/asa/asa91/release/notes/asarn91.html#wp495651

While the one below says go via 8.2

https://supportforums.cisco.com/docs/DOC-12690#How_to_Upgrade_Your_ASA_to_83

I think I will go via 8.2 to be safe.

What confuses me is when I upgrade one ASA we have one with pre 8.3 config and one with post 8.3 config.  How will this be treated by the active ASA ?  So I take one ASA offline.  The other is pre 8.3 code and working live.  I upgrade the offline ASA and it migrates its config to post 8.3 commands.  When I bring it back up will it join the other ASA and be standby with post 8.3 code and config while the current active one is pre 8.3 code and config ? 

I can see this can be done when there is no config migration but with the config migration if we try to keep one ASA live there must be a window where one ASA will be pre 8.3 and the other post 8.3 code and config.  Maybe I misunderstand the failover part but I thought the active will attempt to replicate to a standby that has just been booted.  And we may have a phase where they are on different config types unless we do the final migration of config to both ASAs at once. 

Take down one, upgrade code and boot it.  Let it migrate config.

Take down the other, upgrade code and boot and it joins as standby.

So the downtime is the time to take both out of operation, reboot one and have its code migrated.

I can't see a way a zero downtime migration can work with the config migration phase being done.

Many thanks, St.

[lcambron]

Hello,

Excalty, since it is a mayor upgrade then zero-downtime is hard to accomplish.

The failover will still work with a pre and post 8.3 config, not sure if command replication is still done (will have to replicate this in a lab) but it is better to take them off production for the upgrade.

Regards,

Felipe.

[Karsten Iwen · Accepted solution]

In my opinion, it's best to plan some downtime with that upgrade, but if you plan your upgrade well you can achieve zero-downtime. There are some things to take care of:

• Has you ASA enough memory? If not upgrade the secondary ASA with new memory, bring it back into the FO-cluster, then upgrade the primary unit. Failover will remain active.
• The correct way for zero-downtime-upgrade would be 8.0 -> 8.2 -> 8.3 -> 8.4 -> 9.0 -> 9.1 because in FO only the next minor-version is allowed to be different on the two ASAs. (8.4 to 9.0 is allowed because 9.0 is the following release after 8.4)
• If you go from 8.0 to a release >8.2, then the ACLs will not be migrated. So the step via 8.2 is important.
• The NAT-migration is a PITA and often builds a non-working configuration. Be prepared to completely rewrite your NAT-config. I would prefer to do that before starting the migration as it is a good chance to remove old entries that are not needed any more.

Based on that, my preferred way of upgrading that would be the following (if you are allowed to have some downtime):

1. Upgrade memory if needed.
2. Take one ASA offline and upgrade that up to the version you want. There you can examine and correct the migrated config.
3. Test as much traffic as possible with the packet-tracer until everything seems fine.
4. Switch off the active ASA (the one running 8.0) and power on the ASA with the new version. Here you have a short downtime. This downtime can be reduced by having both ASAs switched on and shutting and unshutting the switchports of both ASAs
5. Test again, in case something goes horribly wrong, switch back to your old verision ASA; of course you will again have some downtime.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[eagles-nest]

Many thanks Karsten

I discovered that ACL issue when I tried to lab the migration. 

I found this bug CSCtf57830.

Conditions:

NAT exempt is configured with acl that contains any as the destination in the access-list tied to nat 0.

So I removed the NAT 0 statements and the ACLs seem to have migrated properly now.  Since NAT control is no longer used in later ASA code I would assume it is safe to leave the NAT 0's out of the final migration.  Anything not specifically defined as being NAT'd goes through unchanged.

This migration procedure seems fraught with danger.  It's not always possible to cover every config item in the time given so I thing the rule is to expect to deal with issues once you bring the firewalls back into service.  Don't you just love being the tester for Cisco ?  Especially on live networks.

BTW Karsten.  What does PITA mean ?

Thanks again, St.

[Jiri Votruba]

PITA=Pain In The @$$. I am getting ready for that as I have to migrate our VPN firewall to a new code due to this Cisco Security Advisory:

Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike?vs_f=Cisco%20Security%20Advisory&vs_cat=Security%20Intelligence&vs_type=RSS&vs_p=Cisco%20ASA%20Software%20IKEv1%20and%20IKEv2%20Buffer%20Overflow%20Vulnerability&vs_k=1