[113256] in North American Network Operators' Group
Re: Verizon EVDO Issues
daemon@ATHENA.MIT.EDU (Robert E. Seastrom)
Thu Apr 9 11:52:37 2009
To: Daniel Senie <dts@senie.com>
From: "Robert E. Seastrom" <rs@seastrom.com>
Date: Thu, 09 Apr 2009 11:45:08 -0400
In-Reply-To: <D026629F-109C-42DE-A38D-A4CCB6F76B74@senie.com> (Daniel Senie's
message of "Thu, 9 Apr 2009 10:31:10 -0400")
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Daniel Senie <dts@senie.com> writes:
> We observe this same kind of behavior with firewalls in the path
> watching for dead sessions they can clean up. Appears they send RSTs
> to both end points when they decide a session has gone away, as
> that'll let end hosts figure it out sooner. Same workaround of turning
> on keep=alives once a minute solves this too. The behavior in the case
> of firewalls makes sense, as state tables have to be cleaned up
> eventually.
While I agree with you that the behavior makes perfect sense, I submit
that the controls are often set improperly (by default or due to
configuration by underskilled technicians) - that is to say, without
taking into account the likely behavior of TCP when the connection is
in fact still open. Consider the default keepalive interval on a
selection of operating systems:
FreeBSD - 7200 seconds:
root@clack [17] # sysctl -a | grep keepidle
net.inet.tcp.keepidle: 7200000
root@clack [18] #
MacOSX - 7200 seconds:
[Superfly:~] root# sysctl -a | grep keepidle
net.inet.tcp.keepidle: 7200000
[Superfly:~] root#
Windows XP - 7200 seconds:
http://support.microsoft.com/kb/314053
(notice a pattern here?)
Seems to me that a well-engineered firewall will have enough memory in
it that (in the application for which it is specified, with
anticipated traffic levels) it doesn't have to be over-aggressive and
try cleaning up flows that haven't seen any traffic in less than, say,
two hours and ten minutes.
-r
