ASA CX5545 Upgrade Procdures

I need to upgrade my ASA 5545-x, I have updated to latest code and now I am attempting upgrade the the CX Module so that I can update the PRSM software.

In your particular case the 9.2(1.4) your CX module is running is the latest release (as of this posting date) even though it is not the highest number (version 9.3(1.1) build 112 was actually released earlier).
Generally speaking though one upgrades the CX module via the PRSM GUI. You can do it via the cli; but the GUI is much easier as it allows you to drag and drop the upgrade package directly into the GUI to transfer the image.
Here's a link to the procedure.

Similar Messages

ASA-SM Upgrade

Dears,
what precaution I have to take before upgrade,
I am upgrading ASA-SM image 8.5.1 to 9.1(2) and then 9.3(1) .And for ASDM direct upgrade from 6.5 to 7.3.
I have to upload both the images in Disk0 as per the link below it is showing in Disk0?? but below show version doesn't show up asdm image in disk0
http://www.cisco.com/c/en/us/td/docs/security/asa/asa93/upgrade/upgrade93.html#pgfId-52066
sh version
Cisco Adaptive Security Appliance Software Version 8.5(1)
Device Manager Version 6.5(1)
Compiled on Tue 03-May-11 14:21 MDT by builders
System image file is "disk0:/asa851-smp-k8.bin"
Config file at boot was "startup-config"
FWSM up 5 mins 11 secs
failover cluster up 5 mins 11 secs
Hardware:   WS-SVC-ASA-SM1, 23552 MB RAM, CPU Xeon 5600 series 2000 MHz
            2 CPUs, 24 cores
Internal ATA Compact Flash, 8192MB
BIOS Flash M25P32 @ 0x0, 64KB
Thanks

Dear Experts,
I am using SUP2T with the following IOS, do i need to upgrade the FPD, how i will know that i need to upgrade
the commands output are form the 6509 switch.
sh run | in boot
boot-start-marker
boot system flash bootdisk:
boot-end-marker
diagnostic bootup level minimal
dir from the 6509 switch.
Directory of bootdisk:/
    1 -rw-    33554432 Aug 14 2014 14:24:14 +04:00 sea_console.dat
    2 -rw-   113733048 Aug 14 2014 14:31:08 +04:00 s2t54-ipservicesk9-mz.SPA.151-2.SY2.bin
    3 -rw-    33554432 Aug 14 2014 14:26:52 +04:00 sea_log.dat
    4 -rw-       25832 Oct 31 2014 13:20:30 +04:00 startup-config.converted_vs-20141031-092028
Still I have not installed ASA-SM in the switch the day of migration i will install the ASA-SM, how i will know that i have to upgrade the FPD ??? and what actually it is helping for ASA-SM ,??? i hope compatibility is perfect between 15.1 switch version and asa-sm 9.3.???
I have a separate chassis (test scenario) with me i will upgrade the asa, and asdm image so i can upload the fpd image also if you experts give me confirmation for the fpd.
S1#sh hw-module switch 1 all fpd
% No cards with FPD support can be found in the indicated chassis or Not in VSS mode.
Thanks

ASA 5520 Upgrade From 8.2 to 9.1

To All Pro's Out There,
I have 2 x ASA 5520 in Active/Standby state (Routed, Single context) running 8.2(3) image. They are working great and everybody is happy. Now it's time for us to upgrade to the latest and greatest version: 9.1 and as you know there are some architectural changes Cisco made to NAT statements and Access Lists. As one can tell, we have a monster environment in terms of NAT statements and access list that are currently configured on the appliances.
In order to make the upgrade process "less" painful, I was able to find a loaner ASA 5520 device so I can practice the upgrade process offline and if needed, I use it in production (in conjunction with existing Primary and Secondary devices) should it be helpful. I currently don't have any plans on how to move forward with these 3 devices and put together an smooth upgrade. I am asking advice from experts that perhaps have done this in the past and know some Do's and Don’ts and can provide me some options toward getting best result: Minimum downtime and Smooth upgrade.
I appreciate all the help in advance.

