All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jorrit Kronjee <j.kronjee@infopact.nl>
To: Patrick McHardy <kaber@trash.net>, netfilter-devel@vger.kernel.org
Subject: Re: debugging kernel during packet drops
Date: Tue, 23 Mar 2010 16:14:13 +0100	[thread overview]
Message-ID: <4BA8DAC5.6050002@infopact.nl> (raw)
In-Reply-To: <4BA7A5D8.5080101@trash.net>

On 3/22/2010 6:16 PM, Patrick McHardy wrote:
> Jorrit Kronjee wrote:
>   
>> Dear list,
>>
>> I've asked this question on the kernelnewbies forum, but I haven't got
>> any responses. I hope someone here is able to help me. I'm trying to
>> build a setup that allows me to limit the amount of packets/s per
>> destination IP address. The setup I use for this is as follows: 
>>
>> [ DoS machine ] -> [ bridging firewall ] -> [ receiving network ] 
>>
>> I used brctl to build the bridge. The DoS machine has a custom built
>> tool that allows me to send small packets at very fast rates. I've
>> discovered that bridging still works reliably at around 300 kpackets/s
>> (notice the 'k' in there). However, as said before, I was trying to
>> limit the amount of packets/s, so I used netfilter's hashlimit module.
>> This is when packet drops started to appear. 
>>
>> At around 300 kpps, the amount of packet drops is 40 kpps. For me, this
>> amount is too significant to ignore. I see the load average go from a
>> comfortable 0.00 to 1.78, mainly caused by ksoftirqd processes. At 200
>> kpps, the average amount of packet drops is 23 kpps. At 100 kpps, it's
>> still 2 kpps. 
>>
>> 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.

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

Thanks for all the help so far!

Regards,

Jorrit Kronjee


  parent reply	other threads:[~2010-03-23 15:14 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-22 10:41 debugging kernel during packet drops Jorrit Kronjee
2010-03-22 17:16 ` Patrick McHardy
2010-03-22 17:53   ` Jan Engelhardt
2010-03-22 18:02     ` Patrick McHardy
2010-03-23 15:14   ` Jorrit Kronjee [this message]
2010-03-23 15:39     ` Patrick McHardy
2010-03-23 17:21     ` Eric Dumazet
2010-03-23 20:07       ` Eric Dumazet
2010-03-24 15:20       ` Jorrit Kronjee
2010-03-24 16:21         ` Eric Dumazet
2010-03-24 16:28           ` Jan Engelhardt
2010-03-24 17:04             ` Eric Dumazet
2010-03-24 17:25               ` Jan Engelhardt
2010-03-25  9:32           ` Eric Dumazet
2010-03-25 10:35             ` Patrick McHardy
2010-03-25 11:02               ` Eric Dumazet
2010-03-31 12:23                 ` [PATCH nf-next-2.6] xt_hashlimit: RCU conversion Eric Dumazet
2010-04-01 11:03                   ` Patrick McHardy
2010-04-01 12:10                     ` Eric Dumazet
2010-04-01 12:36                       ` Patrick McHardy
2010-03-25 12:42               ` debugging kernel during packet drops Jan Engelhardt
2010-03-30 12:06               ` Jan Engelhardt
2010-03-30 14:12                 ` Patrick McHardy
2010-03-26 10:41             ` Jorrit Kronjee
2010-03-26 11:21               ` Eric Dumazet
2010-03-26 14:17               ` Eric Dumazet
2010-03-26 15:54                 ` Jorrit Kronjee
2010-03-23 17:04 ` James King
2010-03-23 17:23   ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BA8DAC5.6050002@infopact.nl \
    --to=j.kronjee@infopact.nl \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.