INFO: MIGRATION - Saving the startup errors to file 'flash:upgrade_startup_errors_201304052222.log'
Reading from flash...
!!!!!!!!
REAL IP MIGRATION: WARNING
In this version access-lists used in 'access-group', 'class-map',
'dynamic-filter classify-list', 'aaa match' will be migrated from
using IP address/ports as seen on interface, to their real values.
If an access-list used by these features is shared with per-user ACL
then the original access-list has to be recreated.
INFO: Note that identical IP addresses or overlapping IP ranges on
different interfaces are not detectable by automated Real IP migration.
If your deployment contains such scenarios, please verify your migrated
configuration is appropriate for those overlapping addresses/ranges.
Please also refer to the ASA 8.3 migration guide for a complete
explanation of the automated migration process.
INFO: MIGRATION - Saving the startup configuration to file
INFO: MIGRATION - Startup configuration saved to file 'flash:8_2_5_0_startup_cfg.sav'
*** Output from config line 4, "ASA Version 8.2(5) "
timeout floating-conn 0:00:00
^
ERROR: % Invalid input detected at '^' marker.
*** Output from config line 421, "timeout floating-conn 0:..."
<--- More ---> WARNING: crypto map has incomplete entries
*** Output from config line 502, "crypto map outside_map i..."
WARNING: This command will not take effect until interface 'inside' has been assigned an IP address
*** Output from config line 550, "ssh 0.0.0.0 0.0.0.0 insi..."
no call-home reporting anonymous
^
ERROR: % Invalid input detected at '^' marker.
*** Output from config line 648, "no call-home reporting a..."
NAT migration logs:
nat (inside) 3 192.168.177.22 255.255.255.255
nat (inside) 1 0.0.0.0 0.0.0.0
nat (inside2) 1 192.168.190.0 255.255.255.0
nat (wireless) 1 192.168.199.0 255.255.255.0
nat (dmz) 2 192.168.187.0 255.255.255.0
<--- More ---> INFO: NAT migration completed.
Real IP migration logs:
No ACL was changed as part of Real-ip migration
ASA#
I talked to Cisco TAC about this, as Im just not ok with something they say should work and doesnt. They ended up coming back to me and telling me that this dealt with two bugs. Below is what they are:
CSCtf57830 - Incorrect real ip translation of ACE after 8.3.1 upgrade
CSCue11738 - this one is not visible to the customers.
So the solution was to scramble as fast as I could to get the ACLs to point to the internal address instead of the external address that they referred to. Once I did that, everything was back up again.
Hi Shane,
ReplyDeleteJust curious from pre8.3 to 8.3 above version, do i need to config "no name" and "no nat-control" in pre8.3 startup config before migrate to 8.3above version?
Yes, you are correct Tommy. I think I read that in the release notes, and I do remember that. Good point and thanks for mentioning that. So yes, make sure you run these two commands before the upgrade. However, just remember one thing about names. If you do 'no names', which the release notes say you need to do before the upgrade, think about how that will affect your ACLs/NAT/ect. I personally do not use names at all, this being one of the reasons. If I run into that situation, I always replace the names with the actual IP addresses/range in the ACL/NAT statements, or where ever they are. Ive never tried to not replace them (names), but I always fear what might happen if I dont replace them and leave the names in the ACLs. With that said, Ive also never talked with anyone who has done an upgrade without changing the names to IPs. It may be just fine. However, Im not one to take a chance like that. Ive seen upgrades go bad for other reasons, and I just dont like throwing that into the mix. Thanks for bringing these two points up. Certainly do the "no names" and "no nat-control".
Delete!!!
ReplyDelete