Zero downtime Upgrade ASA 8.0(4) TO 8.4(7)

Hi All,
I checked a few blogs and upgrading ASA 5520 from 8.0(4) to 8.4(7) following below path. I will be upgrading RAM to 2GB at version 8.2.5. Reason for 8.4.6 is we may get an error message ""No Cfg structure found in downloaded image file" Error Message" if we upgrade directly to 8.4.7.
Please advise if we can perform Zero downtime upgrade if I follow below path and will they still be in HA? Active/standby
8.0.4-->8.2.5 (Active on 8.0.4 and standby 8.2.5)--> Will they be in HA?
8.2.5--->8.4.6(Active on 8.2.5 and standby 8.4.6)--> Will they be in HA?
I believe below one should not be a problem.
8.4.6-->8.4.7(Active on 8.4.6 and standby 8.4.7)--> Will they be in HA?
Thanks in advance.
Regards

8.0.4-->8.2.5 (Active on 8.0.4 and standby 8.2.5)--> Will they be in HA?
HA will work...as in the units will failover. But due to changes in configuration syntax you could run into problems with config synchronisation. And could also cause issues in traffic flow if a failover occurs. So it is best to upgrade the second ASA to the new version ASAP. It is also the reason cisco recommend using the same Major and Minor software versions.
8.2.5--->8.4.6(Active on 8.2.5 and standby 8.4.6)--> Will they be in HA?
Same as above.
8.4.6-->8.4.7(Active on 8.4.6 and standby 8.4.7)--> Will they be in HA?
This should be fine
Please remember to select a correct answer and rate helpful posts

Similar Messages

Cisco ASA non zero downtime upgrade

Hello,
with a NON zero downtime procedure upgrade all connections are lost, even nat and arp table ? here, http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/ha_overview.html#wp1078922, on Table 61-2 State Information I think it is only for plain failover but not for upgrade with a non zero downtime upgrade procedure.

Assuming you have a working HA pair with stateful failover, the Cisco supported answer is that you cannot skip minor releases (i.e. going from 9.1 directly to 9.3).
You CAN upgrade directly from 9.1(2) to 9.1(5) as that third ordinal (the number in parentheses) is known as the maintenance release level.
See table 1-6 in the Release notes for confirmation, excerpted here:
"You can upgrade from any maintenance release to any other maintenance release within a minor release.
For example, you can upgrade from 8.4(1) to 8.4(6) without first installing the maintenance releases in between."
Note that 9.1(3) or later have some restrictions that are unique to those more recent code levels as some file system changes were put in place that requires certain prerequisites for a successful upgrade. Given that you are on 9.1(2) already that doesn't affect you in this case but it may be a consideration for other readers. Those requirements are noted just above Table 1-6 in those release notes.

ASA 5520 Upgrade 8.0(4)-- 8.4.2--Zero Downtime

Hello Everyone,
We are currently on 8.0(4) and planning on upgrading our failover pair to 8.4.2, I read some documents saying that we can perform a zero downtime upgrade.
According the below documents Version 8.2 supports mismatch memory failover,
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ha_overview.html#wp1077536
https://supportforums.cisco.com/message/3549760#3549760//
Upgrade Path:
Active Firewall:                         Standby Firewall:
   8.0(4)                                       8.0(4)-->8.2.2
   8.0(4)                                       Upgrade RAM-2G---Reload
   faiover to standby                    8.2.2
   8.0(4)--->8.2.2                          8.2.2
   Upgrade RAM-2G-reload         8.2.2----Fail over
   8.2.2--Active                             8.2.2--Standby
8.2.2                                          8.3.1
8.2.2                                          8.4.2
Failover to stanby                      8.4.2
8.2.2--Standby                           8.4.2-----Active
Can I perform zero downtime upgrade with the above upgrade path? Will both the firewalls act as a failover pair if one is on 8.2.2 and other is on 8.4.2.
"Performing Zero Downtime Upgrades for Failover Pairs
The two units in a failover configuration should have the same major (first number) and minor (second number) software version. However, you do not need to maintain version parity on the units during the upgrade process; you can have different versions on the software running on each unit and still maintain failover support." (http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/admin_swconfig.html)
Upgrade RAM-2G

You can do it in a lot fewer steps.
1. Upgrade RAM on standby, reload and make it active.
2. Repeat process for newly standby unit.
Now you have 2 units still on 8.0(4) with requisite RAM for 8.3+. TAC will recommend you go up in "baby steps" but the software will work upgrading directly from 8.0 to 8.4. 8.4(3) is the current version for the 5520 platform. At most conservative, I might upgrade to 8.2(4) as an interim but it's not strictly necessary. So my next step would be:
3. Upgrade standby unit from 8.0(4) to 8.4(3). At this point take stock of the script syntax changes. Examine the upgrade log (on disk0:) and address any discrepancies.
Note active/standby failover will work here but should not be run this way for any extended time as syntax changes would affect the ability to synchronize if changes are introduced on the active member.
Finally:
4. Flip upgraded standby unit to active and upgrade remaining standby unit to 8.4(3).
If you follow these steps and check your work after each step, this would all be zero downtime.

