From: Bill Davidsen <davidsen@tmr.com>
To: Jim Faulkner <jfaulkne@ccs.neu.edu>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, kraxel@bytesex.org,
davem@redhat.com, manmower@signalmarketing.com
Subject: Re: major network performance difference between 2.4 and 2.6.2-rc2
Date: Fri, 06 Feb 2004 16:14:13 -0500 [thread overview]
Message-ID: <402403A5.4090708@tmr.com> (raw)
In-Reply-To: <Pine.GSO.4.58.0402042248300.27381@denali.ccs.neu.edu>
Jim Faulkner wrote:
> Thanks to Andrew's suggestion of profiling my kernel, I've figured out
> what is happening here. It is my fault, it is not a bug.
>
> I use this iptables script generator:
> http://ftp.berlios.de/pub/mldonkey/pango/goodies/ipblacklist_convert
> in combination with this blacklist:
> http://www.peerguardian.net/pgipdb/guarding.p2p
>
> I had already modified the script so everything on my LAN interface was
> accepted, however I didn't realize that the scipt was using "-I INPUT 1"
> for all of its blacklist rules. iptables was going through around 5300
> rules for each and every packet that came in through my LAN interface,
> which is definately not what I intended.
>
> I fixed my firewall script, and my LAN throughput is back up at 10
> megabytes per second, with nowhere near the load.
This does point out an issue, as a 2.7 enhancement it would be really
useful to have a better way to handle a large number of rules, when what
you want is one rule applied to many IP values. I ran into this when
fighting a DDoS attack, and by the time I got the attack stopped, even
only dropping or rejecting --syn packets I had most of a CPU in system
time running ~10k rules.
I wrote a perl script to break it into multiple level tables, but it was
still pretty slow and uglier than a hedgehog's rectum.
What would be nice is some kind of table approach, hash or tree, which
allows operations to be matches against all of the IPs in a group, and
obviously to add/delete entries. I think for simplicity individual IPs
rather than CIDR blocks are desirable.
In any case, if a network person is looking for something really neat
for 2.7, blactlists of various types are getting more common, and an
efficient solution would be good.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2004-02-06 21:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-31 3:06 major network performance difference between 2.4 and 2.6.2-rc2 Jim Faulkner
2004-01-31 14:28 ` Felipe Alfaro Solana
2004-02-04 20:42 ` Jim Faulkner
2004-02-04 20:54 ` Andrew Morton
2004-02-04 21:08 ` David S. Miller
2004-02-04 21:22 ` Andrew Morton
2004-02-05 4:57 ` Jim Faulkner
2004-02-06 21:14 ` Bill Davidsen [this message]
2004-02-07 17:56 ` Hilko Bengen
2004-02-18 3:33 ` Bill Davidsen
2004-02-04 21:28 ` Gerd Knorr
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=402403A5.4090708@tmr.com \
--to=davidsen@tmr.com \
--cc=akpm@osdl.org \
--cc=davem@redhat.com \
--cc=jfaulkne@ccs.neu.edu \
--cc=kraxel@bytesex.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manmower@signalmarketing.com \
/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.