|
Hello,
On Wed, 14 Feb 2001, Laurent Lefoll wrote:
> Excuse me if I am a bit slow to understand but when I play with "ipchains -M
> -S
> [value] 0 0" the variable /proc/sys/net/ipv4/vs/timeout_established is
> modified
> even when /proc/sys/net/ipv4/vs/secure_tcp is set to 0 so I don't use secure
> TCP
> defense. The "real" timeout is of course set to [value] when a new TCP
> connection appears.
> So should I understand that timeout_established, timeout_udp,... are always
> modified by "ipchains -M -S ...." whatever I use or not secure TCP defense
> but
> if secure-tcp is set to 0, other variables give the timeouts to use ? If so,
> are
> these variable accessible or how to check their value ?
ipchains -M -S modifies the two TCP and the UDP timeouts in
the two secure_tcp modes: off and on. So, ipchains changes the three
timeout_XXX vars. When you change the timeout_* vars you change them for
secure_tcp=on only. Think for the timeouts as you have two sets: for
the two secure_tcp modes: on and off. ipchains changes the 3 vars in
the both sets. While secure_tcp is off changing timeout_* does not
affect the connection timeouts. They are used when secure_tcp is on.
> Regarding the second question, it's about ICMP packets that are replied to the
> client accessing the virtual service. Maybe I should precise I am in a VS/NAT
> configuration.
> For example, a client accesses a TCP virtual service and then stops sending
> data
> for a long time, enough for the LVS entry to expire. When the client try to
> send
> new data over this same TCP connection the LVS box sends ICMP (port
> unreachable)
> packets to the client. But for a TCP connection how these ICMP packets can
> "influence" the client ? It will stop sending packets to this expired (for the
> LVS box...) TCP connection only after its own timeouts, doesn't it ?
By default TCP replies RST to the client when there is no
existing socket. LVS does not keep info for already expired connections
and this is the reason ICMP is replied. Of course, if we implement
TCP RST replies we can reply TCP RST instead of ICMP.
The other question is how the client interpretes the ICMP
replies. Linux at least allows the application to listen for such
ICMP replies. In the other case (which is default) they are reported
after a TCP timeout (as soft errors).
> Regards,
>
> Laurent
Regards
--
Julian Anastasov <ja@xxxxxx>
|