Zero downtime deployment

Hi, was just wondering about "best practice" in terms of supporting zero-downtime deployment.
We have a cluster with N nodes that are not storage nodes, and M nodes that are storage nodes. We use java all around, and pof-serialize the objects that we store in coherence.
We want to deploy a new codebase, which requires a restart of all the processes, and it might also include changes to the objects that are being stored (ie, their serialization might be different).
The typical approach is to do a "rolling restart" of the various processes, but i fear all that synch-up coherence does might not work right with some members running an older version of code, while the ones that are restarted are running a newer version of the code.
Anybody have any experience with this?
Thanks.

Hi,
If you change the serialisation format then a rolling restart will not work. You need to make sure that all your POF classes are evolvable - that is that they implement EvolvablePortableObject. Doing this can take a lot of effort. We do it, not for rolling restart, but to make sure clients of our system do not constantly need to upgrade their client libraries. It can be quite complicated as it is not just serialisation that you need to be aware of but even changing how methods work that get called on the server side can break evolvability, for example changing how a filter works, an aggregator works, a method return type etc.
We have looked at zero downtime rolling restarts in the past and decided they were more trouble than they were worth. In our case we have large clusters 300+ nodes so a rolling restart would take a very long time as you need to wait for the cluster to re-balance the partitions each time you stop then restart the node. We found it could take quite a few hours to do a rolling restart whereas a full deployment and reload of the data take about 90 minutes.
You would also need to be careful if your cluster sits on top of a database. If you need to make any DB changes then this will not work unless they can some how be evolvable too otherwise either the new code or old code will be incompatible with the start of the DB.
Other people may have different experiences of zero-downtime, but as I said, we just found it too much effort and just go for the normal small-amount-of-planned-downtime approach.
JK

Problems after upgrading ASA from 8.4.5 to 9.1.1

Hi,
We are having problem with behavior of nat statement after upgrading ASA. Here are results of packet tracer in our testing environment:
object network onBK028VRRP
host 1.1.1.111
object network onSIEMServers
host 1.1.1.1
object service osSyslog
service tcp source eq telnet
object-group network ognBK028ClientsOutside
network-object 10.0.0.0 255.0.0.0
nat (inside,outside) source static onBK028VRRP onSIEMServers destination static ognBK028ClientsOutside ognBK028ClientsOutside service osSyslog osSyslog
ASA 8.4.5
packet-tracer input OUTSIDE tcp 10.1.1.1 50000 1.1.1.1 80 detailed
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   1.1.1.0         255.255.255.0   inside
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group IZOUTSIDE in interface outside
access-list IZOUTSIDE extended permit tcp any any eq www
Additional Information:
Forward Flow based lookup yields rule:
in id=0xce99ccc8, priority=13, domain=permit, deny=false
        hits=0, user_data=0xc91bc540, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=80, dscp=0x0
        input_ifc=outside, output_ifc=any
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xcb53d948, priority=0, domain=inspect-ip-options, deny=true
        hits=42, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=outside, output_ifc=any
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xcb561758, priority=0, domain=inspect-ip-options, deny=true
        hits=40, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=inside, output_ifc=any
Phase: 5
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 43, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat
Module information for reverse flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
ASA 9.1.1
packet-tracer input OUTSIDE tcp 10.1.1.1 50000 1.1.1.1 80 detailed
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   1.1.1.0         255.255.255.0   inside
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (no-route) No route to host
Which option change this?
BR, M.

Looks like you are hitting the following bug: CSCud64705
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCud64705

Zero Downtime Migration from Oracle to Sybase

Is there any way/ tool to migrate from oracle to sybase with Zero Downtime??
Thanks

Better answered on a Sybase forum I suppose...

Zero-downtime Database Migration tool ?

We are exploring\evaluating tools provided by Oracle (or its partners) that ensures Zero-downtime Database Migration. Migration should include:
- Migration of data from one version of the application to another version with or without changes to the database schema.
- Migration of data from staging to production where staging was used for beta testing to host customers who created live data which need to be migrated to production. (Oracle to Oracle, SQL Server to Oracle, MySQL to Oracle, etc)
- if a data type changes (say int to varchar) in staging database for a particular column in a table, the change migration should happen in the production database as well
- if a column is added\deleted in a table of staging database, the same table alteration should migrate to production database
- records in production database should not be deleted\truncated during data\schema migration
- maintain zero-downtime
By Zero-Downtime we mean: both the source and the target should be up and accept updates in real time during migration process. This should again be synced across and hence help to eliminate downtime during migration between various vendor databases.
We are not looking for any ETL product, but out-of-the-box products like GoldenGate and Celona that ensure Zero-downtime database migration.

