What is NAT pool "prefix-length" for?

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."

Reply to
Bod43
Loading thread data ...

The same thing that "netmask" does, it identifies the network that the pool addresses are in.

Of course not, the start and end addresses defines its size.

Both identifying the 11.28.2.0/30 network.

Probably cause a /30 is the smallest 'network' with more than one IP address in it (usually a 'pool' has more than one address).

Is there something that is unclear in that description?

Reply to
Rod Dorman

It is unclear where and when the mask might be used?

It makes no sense to me at all.

As far as I understand NAT there is no requirement for the NATter to be aware of any netmask relating to the NAT process.

I can only imagine that it is a decorative entry in the config.

Reply to
Bod43

And what good does that do? Which network _are_ they in and who cares?

The router has three basic jobs with respect to NAT.

  1. 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.

  1. 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.

  1. 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?

Something else?

Reply to
briggs

This may be off topic but similar issues occur on the FWSM/PIX. We have these NAT and PAT entries:

global (Link) 10 xxx.yyy.254.1-xxx.yyy.255.247 netmask 255.255.254.0 global (Link) 10 xxx.yyy.255.254 netmask 255.255.254.0

and this OSPF entry (we run OSPF on the FWSM):

network xxx.yyy.254.0 255.255.254.0 area 426

The prefixes that get advertised are:

6500sup>sh ip route xxx.yyy.254.0 255.255.254.0 longer-prefixes : : xxx.yyy.255.0/24 is variably subnetted, 6 subnets, 6 masks O xxx.yyy.255.128/26 [110/11] via ww.xx.yy.zz, 7w0d, Vlan426 O xxx.yyy.255.192/27 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.255.224/28 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.255.254/32 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.255.240/29 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.255.0/25 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 xxx.yyy.254.0/24 is variably subnetted, 8 subnets, 8 masks O xxx.yyy.254.128/25 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.254.16/28 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.254.4/30 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.254.1/32 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.254.2/31 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.254.8/29 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.254.32/27 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426 O xxx.yyy.254.64/26 [110/11] via,ww.xx.yy.zz 7w0d, Vlan426

Trying to generate a summary in OSPF on the FWSM doesn't have any effect.

Thankfully these get aggregated into a larger prefix in BGP but it's galling to have to

Reply to
Sam Wilson

Sorry, that one got away before I'd finished the thought. Galling not to be able to announce a sensible aggregate from the FWSM.

Sam

Reply to
Sam Wilson

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.

Reply to
Adriano epifas

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.