[nsp] NAT spiking CPU

[Steve Lim]

Well, the outbound NAT translations are due to request for ports 135, 
445, et al. The router eventually runs out of source ports to open. 
I've found that just filtering those ports inbound on the inside 
interface shortens the NAT table to normal levels, hence allowing my 
router to function normally again. And that also works on routers as 
small as 1600s.

Also, port 512 is also popping up as yet another port with about the 
same request volume as port 135. There's a 'nic vulnerability on port 
512 that I read somewhere.

Bob Collie wrote:

> We're seeing this same trouble with our network and have not yet found a
> way to limit NAT translations.  What we're seeing specifically is that a
> site with a 2610 where we're running NAT gets infected by one of the
> DDOS attacks (be it ICMP, etc.) and the sheer volume of dynamic,
> outbound NAT translations makes the router unusable.  
> 
> Has anyone found a way to limit this?  We tried using CAR but it didn't
> make much of a difference when applied against excessive and randomized
> ICMP traffic.
> 
> -Bob
> 
> -----Original Message-----
> From: Streiner, Justin [mailto:streiner at stargate.net] 
> Sent: Monday, September 08, 2003 12:04 PM
> To: Christopher J. Wolff
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [nsp] NAT spiking CPU
> 
> 
> On Mon, 8 Sep 2003, Christopher J. Wolff wrote:
> 
> 
>>Just ran into an interesting situation where, when the public side of 
>>a NAT connection goes down, the router CPU spikes to 100%, effectively
> 
> 
>>restricting all traffic flow inside the network.  This is a 2611XM 
>>router.  Has anyone seen this happen?  Thank you in advance.
> 
> 
> I've seen things like this happen in the past on a variety of platforms,
> all had CEF or dCEF fully enabled. 6400/NRP2 7507 2650 3640
> 
> To me, it appears that the router can handle NAT without major issues
> until some threshold is crossed.  That could be total number of active
> NAT translations, translations per second, bits/packets per second, I
> don't know.  Below this limit, the router would operate normally, but
> once it was crossed, the CPU would almost immediately spike to near
> 100%, but I recall the amount of time spent handling interrupt requests
> to be fairly low.
> 
> As the opportunity permits, I'm trying to chip away at the NAT issue,
> but it's pretty slow going...
> 
> jms
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 

-- 
<><><><><><><><><><><><><><><><><><><><>
Steve Lim - Network Engineer (Michigan)
Corecomm -An ATX Communications Company
On God's keyboard, he has a "Smite" button
-limmer