Hi,
I dont think that there is any easy answer. It looks like huge project so it should be done part to part.
If I understand
1) you have create staging database with all changes
2) production is in old structure
3) now you want to merge this two databases into one? Or applly all changes form staging to prod?
I see there one solution clone your staging and create new prod. Whenit's donw switch connection to your new prod database.
Regards,
Tom

Zero downtime backups

I was shocked to read the following notation on Sun's Training website web page:
"Please note that the Sun Web Learning Center will be down once a week for backup on Saturdays from 1:00 to 3:00 A.M. MDT (Friday 19:00 to 21:00 GMT)."
I have been researching various methods of backup including fssnap ufsdump flar and others only to find it seems there is no "best way" to backup without downtime. It appears as though it is still best and most reliable to bring the system into single user mode to do a proper backup; and the fact that Suns Sys Admins feel it best to bring down the Learning Center system "teaches" me it must be best.
Does anyone have any insite into why this might be, and how it might be possible for the system backup to take place with zero downtime?

If you have enough diskspace you can go a long way with the use of ufssnap. But like you said; your milage may vary. I usually run ufsdump directly on the slices I wish to have backed up because I know there won't be much writes going on. So far this approach never failed me (and yes; it has been crash tested a few times).

Problems upgrading ASA 5505 memory

I am trying to get experience with 8.4 code on my 5505. I purchased a Cisco 512MB memory upgrade and installed it. It booted up once and I thought I was ok. I then looked down and noticed that all lights were blinking on the front panel and I had no console access.
Since I dont have smartnet on my personal 5505, calling TAC for help isnt an option. That is why I spent extra money on Cisco memory but it looks that didnt help. I am assuming all blinking lights isnt a good thing but I havent been able find an explanation.
I will try reseating the memory to see if that is the problem. I put the ASA on an anti-static mat and had it and myself properly grounded.
If this doesnt fix it, I will return the Cisco memory to the vendor and go back to the original installed memory. The ASA 5505 worked fine on 8.2.5.
Would appreciate any suggestions,
Ron

