Chuck- What about TFTPing your changes in a "new" startup-config file, then reloading the router. If you are pretty certain your changes won't be bad afterwards, I don't see where you could go wrong. If you do have a programming issue with a route-map or acl, then you definitely are getting to visit the client router in the morning. :)
My mentor has taught me a command that will always save your butt. When making the changes in the fashion you mentioned: 1st command to issue is "Reload in X" ; x=number of minutes specified. If you do this, you won't have to worry about getting locked out over-night. Also, create your new ACLs on the Router BEFORE you doing anything else. This way, you can change the command that implements the new ACL last, and you should be able to re-connect shortly afterwards. I've had fun with this while working on a IOS VPN solution- it was a rude awakening, and I had to call the client office to have them bounce the router that night. -Mark -----Original Message----- From: The Long and Winding Road [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 11:22 PM To: [EMAIL PROTECTED] Subject: The effect of NAT on an interface [7:61178] it's happened twice now, and the policy routing was removed from the interface, so I'm thinking the problem has to be the NAT configuration The problem: remote configuration of a router. Circumstances: remove poorly constructed access-lists. replace them with better constructed access-lists that are also in conformance with a system wide standard numbering convention. Change the route maps to reflect these new access-lists. one access-list determines whether or not a host on the inside can obtain a NAT translation. the other control policy routing inbound on the WAN interface. The process: 1) remove policy routing from the distant end WAN interface 2) delete old access-lists 3) delete old route-maps 4) paste in new access-lists 5) paste in the new route-maps at this point I lose connection with the router. I presume that because policy routing was disabled ( no ip policy route-map etc ) and the router was reloaded before step 2 was taken, that the problem is not with policy routing denying my own access. That leaves NAT. The ip nat outside configured on the WAN link of the remote router was in place. Now I'm racking my brains about this, because I have 9 other sites identically configured, and I configured them remotely, and life was good. Well, I guess I'll be visiting a client site in the morning. sheesh!!!!!!!!!!! -- TANSTAAFL "there ain't no such thing as a free lunch" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=61206&t=61178 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]