High memory with extended PAT on ASA

Cisco responded to the IPv4 shortage with a clever approach: Extended PAT. But it has drawbacks when used in real 

From NAT to CGN

Classical NAT does use a different port number on the global site for each connection. This allows to map other external sources to reach the same internal host. If such additional mappings are generally allowed it is called "Cone NAT". Otherwise "Restricted NAT". Even in "Restricted NAT", the mapping can be allowed if approbriate protocol helpers are in action.

Extended PAT does allow a port number of a NAT global address to be reused for multiple connections, i.e. different internal clients, as long as they try to reach different external addresses. So you can map much more than 60000 connections to a single public address. For CGN that means you can add an order of magnitude more customers to the same pool of public addresses than before.

Of course extended PAT does not allow any kind of additional mappings. Cisco describes clearly which protocol helpers will not work anymore.On the other hand, the port mappings become more sticky, so there is a much greater chance to get the same global port as used internally. Using round robin pools help a lot to further increase this chance. A lot of port-sensible protocols does benefit from this port stickyness.

Practical Issues

After running extended PAT for a few days, the system was going to collaps today. Memory is running short:


The config was changed two and a half days ago and started to consume memory quickly. After putting more and more customers on the platform the memory run out this afternoon.

Cisco troubleshooting hints does not help much: "During normal operation, the free memory on the ASA should change very little, if at all. Typically, the only time you should run low on memory is if you are under attack and hundreds of thousands of connections go through the ASA."

There are not an unusual amount of connections. But even "show memory" and "show blocks" does not reveal more than the usual memory footprint. A memory leak?

No, the extened NAT does require more (and dynamically more) memory, because it depends on the number of possible ports (number of IPs in the round robin pool mulitiplied by the number of ports usable) times the number of used destinations. That's a huge number.

So reverting the "extended" and "round-robin" entries results in instant solution ...The free memory jumps back to the typical value.

Problem solved.

Steve 13/03/2021 2:51 am
Appreciate this is an old article. Your chart seems to infer as much as 1.6-1.7Gbit of memory was consumed by extended NAT, do you recall how many total connections / NAT translations / end Users you were supporting? Really struggling to find any detailed scalability information for extended NAT. Thanks.

Total 1 comments

Post a comment

Related content