Hi,
My personal approach from the start has been to learn the new NAT configuration format on the ASA CLI and manually convert the configurations for the new ASA software. I am under the impression that the automatic conversion that the ASA does by rebooting straight into a new software level causes quite a lot of configurations and they arent really optimal.
In your case it seems that you have a pretty much better situation than most people that dont have the chance to use a test device to test out the setup before actually putting it in production.
What you can basically do is
Insert the 8.2 configuration to the test ASA and boot it straight to the higher software levels and see what the conversion has done to the ASA configurations.
You can use "packet-tracer" command to test if correct NAT rules are still hit after the conversion
So far I have been lucky in the sense that most of the upgrades I have done have involved new hardware which has basically let me configure everything ready and just switch devices for the customer. So far everything has went really well and there has been only a 1-2 mistakes in NAT configurations because of misstyping some IP address or interface name which basically resulted from a lot of copy/paste when building the configurations. And these couple of mistakes have been from around 150 firewall migrations (of which most from FWSM Security Context to a ASA Security Context)
If you have time to put into this then I would suggest you try to learn the new NAT format and write your NAT configurations yourself. Converting the existing configurations should essentially give you the tools to then maintain that firewall configuration easily in the future and apply that knowledge elsewhere.
If you want to read a bit about the new NAT configuration format then I would suggest having a look at the NAT 8.3+ document I made:
https://supportforums.cisco.com/docs/DOC-31116
My personal approach when starting to convert NAT configurations for the upgrade is
Collect all NAT configurations from the current ASA including any ACLs associated with the Policy type NATs and NAT0 configurations
Divide NAT configurations based on type
Dynamic NAT/PAT
Static NAT
Static PAT
NAT0
All Policy Dynamic/Static NAT/PAT
Learn the basic configuration format for each type of NAT configuration
Start by converting the easiest NAT configurations
Dynamic NAT/PAT
Static NAT/PAT
Next convert the NAT0 configurations
And finally go through the Policy NAT/PAT configurations
Finally go through the interface ACLs and change them to use the real IP address as the destination in all cases since the NAT IP address is not used anymore. In most common screnarios this basically usually only involves modifying the "outside" interfaces ACL but depending if the customer has some other links to external resourses then its highly likely that same type of ACL changes are required on those interfaces also.
The most important thing is to understand how the NAT is currently working and then configure the new NAT configuration to match that. Again, the "packet-tracer" command is a great tool to confirm that everything is working as expected.
One very important thing to notice also is that you might have a very large number of Identity NAT configurations between your local networks interfaces of the ASA.
For example
static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0
In the new software you can pretty much leave all of these out. If you dont need to perform NAT between your local interfaces then you simply leave out all NAT configurations.
Naturally you can also use these forums to ask help with NAT configuration conversions. Even though its a very common topic, I dont personally mind helping out with those.
So to summarize
Try out the ASAs automatic configuration conversion when simply booting to new software levels on the test ASA you have
Learn the new NAT configuration format
Ask for help here on CSC about NAT configuration formats and help with converting old to new configurations.
Personally if I was looking at a samekind of upgrade (which I will probably be looking at again soon) I would personally do the following
Convert the configurations manually
Lab/test the configurations on an test ASA
During Failover pairs upgrade I would remove the Standby device from network, erase its configurations, reboot it to new software, insert manually written configurations.
Put the upgraded ASA to the device rack and have cables ready connected to the customer devices if possible (or use existing ones)
Disconnect currently active ASA running 8.2 and connect the new ASA to the network while clearing ARP on the connected routers to avoid any problems with traffic forwarding.
Test connectivity and monitor ASAs connection and xlate tables to confirm everything is working
Will add more later if anything comes to mind as its getting quite late here
Hope this helps
- Jouni

ASA Firewall Upgrade from 8.2,8.4, to 9.0

