Re: Masquerade: Any large network limits?

Janos Farkas (Janos.Farkas-nouce/priv-#yFQGGyHTQ3aqEHD4V9FVk53CC84@lk9qw.mail.eon.ml.org)
Thu, 1 Jan 1998 21:35:49 +0100


On 1998-01-01 at 16:46:27, Nigel Metheringham wrote:
> Kernels pre 2.0.31 exhibited very poor new connection performance
> when most of the masq slots were used - some connections could even
> be refused. The newest version are better, but not brilliant.
>
> Each connection has a timeout associated with it. The connections
> are not torn down until the timeout has expired (although it is
> reduced at TCP FIN, and set to near zero on TCP RST). This means
> that lots of short connections (ie www connections) load much more
> heavily than long lived connections since you are waiting for old
> ones to die. You could tweak the timeouts to cope with this.

Hmm. For TCP masquerading, how about using TCP "keepalives" (to the
masqueraded host) to check if the connections are still there? I.e.
after say each expire_time/3, if no traffic, mark the masqueraded
connection as being checked, and send a simple TCP ack to the
"internal" host; and let a single pure ack reset the counter, and the
"checking" state, without forwarding the ack.

This could solve the ftp command channel expiration problem in a less
hacky way, and provide a way for working long-living connections with
few data. Maybe then there would be no need to hand-tune the timeout
in many cases. (And it could be small enough to provide advantage in
the common case of a fast LAN where the TCP keepalive probes should be
more bearable.)

This helps nothing for UDP, agreed. But, for DNS, I'd use transparent
redirect to a small named helper (only needed if the clients' resolver
checks the source of the reply packet).

-- 
Janos - Don't worry, my address is real.  I'm just bored of spam.