LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: question about "ip_masq.c"

To: Wayne <wayne@xxxxxxxxxxxxxxx>
Subject: Re: question about "ip_masq.c"
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Sat, 20 Oct 2001 00:48:20 +0000 (GMT)
        Hello,

On Fri, 19 Oct 2001, Wayne wrote:

> I have a question about the 'IP_MASQ_S_FIN_TIMEOUT"
> values in "net/ipv4/ip_masq.c" for the 2.2.x
> kernel. What purpose is served by having the
> terminated masqueraded TCP connection entries
> remain in memory for the default timeout of 2
> minutes? Why isn't the entry freed immediately?

        Because the TCP connection is full-duplex.
The internal-end sends FIN and waits the FIN from
external host. Then TIME_WAIT is eneterd.

> Perhaps what I'm really asking is why there
> is an mFW state at all. The only thing I can

        This state has timeout corresponding to
the similar state in the internal end. The remote
end is still sending data while the internal side is
in FIN_WAIT state (after a shutdown). The remote end
can claim that it is still in established state not
seeing the FIN packet from internal side. In any case,
the remote end has 2 minutes to reply. It can even
work for longer time if each packet follows in these
two minutes not allowing the timer to expire. It
depends in what state is the internal end, FIN_WAIT1
or FIN_WAIT2. May be the socket in the internal end is
already closed.

> think of is if the other end of the TCP connection
> spontaneously issues a half close before the
> initiator sends his half close. Then it might
> be desirable to wait a while for the initiator
> to send his half close prior to disposing of
> the connection totally. What would be the
> consequences of using "ipchains -M -S" to set this
> value to, say, 1 second?

        In any case, timeout values lower than those in
the internal hosts are not recommended. If we drop the
entry in LVS, the internal end still can retransmit
its FIN packet. And the remote end has two minutes to
flush its sending queue and to ack the FIN.

> [IP_MASQ_S_FIN_WAIT] = 2*60*HZ,
> /* OUTPUT */
> /* mNO, mES, mSS, mSR, mFW, mTW, mCL, mCW, mLA, mLI */
> /*syn*/ {{mSS, mES, mSS, mSR, mSS, mSS, mSS, mSS, mSS, mLI }},
> /*fin*/ {{mTW, mFW, mSS, mTW, mFW, mTW, mCL, mTW, mLA, mLI }},
> /*ack*/ {{mES, mES, mSS, mES, mFW, mTW, mCL, mCW, mLA, mES }},
> /*rst*/ {{mCL, mCL, mSS, mCL, mCL, mTW, mCL, mCL, mCL, mCL }},
> };
> /mFW

        IMO, you should claim that the timer in FIN_WAIT state
should not be restarted on packets coming from remote end.
Anything else is not good because it can drop valid packets that
fit into the normal FIN_WAIT time range. Or may be I don't
understand exactly your proposal?


Regards

--
Julian Anastasov <ja@xxxxxx>



<Prev in Thread] Current Thread [Next in Thread>