Dear All ,
we have five firewalls with the following details:
First Firewall
Hardware:   ASA5550, 4096 MB RAM, CPU Pentium 4 3000 MHz, Flash 256MB , BIOS Flash1024KB , ASA IOS 8.4(3) ,Device Manager Version 6.4(7)
    my question can i upgrade ASA IOS 8.4(3) to 9.0 directly without any issues also can i upgrade Device manager 6.4(7) to 7.0 without upgrading the       ASA IOS itself
Second Firewall
Hardware:   ASA5520,2048 MB RAM, CPU Pentium 4 2000MHz, Flash 256MB , BIOS Flash1024KB , ASA IOS 8.2(3) ,Device Manager Version
6.2(3)
my question can i upgrade ASA IOS 8.2(3) to 9.0 directly without any issues also can i upgrade Device manager 6.2(3) to 7.0 without upgrading the       ASA IOS itself
Third Firewall
Hardware:   ASA5520,2048 MB RAM, CPU Pentium 4 2000MHz, Flash 256MB , BIOS Flash1024KB , ASA IOS 8.4(3) ,Device Manager Version 6.4(7)
my question can i upgrade ASA IOS 8.4(3) to 9.0 directly without any issues also can i upgrade Device manager 6.4(7) to 7.0 without upgrading the       ASA IOS itself
Fourth Firewall
Hardware:   ASA5520,2048 MB RAM, CPU Pentium 4 2000MHz, Flash 256MB , BIOS Flash1024KB , ASA IOS 8.4(3) ,Device Manager Version 6.4(7)
my question can i upgrade ASA IOS 8.4(3) to 9.0 directly without any issues also can i upgrade Device manager 6.4(7) to 7.0 without upgrading the       ASA IOS itself
fifth Firewall:
Hardware:   ASA5520,2048 MB RAM, CPU Pentium 4 2000MHz, Flash 256MB , BIOS Flash1024KB , ASA IOS 8.2(3) ,Device Manager Version 6.2(3)
my question can i upgrade ASA IOS 8.2(3) to 9.0 directly without any issues also can i upgrade Device manager 6.2(3) to 7.0 without upgrading the       ASA IOS itself
please help i am doing the upgrading remotely using the ASDM and i don't want to do any upgrade could result disconnectivity.
Best regards

Hi Basel,
Honestly, I wouldn't suggest a direct upgrade from 8.2 to 9.0. This is a *major* upgrade. The recommended path to reach 9.0 would be from 8.2-->8.4-->9.0
Here are the release notes for 9.0:
http://www.cisco.com/en/US/docs/security/asa/asa90/release/notes/asarn90.html#wp690047
Per above document:
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.
Once you are on 8.3/8.4 (I would suggest 8.4 as a lot of issues were fixed post 8.3 as that was a huge transition from 8.2) upgrade to 9.0 is fairly simple.
Major part is upgrade from 8.2 to 8.4 as configuration changes and few things can be broken as a result. I would highly recommend you to check these docs before attempting an upgrade and also do it with some maintenence window so as to correct things in case they broke:
Following doc talks about 8.3 but it is applicable to direct upgrade to 8.4 as well:
https://supportforums.cisco.com/docs/DOC-12690
Release notes for 8.4:
http://www.cisco.com/en/US/docs/security/asa/asa84/release/notes/asarn84.html
Sourav

ASA 5520 upgrade from 8.4.6 to 9.1.2

