|
Hello,
On Fri, 29 Sep 2000, ??? wrote:
> It may be a little bit off the topic, but I'm curious about the behavor of
> linux kernel on DDoS.
> The result of my test is as follows:
> 1. When there are too much incomming packets, network drivers begin to cry.
> (saying, for example, "card reports no resource..")
> 2. The more the packets come, the less the kernel can process.
> (ex, when packets come at the rate of 130000 pkt/s, kernel processes 50000
> pkt/s,
> while when packets come at the rate of 90000 pkt/s, kernel processes 80000
> pkt/s)
> 3. After the kernel is stressed by the packets for 10s of seconds, kernel
> begins to drop all the packets.
It seems the memory is allocated for 10 seconds and no new
connections are created from LVS. The number of entries can't exceed the
number defined with -srcnum. If each entry is no more than 128 bytes
you can select -srcnum value that does not lead to memory overload.
Of course, you can enable some of the LVS defense strategies to see if
there is a difference in the tests.
> 4. After 10s of seconds, kernel restarts processing packets.
Hm, is the number of entries same as before these 10 seconds?
cat /proc/sys/net/ipv4/ip_always_defrag
May be some of the entries are just expired?
> Reasons:(?)
> 1. Once I thought It was the fuction of ipvs code. But It's not.
> Because I didn't configure any ipvs settings in the test, and the sysctl
> variables for DoS was disabled,
> though the kernel was a 2.2.16 kernel patched with ipvs-0.9.15
>
> 2. I thought the network driver might make that problem.
> When it's stressed too much, it might be locked for seconds... But I think
> it's not probable now.
> I've tested 3com, eepro100, realtek which gave the same result.
>
> 3. I think there is codes somewhere in the kernel which makes the kernel
> drop normal
> packets on some condition.(when it should not)
> For example, the netdev_max_backlog variable in net/core/dev.c is fixed to
> 300.
Yes, there are some checks that take care of packet handling
using slow CPUs.
> I don't know what the value means and why it's fixed to that value.
Yes, the network tuning is a difficult task.
> Do you have any idea?
If your CPU is fast enough to accept the packets from the
packet driver and you have enough memory for the LVS entries and for
the packets you should be able to forward all packets. Of course,
there are many "if"s. The other thing we must consider is how LVS
delays the forwarding (and how many incoming packets are dropped
as result of the delayed handling). That can be tested by simply
forwarding the packets to the real server(s) without using LVS,
may be even with kernel without LVS support.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
