LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: random SYN-drop function

To: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: random SYN-drop function
Cc: Ratz <ratz@xxxxxx>, lvs-users@xxxxxxxxxxxxxxxxxxxxxx, cluster-list@xxxxxxxxxx
From: Wensong Zhang <wensong@xxxxxxxxxxxx>
Date: Thu, 16 Mar 2000 21:39:20 +0800 (CST)
Julian,

Your comments are always cute, thanks! ;-)

On Thu, 16 Mar 2000, Julian Anastasov wrote:

>       I see another problem. The OUTPUT state table looks very
> wrong for me. The SR state checking looks incorrect in the context
> of VS/NAT mode. If the SYN packet is forwarded from the Director
> to the Real server, the Real server answers immediately with SYN
> cookie and the state is changed to ES. So, under SYN flood with
> SYN-cookies enabled we have ES states and not the SYN states.
> May be the state table is wrong but it is not patched from the LVS.
> Is the OUTPUT table correct? The change:
> 
> OUTPUT           SYN
>       SR -> ES
> 
>       When the SYN-cookie (SYN+ACK) is sent we switch to ES
> which is for very short interval after the initial SYN. And
> ip_vs_random_drop_syn() can't find many entries.
> 

It is true for VS/NAT now. I think it is the problem of the OUTPUT state
table. Just check the TCP finite state machine in the textbook, it should
be the ACK packet to transfer from SynRecv state to ES state. We need fix
it.

>       This can be avoided if the SYN packets are really dropped
> before forwarded to the Real server and not when the entries are
> dropped.
> 

Yeah, it can be done. We can probably borrow Alexey's traffic shaping code
and add some QoS functionality to LVS too, then different virtual servers
may have different service grade. RED (Random Early Drop/Dection)
algorithm can help protect LVS from syn-flooding attack. Alexey's traffic
control (net/sched/*) is very cute, although I just have understood part
of it. ;-)

The reason that I did not do this is that I don't introduce some overhead
in checking available memory for every new connections.

>       May be we can make sltimer_handler() to set the drop rate
> by this way:
> 
> 0 - don't drop (normal)
> 1 - drop each (may be until the next second)
> 2 - drop 1/2
> 3 - drop 1/3
> n - drop 1/n
> 
>       We can use simple counter: once zeroed we drop a SYN
> frame.
> 
>       What about dropping UDP before the entry is created using
> this rate ?
> 

It is my fault that I forgot dropping entries for UDP. I will add
(ms->state == IP_MASQ_S_NONE) condition soon.

>       Something like this where the drop is triggered by int!=0
>       I didn't tested current implementation how it looks under
> load.
> 

Your feedback is very welcome. ;-)

Thanks,

Wensong





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