Mailing List Archive

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 ?

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 ?

Regards,

Laurent

Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 14 Feb 2001, Laurent Lefoll wrote:
>
> > Hi,
> >
> > If I am not misunderstanding something, the variable
> > /proc/sys/net/ipv4/vs/timeout_established gives the time a TCP connection can be
> > idle and after that the entry corresponding to this connection is cleared. My
> > problem is that it seems that sometimes it's not the case. For example I have a
> > system (2.2.16 and ipvs 0.9.15) with /proc/sys/net/ipv4/vs/timeout_established
> > = 480 but the entries are created with a real timeout of 120 ! On another system
>
> Read http://www.linuxvirtualserver.org/defense.html
> 3. The secure_tcp defense strategy
>
> The above is the place where the timeouts are explained.
> They are valid for the defense strategies only. For TCP EST state you
> need to read the ipchains man page: ipchains -M -S 480 0 0
>
> > I have the same value for /proc/sys/net/ipv4/vs/timeout_established but the
> > entries are created with a real timeout of 15 min. Are there any other
> > parameters affecting the real timeout or am I wrong somewhere ?
> >
> > Another question : what is the usefulness of the ICMP packets that are sent when
> > new packets arrives for a TCP connection that timed out for in LVS box ? I
> > understand obviously for UDP but I don't see their role for a TCP connection...
>
> I assume your question is about the reply after
> ip_vs_lookup_real_service.
>
> It is used to remove the open request in SYN_RECV state in the
> real server. LVS replies for more states and may be some OSes report
> them as soft errors (Linux), others can report them as hard errors,
> who knows.
>
> > Thanks
> >
> > Laurent
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
> Send requests to lvs-users-request@LinuxVirtualServer.org
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users

Hello,

On Wed, 14 Feb 2001, Laurent Lefoll wrote:

> Hi,
>
> If I am not misunderstanding something, the variable
> /proc/sys/net/ipv4/vs/timeout_established gives the time a TCP connection can be
> idle and after that the entry corresponding to this connection is cleared. My
> problem is that it seems that sometimes it's not the case. For example I have a
> system (2.2.16 and ipvs 0.9.15) with /proc/sys/net/ipv4/vs/timeout_established
> = 480 but the entries are created with a real timeout of 120 ! On another system

Read http://www.linuxvirtualserver.org/defense.html
3. The secure_tcp defense strategy

The above is the place where the timeouts are explained.
They are valid for the defense strategies only. For TCP EST state you
need to read the ipchains man page: ipchains -M -S 480 0 0

> I have the same value for /proc/sys/net/ipv4/vs/timeout_established but the
> entries are created with a real timeout of 15 min. Are there any other
> parameters affecting the real timeout or am I wrong somewhere ?
>
> Another question : what is the usefulness of the ICMP packets that are sent when
> new packets arrives for a TCP connection that timed out for in LVS box ? I
> understand obviously for UDP but I don't see their role for a TCP connection...

I assume your question is about the reply after
ip_vs_lookup_real_service.

It is used to remove the open request in SYN_RECV state in the
real server. LVS replies for more states and may be some OSes report
them as soft errors (Linux), others can report them as hard errors,
who knows.

> Thanks
>
> Laurent


Regards

--
Julian Anastasov <ja@ssi.bg>

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@ssi.bg>

Julian Anastasov wrote:
>

> > 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).

Julian,


what is "the other case" (non Linux) and why is it default?
what is "they"?

Thanks Joe

--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA

Hello,

On Tue, 20 Mar 2001, Joseph Mack wrote:

> > 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).
>
> Julian,
>
>
> what is "the other case" (non Linux) and why is it default?

By default if the application does not listen for ICMP
errors they are reported after a TCP timeout and according to the
TCP state. But the application can register for these ICMP errors and by
this way to detect them immediately as they are received for the socket.
May be it is not recommended to use this information from untrusted
sources. The ICMP errors are reported immediately for some TCP (SYN)
states.

> what is "they"?
>
> Thanks Joe


Regards

--
Julian Anastasov <ja@ssi.bg>