IP NAT pool overload misses- how to correct?

[nate.miller]

I've got a 2600 series router running 12.2(19a) that I'm trying to establish a dynamic NAT pool on, but whenever I attempt to make the connection, I get misses- which indicate "failure to allocate an address". I'm not sure why this would be happening on an overloaded pool.

This router has a VPN set up on the WAN interface, which is also the nat outside interface.

The LAN interface is the nat inside interface. I have 10 static NAT entries that are working properly across the router, so I don't believe it to be an IPSec issue.

I'm getting matches on the access list for the nat pool, so that appears to be correct.

The traffic being sent over this connection is FTP traffic- there did appear to be some issues with this in earlier versions, but those issues said they were resolved in 12.1(4), I think...

====

ip nat pool test 10.0.0.254 10.0.0.254 prefix-length 32

ip nat inside source list 70 pool test overload

access-list 70 permit 192.168.1.1

====

Statistics for the access list show hits.

====

Standard IP access list 70

permit 192.168.1.1 (20 matches)

====

sh ip nat statistics shows :

===

[Id: 1] access-list 70 pool test refcount 0

pool bisysftp: netmask 255.255.255.255

start 10.0.0.254 end 10.0.0.254

type generic, total addresses 1, allocated 0 (0%), misses 19

====

I don't know if I'm nothing but a "clear ip nat trans *" away from fixing this, but this router's in a production environment, and I have to submit change orders in order to run even this simple of a command... so I'm trying to figure out exactly what the issue so I can get it resolved with a minimum of trouble.

[dbellaze]

I think that the problem is with your access list. Are you wanting to permit a host or a range of addresses?

If its not just for host 192.168.1.1, then I would make sure your ACL looks like this assuming a /24 mask

access-list 70 permit 192.168.1.0 0.0.0.255

Daniel

[nate.miller]

Right now it's just a host- there will be more devices added to this list in the future, so this access list is our attempt at keeping this extensible- adding the devices that need only inbound access to the ACL, rather than burning up static mappings for each new device. (The static mappings work right now.)

The ACL shows hits, which make me think it's not the fault of the ACL- the single device in the ACL is currently unable to FTP through this router though- we keep getting misses from the NAT pool. I can't find many instances of misses in this regard, so I'm kind of drawing a blank as to how to remedy this.

[dbellaze]

That is odd. Just curious, but what if you change the prefix on the nat pool.

Daniel

[nate.miller]

That's my first plan of attack- but right now the lab I have access to is dismantled, and I can't make the changes in production, so I'm a few days off of being able to play with it. I was hoping that maybe somebody would be able to point out something glaringly wrong with the config.

The fact that when running with a /32 and the overload statement the NAT pool is correctly identified as having 1 valid address makes me think it _should_ work. But I'm feeling pretty restrained in my abilities to play with this and make it work...

[dbellaze]

Nate,

It might just be a problem with this particular configuration. It is technically a one to one NAT but using a nat pool.

What if you change the ACL to permit a few hosts so that it changes from a host to range ACL.

So some thing like this.

access-list 70 permit 192.168.1.0 0.0.0.3

Basically all I am saying is the IOS might be having a hard time with it being a host in the ACL instead of a range. The idea with pools is to do multiple IP's to one IP.

Daniel

[nate.miller]

But the ACL is only going to present one address to the NAT pool at a time, right? (I realize that with the overload there will most likely be several devices using the same address simultaneously, but the router _should_ be completely unaware of how many devices are in the ACL- it should just be presented with an address that it's told is OK to NAT, and then run from there?

The ACL seems works fine, so I'd think that if there were any issues with that, they'd generate misses elsewhere. The NAT pool should regard the ACL as a black box- it can't tell what's in there, it just works on the one address it's been presented with. That's the way I'm mentally block diagramming it, at least.

I'll play around with that as well when I get into Lab. Thanks for the suggestion.

[nate.miller]

The problem ended up being the 'prefix length' portion of the command.

Prefix-length is only used as a 'sanity check', as per cisco. If you enter a beginning address that have a .0 and an ending address that has a .255, with a prefix-length of 24, it won't hand out .0 or .255. Meanwhile, if you have a prefix-length of /16, it _would_ hand those addresses out, as appropriate.

When entering this command with a /32, an error/warning message was generated to the console- something to the effect of "32 is too large of a prefix length. Use a 30 prefix length or smaller." However, the command was accepted into the running config. I can then change it to a /30, and my misses disappear and everything started to work posthaste.

When cut and pasting a large config into a router, it was difficult to see that single error message pop up .

I probably won't forget that one again.