Dear All,
I am having ASA 5520 in Active Standby failover configuration . I want to know if I can upgrade it from 8.4.6 to 9.1.2 using the zero downtime upgrade process mentioned on cisco site .
Below is the process :
Upgrade an Active/Standby Failover Configuration
Complete these steps in order to upgrade two units in an       Active/Standby failover configuration:
Download the new software to both units, and specify the new image to           load with the boot system command.
Refer to           Upgrade           a Software Image and ASDM Image using CLI for more           information.
Reload the standby unit to boot the new image by entering the           failover           reload-standby command on the active unit as shown           below:
active#failover reload-standby
When the standby unit has finished reloading and is in the Standby           Ready state, force the active unit to fail over to the standby unit by entering           the no           failover active command on the active unit.
active#no failover active
Note: Use the show             failover command in order to verify that the standby unit             is in the Standby Ready state.
Reload the former active unit (now the new standby unit) by entering           the reload command:
newstandby#reload
When the new standby unit has finished reloading and is in the           Standby Ready state, return the original active unit to active status by           entering the failover           active command:
newstandby#failover active
This completes the process of upgrading an Active/Standby Failover       pair.
Also after upgrade are there any changes required after IOS migration ( i.e are there any changes in the command line of 8.4.6 and 9.1.2 )
It is mentioned on cisco site that
Major Release
—You can upgrade from the last minor           release of the previous version to the next major release. For example, you can           upgrade from 7.9 to 8.0, assuming that 7.9 is the last minor version in the 7.x           release.

Hi Tushar,
The steps you mentioned are perfectly fine. There is no major difference in the commands of the 2 versions, it's just that in access-rule from 9.1 you have to any4 instead of any for ipv4 and any6 for ipv6. During conversion it will get convert automatically.
Also, please refer to the following document (release notes of 9.1.2) for viewing the new features added in that version:
http://www.cisco.com/en/US/docs/security/asa/asa91/release/notes/asarn91.html#wp685480
- Prateek Verma

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.

Multiple Vulnerabilities in Cisco ASA Software Upgrade

Hello,
Has anyone upgraded their ASA's IOS to the recommended version as mentioned in this link -->
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20131009-asa?
I have upgrade my 8.2 & 8.6 softwares to the new release versions (as recommended by Cisco), but whenever I use the reload command, my I get the following error:
*** --- START GRACEFUL SHUTDOWN ---
Shutting down isakmp
Shutting down webvpn
Shutting down sw-module
Shutting down File system
*** --- SHUTDOWN NOW ---
Write failed: Broken pipe
Any ideas as to why this is happening and any suggestions to answer this issue?
Thanks,
Arun

We will need to investigate this further.
Allow me sometime or if it is urgent please open a TAC case.
Mike

ASA HA upgrade procedure

Hello,
I'll be upgrading an HA pair of ASA 5520s next week, and wanted to clarify the procedure. I read "Upgrading an Active/Standby Failover Configuration" at http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/admin_swconfig.html#wp1057338 which suggests placing the image on both units, updating boot statements, then issuing failover reload-standby.
But I was wondering if there's a way to a way to be a bit safer. I'd like to modify the standby unit, without affecting the config on the active. So I'd like to modify the boot statement on the standby without modifying the active config. That way incase there's a problem and the active reboots, it won't upgrade.
Can I modify the config on the standby without affecting the active?
Then I'd like to test the newly upgraded unit with our production traffic. Would that simply be no failover active, and then once the standby becomes active -- test traffic?
Once everything is okay, I would upgrade the second unit, and fail traffic back.
Thanks
Bill

Thanks Varun, that worked -- with one small hiccup.
The secondary was running the new version, with the modified boot statement. But while we were working, the primary sync it's config to the secondary, overwriting the boot statement. I thought if the versions were different it wouldn't overwrite the config?
We manually put it back. But is there a way to temporarily stop config sync?
Thanks

ASA firmware upgrade from console - tftp error

Have an asa 5510, trying to upgrade the firmware via console.
I have a tftp program installed on my PC but get an error running the command, any idea what I'm doing wrong?
asa# copy tftp flash
Address or name of remote host [142.xx.xx.xx]? ------------> IP of my PC
Source filename [asa912-k8.bin]?
Destination filename [asa912-k8.bin]?
Accessing tftp://142.xx.xx.xx/asa912-k8.bin...
%Error opening tftp://142.xx.xx.xx/asa912-k8.bin (No such device)

