any inbound packet over the limit is a bad packet.
the current situation simply misses packets altogether at the 100% mark.
this means that 100% of the bandwidth is going being consumed by the
inbound flood. outbound traffic can't compete.
my idea is do drop that 100% mark down a bit so we get *some*
communication. i.e. reserving a pinch of memory so we can at least send
some packets.
it would make sense to make a small buffer distinction between network
interfaces so a second network card doesn't become useless when card #1 is
under heavy fire.
> It's like this ->
> assemble IP frame . look at source/numbering. match against firewall list.
> drop
> you want to drop the frames even before they are reassembled.
yes i do. frames are getting missed in the first place from the extreme
ingress rate. so dropping them to maintain an XX % limit isn't making a
bit of `validity' difference. the difference is that we are now have
buffer space to send packets and maintain current connections.
to reiterate:
current solution: give all buffer space to anything asking for it. no
limits. an attacked interface can hog all buffer
resources leaving nothing to operate on.
proposed solution: give n% (sysctl controllable) buffer space to anything
asking for it. reserve buffer space for outbound and
try to make the impact of heavy attack on one NIC less
debilitating on all other NICs.
remember. at >8,000pps inbound, a significant amount of these are likely
lost to the etherworld already. instead of dedicating all resources to
try and handle them. establish a resource limit and simply drop excess
frames. you're already being denied service, you should attempt to
control that loss and reserve some resources for yourself.
-d
-- Look, Windows 98 Buy, lemmings, buy! MCSE, Must Consult Someone Experienced (c) 1998 David Ford. Redistribution via the Microsoft Network is prohibited. for linux-kernel: please read linux/Documentation/* before posting problems
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/