The quick answer (from a thread from way back) is that the following
command will set the TIME_WAIT to 60 seconds for Linux 2.2 kernels:
echo 1 > /proc/sys/net/ipv4/tcp_rfc1337
Brian O'Keefe (brianok@us.ibm.com)
IBM Transarc Lab, Pittsburgh, PA
Alex Rousskov <rousskov@measurement-factory.com> on 09/27/2000 11:57:32 AM
To: "Steven R. Breistein" <breitstein@lucent.com>
cc: polygraph@ircache.net
Subject: Re: msl_test
On Tue, 26 Sep 2000, Steven R Breitstein wrote:
> This posting reminded me of that other msl experience we had in
> Houston last week. As promised, I am sending a link to the newgroup
> thread where a near identical problem was seen (and apparently
> resolved) on a linux platform. Hope this contributes to the general
> understanding of the phenomenon. Steven
>
>
http://x54.deja.com/[ST_rn=ps]/getdoc.xp?AN=568078296&search=thread&CONTEXT=969553503.1684930573&HIT_CONTEXT=969553463.1684865033&HIT_NUM=21&hitnum=0
Steven,
As far as I can tell, the posting investigates a [minor] Linux
TCP stack bug that leads to 2-second TIME_WAIT values under certain
conditions. The thread has a patch that fixes the bug. So it looks like
msl_test was correct in reporting 2 second TIME_WAIT for the Linux
person who opened the fa.linux.kernel thread.
I believe that the strange behavior we have seen during the
cache-off is not related to the above thread: The caches in question
were running FreeBSD rather than Linux and the 2-second TIME_WAIT value
was due to ARP(?) problems on the cache. Same reported value, different
cause. As you know, we've got the correct measurement of 60 seconds when
using Polygraph aliases rather than the monitoring station IP address.
The above URL may be of interest to those who have problems with
msl_test in Linux environment.
Thank you,
Alex.
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:15 MDT