Re: debugging kernel during packet drops

[Patrick McHardy <kaber@trash.net>]

Jorrit Kronjee wrote:
> On 3/22/2010 6:16 PM, Patrick McHardy wrote:
>   
>>> When I disable the hashlimit module the packet drops disappear again.
>>> Now I know that hashlimit is made for more than one thing, namely
>>> limiting packets based on source/destination host and source/destination
>>> port, so it's not as efficient as it could be for my purposes. I could
>>> rewrite it, but before I do that, I would like to know if the module
>>> itself is really what's causing it, or if there's some underlying cause
>>> that I'm not seeing. So my question in short: how can I discover why
>>> it's dropping packets? 
>>>   
>>>     
>>>       
>> A couple of suggestions:
>>
>> - try the limit module in case you don't actually need per-source/dest etc.
>>   limiting but just a global limit
>>
>> - try using TBF or ingress policing. Both limit and hashlimit suffer of
>> problems
>>   regarding the resolution of the applied TBF. I don't remember the
>> exact range
>>   of values it is able to handle, but IIRC you should be able to find it
>> in the
>>   netfilter bugzilla.
>>
>> - if you use TBF or ingress policing and don't need ip_tables specific
>> modules,
>>   disabling bridge netfilter invocation of ip_tables through /proc
>> should increase
>>   performance.
>>
>>   
>>     
> Patrick,
>
> Although these are good suggestions, I really need to be able to limit
> per destination. The receiving network is a /15 which means I have to
> use something like a hashtable to keep track of destination IP
> addresses. Neither rateest or limit can do that. OTOH, that's also the
> only thing I need. This would make a low-cost ISP-grade DDoS filter,
> which is why I'm interested in it.
>
> The bug you're referring to is this one, I think: 
> http://bugzilla.netfilter.org/show_bug.cgi?id=523 but I'm not entirely
> sure if that is related to my problems.
>   

Yes, that's the one. Not specifically related to your problem, but to
the general hashlimit limitations.

> Is there any way I can figure out why ifconfig is reporting dropped
> packets?

Based on your description I'd say that the CPU simply can't keep up with
traffic. Perhaps the hash is undersized. The default size depends on the
amount of memory, you could try setting it manually to something appropriate
for the amount of addresses you expect to see.

If that doesn't help, I'd start by profiling the kernel.