All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert de Bath <list-netfilter@debath.co.uk>
To: netfilter-devel@lists.netfilter.org
Subject: Iptables 1.3.1 still not very fast.
Date: Fri, 1 Apr 2005 22:52:25 +0100 (BST)	[thread overview]
Message-ID: <89b63d049739b257@mayday.cix.co.uk> (raw)

Okay, I'll admit is it a LOT faster that 1.2.11 it still seems to take a long 
time with big tables.

An example:
I have a program (I've called iptrange) that will take a file full of ip 
address ranges (192.168.42.10 192.168.42.25) and converts them into a set
of iptables chains that invokes another chain if the source (or dest) matches 
ie:

iptables -N CHECK
iptables -A CHECK -s 192.168.42.10/31 -j FOUND
iptables -A CHECK -s 192.168.42.12/30 -j FOUND
iptables -A CHECK -s 192.168.42.16/29 -j FOUND
iptables -A CHECK -s 192.168.42.24/31 -j FOUND

The good bit is that it will create a tree of subchains so that the
matching is efficient for large numbers of ip addresses.

This works well for a few hundred address ranges; I use it to match
recent 'evil' ips and ranges from dshield.org.

However, when I tried a 50000 range list from http://blocklist.org I
ran into problems.  After conversion it created 20000 chains with a
total of 70000 rules.  This tables took about an hour to load using
iptables-1.2.11!

Version 1.3.1 of libiptc is a LOT faster at about 5 minutes to do the
load. But this still seems very slow when it takes about half a second
to generate and print out the iptables rules to a script.

I hate to think how slow it would be with a million ranges; assuming it can be 
loaded it looks like it would be about 300000 chains, 1.3M
rules and about 100 rules checked per packet (to pick some figures out
of a single test) so it should be useable ...

BTW: iptables-restore is slower than my iptrange!

My problem is that I think that libiptc looks evil and I really don't
want to dive into messing with that code. So how can I help to make
libiptc run as fast as I'd like it to?

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)

             reply	other threads:[~2005-04-01 21:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-01 21:52 Robert de Bath [this message]
2005-04-02  4:53 ` Iptables 1.3.1 still not very fast Wang Jian
2005-04-02  5:32   ` Peter Enderborg
2005-04-02  5:41     ` Patrick Schaaf
2005-04-02  6:06       ` Re[2]: " Wang Jian
2005-04-02  5:49     ` Wang Jian
2005-04-02  9:27   ` Robert de Bath
2005-04-03 21:11     ` Henrik Nordstrom
2005-04-02  9:10 ` Henrik Nordstrom
2005-04-02 10:11   ` Robert de Bath
2005-04-28 10:36 ` Harald Welte
  -- strict thread matches above, loose matches on Subject: below --
2005-04-03  5:44 Robert Iakobashvili
2005-04-01 20:47 Robert de Bath

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=89b63d049739b257@mayday.cix.co.uk \
    --to=list-netfilter@debath.co.uk \
    --cc=netfilter-devel@lists.netfilter.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.