Post mortem - the problem described below appears to lie in the nature of how changes are made and applied. I'm guessing bug.
here are some relevant configs: ------------------------------------------------------- interface ATM0.1 point-to-point description To Host ip address 172.31.250.22 255.255.255.252 ip nat outside ip summary-address eigrp 999 172.31.8.0 255.255.255.0 5 pvc 0/35 encapsulation aal5snap ! interface FastEthernet0 description Remote Site ip address 192.168.0.251 255.255.255.0 ip nat inside no ip mroute-cache speed auto ! ip nat pool sfcccnat 172.31.8.25 172.31.8.250 netmask 255.255.255.0 ip nat inside source route-map sfcccnat pool sfcccnat --------------------------------------------- lets's assume that the access-list is correct. it is, because it's in, running, and there are no reachbility problems. while making the changes, I pasted the new access-list into the router. I then attempted to add the route-map back into the router ( the corrected route-map that referred to the new access-list numbers ) at that point I lose connectivity. I had a co-worker on site, who removed the ip nat outside statement. Then from the central site I repeated my methodology, and had no problem. My suspicion is that the router processes get confused because of the order in which I did things. Oh, I should add that this time I also removed the statement "ip nat inside source etc" before adding in the corrected route-map. In any case, all is well, and I can finally close out this project. Hot dawg!!!!!! This one has been an albatross, having been in implementation for six months. problems with equipment, with DSL lines, and with local admins turning off routers and stashing them in back rooms, not to mention an extranet partner who came in and reconfigured the firewall and generally f****** the original design that they had agreed to in the early stages, has made this one a real bear. word of advice - talk about layer 8 issues first. if layer 8 cannot be solved, layers 1-7 are irrelevant. reload in X - yep - I'll keep that one in the tool chest :-> ""Mark W. Odette II"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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=61301&t=61178 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
