|
Hello,
On Mon, 27 Mar 2000, Wensong Zhang wrote:
>
>
> Hi Julian,
>
> On Mon, 27 Mar 2000, Julian Anastasov wrote:
>
> > OK, may be we can implement some statistics in the LVS:
> >
> > - dropped entries
> > - traffic for each real service
> > - etc
> >
> > Or may be just for debugging, i.e. to check the behavior under
> > attack and with the goal to tune the mechanisms. We can encount the
> > ICMP_PORT_UNREACH packets sent back to the real server too. This
> > is only an idea.
> >
>
> Both are OK. Statistics information is good, as long as it won't take too
> much CPU cycles to collect those information.
>
> > > > I like the idea of many independent sysctl vars.
> > > > We have to choose correct names for the above sysctl vars.
> > > >
> > >
> > > It is good to have many independent sysctl vars. However, it might be good
> > > to have an ip_vs_defence_level sysctl, whoes value can be 0,1,2,3,4...,
> > > different level means different defence strategies, then there is only one
> > > sysctl on this. ;)
> >
> > I think it is very useful to combine delayed ES transitions
> > with dropping packets (without passing them). Lets choose some names
> > for them.
> >
> > 1. "dropping entries" => from table
> > 2. "dropping packets" => without passing them (using rate)
> > 3. "secure tcp" ??? I.e. when we follow the real servers TCP state
> >
> > Method 3 can be problematic for services which assume
> > timeout 15 minutes after the connection setup. May be this method
> > can be optional. But methods 1 and 2 seem as mandatory for me. But
> > it can be useful each to be set independently. If we choose to
> > use one sysctl var, we have to combine the useful combinations.
> > I.e. the max is 3 methods ^ 3 values (0/1/2) => 27 values. The
> > other parameters can be when each method is triggered in
> > automatical mode. OK, may be we have to choose only small number
> > of possible settings.
> >
>
> Independent sysctl variables are OK, and let users combine one that they
> want. I haven't got good names for them, maybe we can simply use
>
> ip_vs_dropentry randomly drop entries from the table
0 - never drop entries
1 - mode is automatically changed (using amemthresh)
> ip_vs_droppacket 1/rate randomly drop packets without
> passing
0 - never drop packets
1 - mode is automatically changed (using amemthresh)
> ip_vs_amemthresh available memory threshold to guild
> when to do dropentry and droppacket
Name for this?:
ip_vs_secure_tcp
0 - use default state/timeout table
1 - mode is automatically changed (using amemthresh)
2 - we like it so much => always follow real
servers TCP flags
The recommended settings:
ip_vs_dropentry =1
ip_vs_droppacket =1
ip_vs_secure_tcp =2
ip_vs_amemthresh =X(KB or MB?)
>
> Maybe you have other good names.
These look good for me. Someone with better names?
> > It can be useful each virtual service to use different
> > timeouts but it is difficult to achieve. There are so many states.
> > May be only for the ES and UDP states. When I implement the
> > per-entry timeout table (ms->timeout_table) I'll check if this is
> > possible. If the idea looks good. So, this can be an additional timeout
> > value. For TCP it is ES timeout. For UDP it is UDP timeout. But the
> > goal is only to work under DoS attack.
> >
>
> Yeah, it must be complicated to implement different virtual services have
> different timeouts. Maybe we can simply implement the under-attack timeout
> table as you suggested before, when the system is under attack, we turn to
> that defence timeouts (timeouts are often short). Or, maybe we can use
> sysctl variables to let people to tune the defence timeouts themselves.
Yes, it looks very complex. If we continue in this direction
the MASQ will be rewritten. Currently only ms->timeout_table is
defined but it is not very useful. The useful struct fields can be:
ms->state_table
state_table->timeout_table.timeout
state_table->states
But it is very complex. I agree, for now we can just use
two different tables. Let try the changes step by step.
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|
