On Fri, 23 Apr 2021 15:45:54 +0900, JeongHwan Kim said:
I'm testing packet flooding test with old kernel version 2.6.30.
[/usr/src/linux-next] git show v2.6.30 | grep Date Date: Tue Jun 9 20:05:37 2009 -0700 [/usr/src/linux-next] git diff --shortstat v2.6.30..HEAD 82911 files changed, 25695096 insertions(+), 6275216 deletions(-) You're almost 26 million lines and 12 years out of date. Why are you using such an old version? As GregKH will say, complain to the people who are forcing you to use such an outdated kernel version. (Another indication of how much code change has happened is that 82,911 files were changed - but there are currently only 72,245 files in the source tree)
My board experienced process starvation when injecting ICMP flood with hping3 tool. I modified softirq invocation routine to launch ksoftirqd instead of executing do_softirq and I limitted the speed of ethernet phy to accept below 10Mbps.
What CPU are you running this on? Anything resembling modern hardware should be able to handle *much* higher data rates. Of course, if you're stuck with decade-old hardware, it's harder. But even a Sun3/50 with a 16Mhz 68020 processor back in 1986 was able to deal with 10Mbps traffic. Also, note that the critical point is the packets per second, not the bitrate of the PHY. On server-class hardware, it's trivial to get 10 gigabit/sec traffic when using MTU=9000, harder at MTU=1500, and *very* difficult to handle 10Gbit/s of 64-byte minimum size packets (even *generating* that many packets that fast requires some cleverness).
It seems that the board can process flooding ICMP packets of 10Mbps, but the board cannot process against TCP/UDP packet flooding, the speed of processes become slow down.
Well, it *should* self-protect against TCP packet flooding by simply not sending ACK packets with sequence numbers until those sequence numbers have actually been dealt with. However, UDP doesn't have any such built-in protections.
How can I protect the TCP/UDP flooding in my environment.
It's not TCP/UDP flooding that's your problem. Packet flooding *in general* is a problem. The only reason you think ICMP is working is because the per-packet overhead for handling an ICMP flood packet is much lower - UDP and TCP have to do more processing, especially if the packet is going to a port number that's actually in use. TCP packets to non-open ports are cheap to send an RST packet back, and UDP packets to non-open ports are equally cheap (but send an ICMP PORT UNREACHABLE instead), but if a TCP or UDP packet is going to an open port, there's a lot more processing that has to be done even if the packet is going to be discarded.