|
Hello,
You are right, a new algorism needs time to test and
verify. Sometimes I just need more control over the
dispatching, such as I need to use my hashing algorism
to control which client goes to where.
Doesn't the fwmark feature do it for your purposes then? I mean I don't
want to hold you off doing an API for transfering commands from user
space to kernel space to steer the scheduler's behaviour but be warned
of the consequences and it's rather academic viewpoint.
Sidenote: However the more I'm thinking about it the more I could see it
as a USP for LVS :).
Well, maybe you are right, they are just marketing
feature. I first though the syn check of BIGIP will
take less overhead then just pass it to real servers.
I'm not sure what you mean here.
Thus, the whole cluster may survive longer. I totally
agree with you that syn flood is a defect of the TCPIP
protocol and there's no way to prevent it. I just want
the lvs can stand a little bit longer if we can
features such as syn check.
Syn check can IMHO only be done on the RS part for LVS_DR and maybe on
the director for LVS_NAT. You can of course most of the time use a
contempary Unix (or Windows 2k3 Server for that matter) system for a RS
which will enable you to configure syn cookies, syn backlog queue, rate
limiting, whatnot.
Besides, the secure_tcp
defense strategy you mentioned in the defense page is
partialy disabled, because in the new kernel, the
timeout variables are not exists anymore.
Well, it's not disabled, nor partially disabled, you simply don't have
any means anymore to influence the tcp state transition timeouts for the
"under attack" table. You'll have to live with the one the kernel (LVS)
provides you. It's called best effort ;). But you still have memory
triggers and you also have threshold limitation.
And I think
secure_tcp is less useful than syn check(if it is not
marketing feature), because it only pass the burden to
real servers, and real server will spend much more
overhead if it is dealed in lvs.
I understand your reasoning and if you're willing to set up and perform
real life LVS cluster tests with regard to SYN flooding we're more than
willing to pick up the discussion again about including more
sophisticated approaches to this problem. Also don't understimate the
rate limiting functionality of the QoS subsystem and netfilter.
I'm always open to new ideas, however.
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
