[c-nsp] help on NAT rate limiting

[Ted Mittelstaedt]

> -----Original Message-----
> From: Daniel Hagerty [mailto:hag at linnaean.org]
> Sent: Wednesday, December 29, 2004 2:05 PM
> To: Ted Mittelstaedt
> Cc: hag at linnaean.org; Church, Chuck; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] help on NAT rate limiting
> 
> 
> [ Apologies in advance. ]
> 
>  > From: "Ted Mittelstaedt" <tedm at toybox.placo.com>
>  > Date: Wed, 29 Dec 2004 02:33:18 -0800
> 
>     I do not appreciate you putting words in my mouth as you did, on a
> public mailing list no less. 

Daniel, hold on there.  I didn't put words in your mouth - I questioned
the implication you made in your post that a long timeout should be
standard.  I believe your exact words were "speak for yourself please"
this implies that only -I- am out there bitching about this change.

Since both our posts, James Edwards posted the same complaint I
did, followed by Rodney posting that the agressive timer when
a close happens was changed.  So with the benefit of hindsight
I can safely say I'm speaking for more than myself.

Now, if as your saying here, you -don't- advocate for a long 
timeout for 'the entire internet' then I apologize for assuming
that you were.

> Polite people apologize for such
> behavior.  You said you couldn't understand any reasons for the
> "absurd" default, and I gave you some.
>

My exact statement was:

"I understand that in some situations that you can benefit from disabling
keepalives."

I have a feeling you didn't read my post completely.  This is
probably my fault for the rather harsh tone I used - but this is
a problem that has caused a couple of our customers pain, who
have caused me pain.  I'm rather appalled that as James said
this has gone on for 12 iterations of IOS!
 
>     I'm pretty sure that the TCP session timeout defaulted to 24
> hours, with teardown mitigitation.  I can personally speak for as far
> back as early 12.2, if not 12.1.  So while I don't necesarily advocate
> that the entire internet should use a 24 hour tcp timer (I never said
> that I did), those of you with cisco based nats already are.  How do
> you explain those TCP sessions on your 12.2 boxes with 24 hour
> connection timers on them?
> 

Your right, I see the same 24 hour timers on older IOS boxes.  But
there is an important difference - very very few dynamic sessions
have a timer at 24 hours.  In fact, only the dynamic sessions that
haven't got a RST/FIN have such long timers and you almost never
see any of those unless, of course, there's a worm.

With the 12.3 IOS, just about every dynamic TCP session in the
list has a 24 hour timer on it.

> 
>     I dimly remember upping timers on boxes from 24 to 72 hours at the
> request of myself and two other (ab)users at the site in question who
> tended to have the similar usage of disabling keepalives for some
> connections.  Nothing even approaching memory pressure under what
> would have been 12.2.x and probably pixos late 5 something.  I know
> for sure that they were garbage collecting normally terminated TCP
> connections.  Not counting your worm traffic, I would guess the load
> being moved was similar to the particular case you're having problems
> with.
>

Like I said I don't have an objection to allowing someone to kludge up
their router if they want.  But something is wrong when you go from
an average of 2-300 TCP translation entries in a router under IOS 12.2
or lower, with timeout timers running around 20 minutes or less, to
20,000 TCP translation entries with timeout timers running at 
somewhere under 24 hours, under IOS 12.3, in the same environment.

And something is even more wrong that nothing has been done about it
for 12 iterations of IOS.

Ted