jamal <hadi@xxxxxxxxxx> writes:
> I meant whoever said that 400pps would cause a DOS. I didnt see the dst
> cache test being described in the source, so i assume it is someone else
> other than people who wrote the tool.
Ah, I see. I'm sorry for the confusion.
> I skimmed through it and got their message. Yes, i understand the
> implications ;->
>> > Is this supposed to cure something?
>> Garbage collection is much more aggressive and the chains attached to
>> the bucket are kept much shorter, so less CPU time is spent processing
> You may find that aggressive gc is one of your problems infact.
I don't think so. During a DoS attack with spoofed source addresses,
the dst cache quickly fills up, and the overwhelming majority of the
entries is useless (they won't be used again). The slabinfo line
looks like this:
ip_dst_cache 116477 131080 192 6554 6554 1
There are only 8192 hash buckets on this system, and if we assume that
the entries are uniformly distributed over the buckets (which is not
necessarily true), the code in ip_route_input() has to look at 14 or
15 cache entries before the miss is detected. I can hardly see how
this is efficient.
> I dont see the correlation of syn attacks and the dst cache in your
> description. Can you collect some profiles?
On the machine above, the dst cache has 2**17 entries. Imagine what
happens if all these entries are chained to the same bucket, and the
chain has to be traversed for each packet.
> I know thats what the paper says - but this is exactly what i have
> problems with: In the little study we did, its not the collisions that
> kill us rather the fact we are being forced into the slow path the
> majority of times. Please collect the profiles and send me the tool as
Okay, I'm going to do this (if I can figure out how to read the
> Our data was collected on a real ISP which hosts a lot of web
> servers and was being constantly DOSed. I dont think you can get
> more real world than that.
Did you look at a router, or at a host?