cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2320
Views
0
Helpful
1
Replies

post 8.2.4 - 8.4.1 migration nat verification needed

daniel.litwin
Level 1
Level 1

Migrated our ASA5510 from 8.2.4 to 8.4.1 code over the weekend.

migration seemed to work fine.  I made sure to issue the no nat-control statement prior to upgrading.

here is part of the 8.2.4 config that includes the only nat statement

8.2.4:

global (Outside) 1 interface
nat (inside) 1 10.0.0.0 255.0.0.0
access-group outside_access_in in interface Outside
access-group inside_access_in in interface inside

after migration to 8.4.1

object network obj-10.0.0.0
nat (inside,Outside) dynamic interface
access-group outside_access_in in interface Outside
access-group inside_access_in in interface inside

and here is the upgrade_startup_errors log file:

INFO: MIGRATION - Saving the startup errors to file  'flash:upgrade_startup_errors_201104162230.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_4_0_startup_cfg.sav' *** Output from config line 4,  "ASA Version 8.2(4) " WARNING: MIGRATION: During migration of access-list  expanded this object-group ACE permit tcp host 66.199.195.217  host 66.199.193.22 object-group DM_INLINE_TCP_1 *** Output from config line 184,  "access-group outside_acc..." NAT migration logs: The following 'nat' command  didn't have a matching 'global' rule on interface 'inside' and was not migrated.  nat (inside) 1 10.0.0.0 255.0.0.0 INFO: NAT migration completed. Real IP  migration logs: ACL has been migrated to real-ip version

I am just making sure that the upgrade went correctly.  I am not sure how to read the output in the log file.

Thanks.

Dan

1 Accepted Solution

Accepted Solutions

Shrikant Sundaresh
Cisco Employee
Cisco Employee

Hey Dan,

Let's analyze the log line by line:

INFO: MIGRATION - Saving the startup errors to file  'flash:upgrade_startup_errors_201104162230.log

The startup errors have been saved on the flash in that file.


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.

Explanation: In 8.3 and above, the access-lists use the real ip values, rather than the translated ip addresses. However, for per-user ACLs, you would need to use the original ACL. So basically, the Access-list conversions take place for Access-lists in use by the 4 commands mentioned in line 1. If one of those access-lists is also being used by a per-user ACL, then you would need to create a new access-list and then assign the new name, since the original ACL got converted to real-ip addresses.

Analysis: If you have per-user ACL' s that were being used in one of those 4 commands, then you need to look into the config. Else it would be fine.

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.

Explanation: The Migration process is on a best effort basis, and does not consider weird configurations such as "identical IP addresses or  overlapping IP ranges on  different interfaces."

Analysis: If your IP addressing scheme is distinct on each interface, then there is no reason for you to worry.

*** Output from config line 4,  "ASA Version 8.2(4) "

Explanation: The current version is 8.4(1), hence it threw an exception here when applying the config.

Analysis: Nothing to worry. Happens during every upgrade.

WARNING: MIGRATION: During migration of access-list  expanded this  object-group ACE permit tcp host 66.199.195.217  host 66.199.193.22  object-group DM_INLINE_TCP_1

Explanation: The DM_INLINE_TCP_1 was expanded, and thus this 1 Access-list Entry (ACE) would have been split into X ACEs, where X is the number of objects in that object-group.

Analysis: Nothing to worry. Your "show run access-list" will show all entries with ports instead of 1 with object group. If required, you can configure it back to what it was.

Output from config line 184,  "access-group outside_acc..."

Analysis: Not sure what this is. Did you truncate this part of the log file, or this was how it was shown?? Just see in the "show run access-group" if the access-list is applied to the outside. If it is, then nothing to worry.


NAT migration logs: The following 'nat' command  didn't have a matching  'global' rule on interface 'inside' and was not migrated.  nat (inside) 1  10.0.0.0 255.0.0.0

Explanation: In your previous config you had the above nat command, but no "global(interface_name) 1" command, thus rendering the "nat (inside) 1" useless. Thus the "nat (inside) 1"  could not be, and hence was not, migrated.

Analysis: Nothing to worry.

So that's about it. I think everything should be fine. Don't really see any problem areas.

Best way to know if everything is working fine, is if no one at the site is complaining.

Hope this helps.

-Shrikant

P.S.: Please mark the question as resolved, if it has been answered. Do rate helpful posts. Thanks.

View solution in original post

1 Reply 1

Shrikant Sundaresh
Cisco Employee
Cisco Employee

Hey Dan,

Let's analyze the log line by line:

INFO: MIGRATION - Saving the startup errors to file  'flash:upgrade_startup_errors_201104162230.log

The startup errors have been saved on the flash in that file.


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.

Explanation: In 8.3 and above, the access-lists use the real ip values, rather than the translated ip addresses. However, for per-user ACLs, you would need to use the original ACL. So basically, the Access-list conversions take place for Access-lists in use by the 4 commands mentioned in line 1. If one of those access-lists is also being used by a per-user ACL, then you would need to create a new access-list and then assign the new name, since the original ACL got converted to real-ip addresses.

Analysis: If you have per-user ACL' s that were being used in one of those 4 commands, then you need to look into the config. Else it would be fine.

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.

Explanation: The Migration process is on a best effort basis, and does not consider weird configurations such as "identical IP addresses or  overlapping IP ranges on  different interfaces."

Analysis: If your IP addressing scheme is distinct on each interface, then there is no reason for you to worry.

*** Output from config line 4,  "ASA Version 8.2(4) "

Explanation: The current version is 8.4(1), hence it threw an exception here when applying the config.

Analysis: Nothing to worry. Happens during every upgrade.

WARNING: MIGRATION: During migration of access-list  expanded this  object-group ACE permit tcp host 66.199.195.217  host 66.199.193.22  object-group DM_INLINE_TCP_1

Explanation: The DM_INLINE_TCP_1 was expanded, and thus this 1 Access-list Entry (ACE) would have been split into X ACEs, where X is the number of objects in that object-group.

Analysis: Nothing to worry. Your "show run access-list" will show all entries with ports instead of 1 with object group. If required, you can configure it back to what it was.

Output from config line 184,  "access-group outside_acc..."

Analysis: Not sure what this is. Did you truncate this part of the log file, or this was how it was shown?? Just see in the "show run access-group" if the access-list is applied to the outside. If it is, then nothing to worry.


NAT migration logs: The following 'nat' command  didn't have a matching  'global' rule on interface 'inside' and was not migrated.  nat (inside) 1  10.0.0.0 255.0.0.0

Explanation: In your previous config you had the above nat command, but no "global(interface_name) 1" command, thus rendering the "nat (inside) 1" useless. Thus the "nat (inside) 1"  could not be, and hence was not, migrated.

Analysis: Nothing to worry.

So that's about it. I think everything should be fine. Don't really see any problem areas.

Best way to know if everything is working fine, is if no one at the site is complaining.

Hope this helps.

-Shrikant

P.S.: Please mark the question as resolved, if it has been answered. Do rate helpful posts. Thanks.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card