|
Horms wrote:
>
> Hi,
> I have a question on behalf of a client.
>
> When a connection is recieved by an IPVS server and forwarded
> (by whatever means) to a back-end server at what stage is
> this connection entered into the IPVS table. It is before or
> as the packet is sent to the back-end server or delayed
> until after the 3 way handshake is complete.
>
> It has been alleged that IBMs Net Director waits until
> the completion of the three way handshake to avoid the
> table being filled up in the case of a SYN flood. To
> my mind the existing SYN flood protection in Linux should
> protect the IPVS table in any case and the connection
> needs to be in the IPVS table to enable the 3 way handshake
> to be completed.
>
There is state management in connection entries in the IPVS table. The
connection in different states has different timeout value, for
example, the timeout of the SYN_RECV state is 1 minute, the timeout of
the ESTABLISHED state is 15 minutes (the default). Each connection
entry occupy 128 bytes effective memory. Supposing that there is 128
Mbytes free memory, the box can have 1 million connection entries. The
over 16,667 packet/second rate SYN flood can make the box run out of
memory, and the syn-flooding attacker probably need to allocate T3
link or more to perform the attack. It is difficult to syn-flood a
IPVS box. It would be much more difficult to attach a box with more
memory.
> A second, related question is if a packet is forwarded to
> a server, and this server has failed and is sunsequently
> removed from the available pool using something like
> ldirectord. Is there a window where the packet
> can be retransmitted to a second server. This would
> only really work if the packet was a new connection.
>
Yes, it is true. If the primary load balaner fails over, all the
established connections will be lost after the backup takes over. We
probably need to investigate how to exchange the state (connection
entries) periodically between the primary and the backup without too
much performance degradation.
Thanks,
Wensong
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