Hi,
You really cant upload files through the Console connection. Its not a network connection.
Your PC might have an IP address configured but that would be configured in its network interface card which has nothing to do with the console cable connection.
So you will have to configure one of the ASAs network interfaces with IP address and other basic settings. Then you need to configure the PCs network interface cards settings to match the IP address/subnet configured on the ASA. Then you will have an connection between the ASA and the PC and should be able to load the software to ASA.
For example
interface Management0/0
nameif management
security-level 100
ip address 10.10.10.1 255.255.255.0
no shutdown
and the configure the PC with IP address 10.10.10.100 and mask 255.255.255.0 for example and then load the software from the PCs IP address of 10.10.10.100.
- Jouni

ASA IOS upgrades

Hi All,
I'm looking for some information and the benefits of others expereince. I'm looking to upgrade 2 ASAs, 5520 & 5510 to IOS Version 8.6(1)2. The ASAs are ASA 5520 Version 8.0(5)
ASA 5510 Version 7.2(4)33
Has anyone taken on such a task?? If so what were the challenges involved with such and upgrade
Lookign forward to any guidance I can get with this.
Thanks
Deena

You can't upgrade the ASA5500 series to version 8.6.x.
Version 8.6.x is meant to be just the new ASA5500-X series.
Here is the release notes for your reference:
http://www.cisco.com/en/US/docs/security/asa/asa84/release/notes/asarn86.html
For the existing ASA5500 series (inc. 5510 and 5520), you can upgrade it to the latest version of 8.4.x.
Pls kindly be advised from version 8.3 onwards, you would need to have the upgraded memory on your ASA, and there are major feature change from version 8.3 onwards (ie: NAT and ACL in particular).
Here is the memory requirement for version 8.3 and above:
http://www.cisco.com/en/US/docs/security/asa/asa83/release/notes/asarn83.html#wp310503
Here is the complete release notse for version 8.3:
http://www.cisco.com/en/US/docs/security/asa/asa83/release/notes/asarn83.html
(Pls check out the new feature section).
And here is the release notes for version 8.4:
http://www.cisco.com/en/US/docs/security/asa/asa84/release/notes/asarn84.html
Hope that helps.

ASA flash upgrade

Never done it before but is there a second slot for internal flash or do you have to get external flash copy the files off and then upgrade the flash and copy back.

Thi might help you:
https://supportforums.cisco.com/message/3533328#3533328
Thanks,
Varun Rao
Security Team,
Cisco TAC

ASA multiple mode upgrade from 8.2.5 to 8.4.5 to 9.0.3

I'm doing ASA code upgrade with contexts from 8.2.5 to 8.4.5 to 9.0.3 and I'm concerned about the NAT syntax with the new code. Should this automatically changed to the new syntax on all contexts or I have to do it manually. Anyone there with that experience, please advise. Thanks.
Please reply to [email protected]
Thanks.

Hello,
I am actually working on a project right now really similar to yours.
When are you planning to perform the Upgrade???
As per Cisco documentation the Upgrade should be done from the system context!
Migration will happen automatically:
I created a post about it
http://www.laguiadelnetworking.com/asa-8-3-upgrade-new-features-known-issues-best-practicesetc/
Enjoy
Rate all of the helpful posts!!!
Regards,
Jcarvaja
Follow me on http://laguiadelnetworking.com

ASA Migration Problems

