Here's an idea. With the below discussion, would it make sense to
regulate inbound packets so as not to consume 99.9% (those two connections
stayed alive :) of the network stack? If inbound packet handling was only
allowed to flood at most 80% of the stack, that should leave significantly
enough room for the rest of the work. (this should be considered dynamic
and tunable).
>> stalled after that. Of the six running connections I had (all ssh) all
>> but two of them stalled.
>
> That sounds like someone ran out of bandwidth. You are describing classic
> capture effect . How much do you know about your providers bandwidth 8)
My provider feeds us an SMDS line capable of doing DS3 rated bandwidth.
When under a smurf attack, we have sustained a 19Mb/s flow inbound, 5Mb/s
outbound and still managed connections. Yesterday we rated the combined
inbound and outbound traffic at 8Mb/s peak with an average of 5Mb/s. We
were well within the bandwidth constraints.
Our provider is Pacific Bell Internet and we are the only client on this
SMDS cloud. Our closest SMDS neighbor is Earthlink.
Other hosts on this switched network were able to do traffic with just a
slight bit of lag as they passed through the boundary router. Hosts on
the same segment as the target were unable to establish or maintain flow
of a current session with the target.
To further the conversation, a normal ping produced a normal resulting
echo reply. I did not measure the performance of UDP. TCP connections
showed up as the squeakiest wheel.
The ssh connections were all inside the local network. All other
connections from and to the local network acted completely normal.
-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/