My understanding is that you should not think of ip nat enable as the new way, and hence preferential. It is much more limited I believe in how and when you can use it. I think it was created to address the need for directionless nat. I.e don't label up an inside/outside. For example when an interface would be required to be both, or when trying to nat through a Loopback etc.
For everything else I use vanilla ip nat inside and all the options it brings. ? Sent from my iPhone On 10 Apr 2011, at 21:37, Max Pierson <[email protected]> wrote: > Hi Jay, > > I got a offline response from someone with the same issue on that exact IOS, > only a different platform. ZFW seems to work perfectly if I remove NAT, so > I'll just move to another release when I get time and check out the Bug > Toolkit to see what shows up. Just wanted to see if anyone else has seen > this since this is what we use in our labs .... hate running up against bugs > while studying ... if infact this is a bug :) > > Thanks, > M > > On Sun, Apr 10, 2011 at 7:38 AM, Jay Taylor <[email protected]> wrote: > >> I'm no ZBF expert but I do remember hearing that 'ip nat enable' is not >> compatible with it. Not sure about the other issue you're seeing. >> >> On Sat, Apr 9, 2011 at 1:50 PM, Max Pierson <[email protected]> wrote: >> >>> Hi List, >>> >>> I'm testing out ZFW on a 3725 router and noticed some strange behavior of >>> NAT when I perform testing. It seems when I overload the "outside" >>> interface >>> or pool, the first packet gets dropped as if there's no translation >>> already >>> built for the session. Even if I remove all of the ZFW config and just >>> have >>> the NAT config in place, I still see the same issues. I DO see the NAT >>> session created in a "show ip nat trans", however, the first packet out of >>> any session created is dropped. Once TCP sessions (ex. web download) are >>> established after a few drops, the performance is fine. It's just when >>> that >>> first packet hits the interface is when I'm seeing the flakiness. To make >>> sure it wasn't my config, I removed all of the ZFW config, and loaded >>> 12.4(25d), and the config works as expected. Relevant configs are below. >>> >>> Also, should I use the "ip nat enable" method instead of the old method I >>> am >>> using?? And if so, can someone explain or link me to the info as to when >>> to >>> use it vs the old method?? Or is this possibly a bug I'm hitting since >>> this >>> works fine in 12.4(25d) mainline?? >>> >>> ! >>> interface FastEthernet0/0 >>> ip address 192.168.35.253 255.255.255.0 >>> ip nat inside >>> ip virtual-reassembly >>> ip route-cache flow >>> load-interval 30 >>> duplex auto >>> speed auto >>> ! >>> interface Serial0/0 >>> ip address 172.16.0.1 255.255.255.252 >>> ip nat inside >>> ip virtual-reassembly >>> ip route-cache flow >>> load-interval 30 >>> ! >>> interface FastEthernet0/1 >>> ip address 206.XX.XX.XX 255.255.255.252 >>> ip nat outside >>> ip virtual-reassembly >>> ip route-cache flow >>> load-interval 30 >>> duplex auto >>> speed auto >>> ! >>> ! >>> ip nat pool OUTSIDE 206.XX.XX.XX 206.XX.XX.XX netmask 255.255.255.252 >>> ip nat inside source list NGA-NETS pool OUTSIDE overload >>> ! >>> ip access-list extended NGA-NETS >>> permit ip 192.168.32.0 0.0.7.255 any >>> permit ip 172.16.0.0 0.0.0.255 any >>> >>> Thanks, >>> Max >>> _______________________________________________ >>> For more information regarding industry leading CCIE Lab training, please >>> visit www.ipexpert.com >>> >> >> >> >> -- >> >> Jay Taylor >> CCIE #28391 >> @JTIE_6EE7 >> >> >> > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