Hi,
I'm trying to migrate a configuration of an ASA 5520(Version: ASA 8.0(5)) to an ASA 5585 (Version: 8.4(2)). I keep getting some errors which are included below. I've been struggling with these for some copule of weeks and read the documentation on cisco.com (
http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.html) and also some pages on this forum. Some lines are written in bold of which I wasn't able to find any information about. Any help is appreciated. Thanks.
INFO: MIGRATION - Saving the startup errors to file 'flash:upgrade_startup_errors_201203062349.log'
Reading from flash...
!!!!!!!!!!!!!!!!!!!WARNING:
MIGRATION: NAT Exempt command is encountered in config.
Static NATs which overlap with NAT Exempt source are not migrated.
Please check migrated ACLs for accuracy.
WARNING: MIGRATION: Failed to create acl element to track during migration
*** Output from config line 1291, "access-group outside_acc..."
WARNING:
MIGRATION: NAT Exempt command is encountered in config.
Static NATs which overlap with NAT Exempt source are not migrated.
Please check migrated ACLs for accuracy.
*** Output from config line 1292, "access-group inside_acce..."
WARNING:
MIGRATION: NAT Exempt command is encountered in config.
Static NATs which overlap with NAT Exempt source are not migrated.
Please check migrated ACLs for accuracy.
*** Output from config line 1293, "access-group DMZ_access_..."
WARNING: MIGRATION: During migration of access-list <XXXXXXX> expanded
this object-group ACE
permit object-group DM_INLINE_SERVICE_5 XXX 255.255.255.0 DMZnet 255.255.255.0
WARNING: MIGRATION: Failed to create acl element to track during migration
*** Output from config line 1298, "access-group XXXXX..."
ERROR: MIGRATION: No memory to create migrated service-policy element
ERROR: Problem with interface 2
ERROR: MIGRATION: No memory to create migrated service-policy element
ERROR: Problem with interface 3
ERROR: MIGRATION: No memory to create migrated service-policy element
ERROR: Problem with interface 4
ERROR: MIGRATION: No memory to create migrated service-policy element
ERROR: Problem with interface 5
ERROR: MIGRATION: No memory to create migrated service-policy element
ERROR: Problem with interface 6
ERROR: MIGRATION: No memory to create migrated service-policy element
ERROR: Problem with interface 7
ERROR: MIGRATION: No memory to create migrated service-policy element
ERROR: Problem with interface 8
ERROR: MIGRATION: No memory to create migrated service-policy element
ERROR: Problem with interface 9
ERROR: MIGRATION: No memory to create migrated service-policy element
ERROR: Problem with interface 10
ERROR: MIGRATION: No memory to create migrated service-policy element
ERROR: Problem with interface 11
*** Output from config line 1797, "service-policy global-po..."
NAT migration logs:
The following 'nat' command didn't have a matching 'global' rule on interface 'dmz' and was not migrated.
nat (inside) 1 access-list inside_nat_outbound
WARNING: The following identity NAT was not migrated. If required, an appropriate bypass NAT rule needs to be added.
global (outside) 10 interface
nat (inside) 0 logserver 255.255.255.255
WARNING: The following identity NAT was not migrated. If required, an appropriate bypass NAT rule needs to be added.
nat (inside) 0 logserver 255.255.255.255
The following 'nat' command didn't have a matching 'global' rule on interface 'dmz' and was not migrated.
nat (inside) 1 icnetwork 255.255.0.0
ERROR: MIGRATION: No memory to create migrated service-policy element
The following 'nat' command didn't have a matching 'global' rule on interface 'TAV' and was not migrated.
nat (dmz) 1 access-list dmz_nat_outbound
INFO: NAT migration completed.
ERROR: an object-group with the same name (egitim) exist.
WARNING: Failed to create an object for name 'egitim' in the following ACL:
access-list DMZ_access_in extended permit tcp host 9.1.1.90 object-group egitim any

Ummm,
Did you possibly try the default username/password combination? (cisco/cisco) It should then prompt you to change these settings once you gain access. I'm not familiar with how the migration works, if it transitions the user accounts over or you end up starting from scratch. Give that a try and hopefully it gets you into your new system.

ASA 5505 - 2 Internet Connections, Problems with the Default Route

Hey there,
i have a Problem at a Customer Site at the moment. The customer uses an ASA 5505 with two internet connections attached to it. On the first connection (which is the only one in use at the moment) he has some Static-PAT's from Outside to Inside where he translates different services to the internal servers. He also has a site-2-site VPN terminating there and AnyConnect.
He now wants to switch the Internet Traffic from Inside to the new Internet Connection. Therefore changing the default route to that new ISPs Gateway. The problem now is, that no traffic recieved on the old "outside" Interface is transmitted back out of that old "outside" Interface. And this happens although the "same-security permit intra-interface" command is set.
Can you tell me what's wrong here? For every Static-PAT from outside to inside there is also a dynamic PAT from inside to outside. But the ASA seems to ignore this. I have not looked into the Logs yet, was too busy finding the problem because i had no real time window to test on the productive ASA.
Can it be achieved in any way? Having a default route on the ASA which leads any traffic to the second internet connection while still having connections on the first internet connection where no explicit route can be set? Because connections arrive from random IPs?
Many thanks for your help in advance!
Steffen

