All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jorrit Kronjee <j.kronjee@infopact.nl>
To: netfilter-devel@vger.kernel.org
Subject: debugging kernel during packet drops
Date: Mon, 22 Mar 2010 11:41:20 +0100	[thread overview]
Message-ID: <4BA74950.6000305@infopact.nl> (raw)

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? 

Some details about the machine: 

network controllers: 
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network
Connection (rev 02) 
04:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet
Controller (rev 05) 

drivers: 
driver: e1000e 
version: 1.1.2.1a-NAPI 
firmware-version: 1.3-0 
bus-info: 0000:00:19.0 

driver: e1000 
version: 7.3.21-k3-NAPI 
firmware-version: N/A 
bus-info: 0000:04:02.0 

CPU: Intel Xeon CPU X3330 @ 2.66 GHz

Regards,

Jorrit Kronjee


             reply	other threads:[~2010-03-22 10:41 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-22 10:41 Jorrit Kronjee [this message]
2010-03-22 17:16 ` debugging kernel during packet drops Patrick McHardy
2010-03-22 17:53   ` Jan Engelhardt
2010-03-22 18:02     ` Patrick McHardy
2010-03-23 15:14   ` Jorrit Kronjee
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=4BA74950.6000305@infopact.nl \
    --to=j.kronjee@infopact.nl \
    --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.