Does anyone have any idea what the prefix-length argument is for in the NAT pool command?
It does NOT seem to affect the pool size.
For example I have in production:
ip nat pool POOL.source.1 11.28.2.1 11.28.2.1 prefix-length 30 ip nat pool POOL.source.2 11.28.2.2 11.28.2.2 prefix-length 30
ip nat inside source list ACL.NAT.1 pool POOL.source.1 overload ip nat inside source list ACL.NAT.2 pool POOL.source.2 overload
The "30" is the minumum acceptable prefix-l.
These are correctly treated as two seperate pools each with one address. I get the translations that I expect.
CCO has this:
formatting link
"prefix-length Number that indicates how many bits of the netmask are ones (how many bits of the address indicate network). Specify the netmask of the network to which the pool addresses belong."
And what good does that do? Which network _are_ they in and who cares?
The router has three basic jobs with respect to NAT.
It has to translate the forward traffic, replacing the untranslated address with the translated address and creating/updating a NAT connection context.
That task does not involve a netmask.
It has to untranslate the reverse traffic, replacing the translated address with the untranslated address, consulting the NAT connection table in order to do so and to know whether to do so.
That task does not involve a netmask.
If a NAT address falls within within the address space belonging to a connected Ethernet interface, the router will ARP for the NAT address on that interface. [In the wrong vrf, but that's a different story].
That task need not involve a netmask. [And should be suppressable, but I digress again]
A /31 is the smallest network with more than one IP address in it. A /32 is the smallest network with at least one IP address in it.
Both are valid pool sizes. Both are valid prefix lengths in an IP routing table. There's nothing special about the "all zeroes" NAT address or the "all ones" NAT address in a pool.
You're likely correct that this is the motivation for that restriction. But it's a pretty silly motivation.
Even prior to CIDR, netmasks depended on context. The netmask on an interface will not match the netmask in all the routing tables on all the other routers on the network. And when there is no relevant interface, what then?
So, which netmask is it?
The netmask on the connected interface to which the NAT pool addresses would belong if they were real addresses, if there were such an interface and if it were unique?
The netmask on the narrowest containing route that points to the NAT pool addresses, assuming that such a route exists and is unique?
The netmask on the summary route that would be advertised to the adjacent routers that are generating traffic addressed to the NAT pool if those routers in fact needed such a summary route and further assuming that such routers even exist?
replying to Bod43, Adriano epifas wrote: Almost 9 years late to this post but here it goes in a nutshell.
prefix-length and netmask arguments are just sanity checks. you could assign a nat pool like 100.100.100.0-100.100.100.255 but there could be issues if you got IPs .0 or .255 because they are network id and broadcast id. But if you use arguments prefix-length or netmask, those two ip addresses would never be mapped.
So, arguments prefix-length and netmask prevent network id and broadcast address from being mapped.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.