|
Hello,
On Fri, 29 Sep 2000, Pietro Ravasio wrote:
> > This result is expected. Have you seen DDoS :)
>
> I've read "LVS defence strategies against DoS attacks"
> (www.linuxvirtualserver.org/defense.html), but I've not implemented any of
> the strategies it talks about yet!
> Is this what you're talking about?
Hm, yes.
> Is DoS protection you're talking about at kernel level or at LVS level? I
> think the first one since I can't connect to real servers' port 80 after
> testlvs launch even trying to connect from "realservers localhost" (it's
> realservers' kernel to stop processing packet directed to port 80)
Yes, the real servers rely on the kernel's defense but LVS has
it's own strategies. If enabled they try to keep some free memory for
the LVS entries in the director. They don't care for the real servers.
The kernel's defense can guard the sockets from long queues with requests
that are not accepted.
> I can perform testlvs runs if I set -srcnum < ~20, it seems to me that
> kernel considers a packet flooding as a DoS attack only if it comes from a
> lot of different Ip numbers... Am I wrong?
Yes, one of the reasons testlvs to exist is to stress the
LVS connection table with packets from many client addresses. This is
more than just to forward packets. Now we simulate a production
environment with many clients where you can expect large connection
table. Now you can tune many of the LVS parameters (sysctl vars) before
including the director in production.
Of course, testlvs is not perfect for testing all defense
strategies in LVS. Some of them are very complex and can classify
the attack as SYN flood and to drop the entries very soon after the
entry creation (seconds).
> Having set "srcnum 10", I've done some test with testlvs, and I can get
> about 3200-3400 packets/sec. This is CPU limited: my PIII 733 LVS servers
> report full CPU usage during tests, while occupied memory doesn't seem to
> grow (used memory: ~40Mb, and it doesn't grow during tests).
I'm not sure what one request in your setup raises as response.
It depends on the used source addresses, whether the traffic is dropped
in the real servers or it is replied and followed from connection resets,
etc. You have to test with one packet and to show us the tcpdump output.
The ideal situation is 2 packets:
1. From client to director
2. From director to real server (where the packet is dropped)
If you see ICMP errors (network unreachable) or other error
packets this can be a good reason for the performance drop.
> I have reached ~17500 packets/sec during first tests, I can't understand
> why I can't get this result anymore (I've not change anything in SW/HW
> configuration, I only went lunch! :)
Hm, the main thing is whether the packets are dropped in the
real server(s). You still have the option to trace one packet.
> My LVS servers are single PIII 733, 256Mb, doing NAT on a 100Mbit switched
> (Cabletron Smart Stack) network.
>
> Regards,
> Pietro
Regards
--
Julian Anastasov <ja@xxxxxx>
|