Phillip, indeed , I have as well read may comments,it all depends on your environment as they all differ from one another, you best bet is to have a good solid plan for upgrade and fall back. You do have a justification to upgrade for features needed, so I would suggest the following:
1- Do a search again in forum for ASA code upgrades and look at comments from users that have gone through this process and note their impact in fuctionality if any. I believe this is good resource to collect information .
2- Very important , look into release notes for a particular version. For example version 8.0, look into open CAVEATS usually at the end of the link page, reading the open bugs gives you clues what has not yet been resolved for that particular code and if in fact could impact you in your environment, it is possible that a particular bug does not realy apply to your environment becuase you have yet not implemented that particualr configuration. Usually we all try to aim towards a GD (General Deployment) code which is what we all understand is most stable but not necesarily means you have to be stack in that code waiting for another GD release, in my personal experience I have upgraded our firewall from 7.2 to 8.0(3) long ago and had no issues, and recently upgraded to 8.0(4)when it was first release in August this year.
Release notes
http://www.cisco.com/en/US/products/ps6120/prod_release_notes_list.html
3- AS a good practice precaution -
a-Backup firewall configs in clear text as well as via tftp code.
b-Backup running code and ASDM version code currently running in firewall.
c- Save the output of " show version " to have as reference for all the feature licenses you currently have running as asll as activation keys - good info to have to compare with after upgrade.
d- Ensure that the code you will be using to upgrade also uses correct ASDM version code.
I think with thorough assesment and preparation you can indeed minimize impact.
Rgds
Jorge

ASA 5505 ISP Failover (PPPoE/DHCP)

Hello,
I have 2 WAN uplinks:
The primary is VDSL (PPPoE) - very fast, and I have a static IP + /29 subnet 'assigned' to me.
The secondary is DSL (DHCP) - slower
What I'm trying to do is setup ISP failover on my ASA 5505 with security plus licence... and the way I have it currently setup 'half-works'. If the primary goes down - the primary route is removed from the routing table and the secondary route is 'inserted'. I have the NATs setup so I have internet access and all seems well. The problem however is when the primary ISP comes online again, the ASA doesn't switch back over. It maintains the backup route until I manually switch it (by temporarily disabling the backup ISP switch port).
This is what I did to configure it:
config t
sla monitor 10
type echo protocol ipicmpecho x.x.x.x interface outside-primary
frequency 5
exit
sla monitor schedule 10 life forever start-time now
track 1 rtr 10 reachability
route outside-primary 0 0 x.x.x.x 1 track 1
route outside-backup 0 0 y.y.y.y 2
nat (inside,outside-primary) after-auto source dynamic any interface
nat (inside,outside-backup) after-auto source dynamic any interface
Have I missed anything? Is there a better way to set this up? I noticed in the ADSM if you edit an interface there seems to be the ability to set tracker IDs, SLA IDs, etc - but couldn't really find anything on google that helped.
Any assistance would be greatly appreciated.
Thanks!
Robert

Hi Robert,
you need this command:
no ip verify reverse-path interface outside_primary
Problem:
SLA monitoring does not work after the ASA is upgrade to version 8.0.
Solution:
The problem is possibly be due to the IP Reverse-Path command configured in the OUTSIDE interface. Remove the command in ASA and try to check the SLA Monitoring.
For reference:
http://www.cisco.com/c/en/us/support/docs/security/pix-500-series-security-appliances/70559-pix-dual-isp.html
https://supportforums.cisco.com/blog/150001
HTH
"Plz don't forget to choose correct answer and rate help full answer "

ASA CX5545 Upgrade Procdures

Similar Messages

Maybe you are looking for