[c-nsp] Question about NAT Rate Limiting

[Rodney Dunn]

If you were seeing high CPU with NAT ager with the
new NAT code is very likely you are hitting:

CSCef58137
Externally found catastrophic defect: Resolved (R)
IP NAT crash ipnat_free_nat

Rodney


On Fri, Nov 19, 2004 at 03:58:31PM -0800, Kevin Graham wrote:
> On Tue, 16 Nov 2004 20:42:35 -0600, Church, Chuck <cchurch at netcogov.com> wrote:
> > This can probably save many a router from running out of RAM when the next big
> > MS worm gets on an internal PC.
> 
> Being able to have a rotary overload pool would likely help as well.
> In doing some high-volume NAT tests (w/ the 12.3(4)T enhancements ..
> which are broken in 12.2(25)S), CPU utilzation from the NAT ager was
> the major limitation (>20% and eventually spiralling out of control).
> Moving to non-overloaded, NAT Ager would stay below 2%. Since there's
> still per-connection entries created, the disparity was somewhat
> suprising. Not sure if this is because the ager is more efficient when
> connections are spread out across multiple addrs, or if overload'ing
> really does increase the workload that substantially.
> 
> Whatever the cause, being able to do a PAT-fallback when a pool is
> exhausted (ala example PIX configs) so that non-overloaded pools could
> be used safely when clients > pool would be a huge boost in NAT
> scalability (particurally in those worm scenarios).
> 
> Haven't experimented w/ sepecifying multiple pools w/ the same
> list/route-map, but given the lack of prioritization, I don't see how
> this could work in present code..