Ronald and James,
It has been over a month since you posted, so perhaps your issue was resolved. I actually experienced the exact same issue with my personal ASA 5505 today following an upgrade to 512MB. What really surprised me was James' comment that his worked for about 12 hours and stopped. That's exactly what happened to me today. It might have been 13 hours, but it was definitely in the ballpark.
The first thing I did was just disconnect power and re-connect the power to see if it magically went away. (I've never had to cycle the power on my ASA before, so I was not hopeful this would work. In fact, I was glad it did not work, as that would concern me even more.)
The next thing I did was disconnect everything, open the case, remove the RAM, blow out all of the dust using compressed air, and then re-install the RAM. So far, so good, but it has only been 15 minutes.
I'll keep an eye on this, obviously, but I am nonetheless curious to hear more about your situations. Were you able to resolve the problem permanently or were you unable to make the upgrade to 512MB?
UPDATE - My ASA continued to have issues with the new RAM module. It turned out to be a defective SIMM. I contacted the seller and returned the defective SIMM. They sent a new one and it works just fine.

Upgrading ASA (5520) from 8.2(5) to 8.4(6)

Hi All,
I'm planing to upgrade my failover firewalls active/standby from 8.2.5 to 8.4.6. I read about the NAT and I think I'm ready for it cross fingers
My plane is
Upload the 8.4.6 and ASDM 7.1.3 for both firewalls then assgin the boot and ASDM image to the new files. After thaton the active firewall reload the standby and wait until its up and running (cross finger again) then force the active to be standby and reload the standby to get the new 8.4.6.
am I right about that? or should I upgrade to 8.3.1 or 8.3.1 first ?? please if it is, can you give me the full upgarde path?
Thanks in advance!!!

I don't know if I'm going to answer your question. But here is my latest experience, about year ago. I just preformed an upgrade from 8.0.x to 8.4.4.1 on a pair of ASA 5510's in failover using CLI. The upgrade seem to go smooth from our end, but all connection did drop. We followed these steps here. NAT wasn't an issue for us.
Point is, there really isn't an upgrade path. Just reload stand-by unit, make it the active unit and watch the connections. Ours dropped don't know why.
Don't know if that helps,
Nick

Upgrading ASA 5510 from 8.0.4 to 8.2.5

We want to implement Netflow so want to upgrade our 5510 to 8.2.5. But have a few questions.
This device has 64MB of flash and 256MB of DRAM. Would I need to upgrade RAM? Right now we have about 25 site to site VPNs running through this thing as well as a few remote clients. Is this enough to constitute a memory upgrade?
Right now we are running ASDM 6.4.7. Should we upgrade to a higher version?
And lastly, would the upgrade to 8.2.5 require the use of AnyConnect for our VPN client users? Our 5505 is on version 8.2.5 and doesn't require AnyConnect, but wanted to make sure.
Thank you for your time.

Hi Michael,
The RAM upgrade is needed if you want to go to 8.3+ code. Although you might find that you are running low on RAM and that will impact your ability to run packet captures, so an upgrade doesn't hurt...
ASDM can be upgraded seperately and does not require a reboot + new ASDM versions are backwards compatible with older ASA codes...
http://www.cisco.com/en/US/docs/security/asa/compatibility/asamatrx.html#wp42231
ASA 8.0(4)
ASDM 6.1(3) and later.Recommended: 7.1(4).
ASA 8.2(5)
ASDM 6.4(3) and later.Recommended: 7.1(4).
Although the Cisco VPN Client is eol and the replacement is AnyConnect, you are not forced to go that direction in any code...
Patrick

Upgrade ASA Compatibility 8.4 to 9.1

Hi
Does anybody knows if it is posible to have a mismatch in configuration if I upgrade from 8.4.5 to 9.1.5, this because the bug said that 8.4.7.15 and prior are vulnerable.
This bug says that 8.4.7.6 is the fix, but I can find that in the download software (8.4.7.15 is the last of this train).
The version is ASA 5540 Adaptive Security Appliance 8.4(5), Device Manager Version 6.4(9)
Thanks for your help.
Regards

I hope that you will find this discussion of upgrade paths to be helpful.
http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/release/notes/asarn91.html#pgfId-763574
HTH
Rick

Advice on upgrading ASA 5510 from version 8.4(4)1

Hello all,
Due to an issue we need to upgrade our ASA. Cisco Support team recommended upgrading to version 8.4.7, but, as we'll upgrade, we'd like to upgrade to version 9.
We still use Cisco VPN Client for Remote Access VPNs so I'd like your advice on which version to install on ASA.
Would you recommend version 9.0.3? 9.1.X?
Thanks in advance,
Igor

We have a pretty huge ASA and ASASM complex, and we are just about finished upgrading from an assortment of 8.4.x, 8.5.x, and 8.6.x installs to 9.1.3 on everything. There is one gotcha on some systems in that there is a file system change or some sort of bug that is fixed in 8.4.5 I think. So you _may_ have to first upgrade to a newer version (8.4.7 would work) before going to 9.1.3.
Our Cisco team has recommended going to version 9.x, and this is supported by recent tickets I've had on our stuff still running on 8.x, as the TAC engineer often says we need to upgrade to version 9.
Four our setup, we had some fatal bugs in 8.4.6 and 8.4.7 that kept us running 8.4.5 for a very long time on some equipment.
Anyway, I would recommend going to 9.1.3, which is one removed from the recently recleased 9.1.4. Our AnyConnect VPN complex has been on 9.1.3 for a few months now with no issues. Be sure to read the release notes thoroughly as 9.x changes some command contexts, new features, etc.
Graham

Sales analysis zero after upgrade from SBO 6.5 to 2005 SP01

Hi,
I have upgraded the DB directly from 6.50.099 SP:01 EF:27 to 2005 SP01 ( 6.80.318 SP:01 PL:18)
I have a clean install of SBO since it is running on another server now.
The only problem I got is that the sales analysis shows zero amounts in the total A/R invoices row for all invoices prior to the upgrade.
The invoices itself have the correct values.
Any clue how to fix this problem?

I just ran the Update Control Report and it shows that
table CRD1 now has more records 94 before 184 after
And there are 7 entries in the System Messages table saying
[Microsoft] [ODBC SQL Server Driver][SQL Server] Invalid column name 'prjcode'.

Upgrade ASA Software from 8.3.2 to 8.4.3

Hi,
does anybody did an Upgrade from an 8.3 version to the new version 8.4.3 and can give some hints or links to read?
I only have a production system and nothing to test and I don' want to get a nasty surprise...
Thanks a lot in advance

If you're already on 8.3(2) you've already gotten past the tricky bit - the new NAT syntax and access-list object use. There are some minor changes with identity NAT in going up to 8.4(3) as described here but that's about it as far as things to watch out for.
The TAC is quite helpful and it is a good idea to open a case proactively just to have them on hand to take a quick look at any issues that come up. The TAC security team deals with these upgrades every day and is very adept at zeroing in on the root cause of any issues you are having and setting things straight within in few minutes.

Zero downtime Upgrade ASA 8.0(4) TO 8.4(7)

Similar Messages

Maybe you are looking for