All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aleksandar Milivojevic <amilivojevic@pbl.ca>
To: netfilter@lists.netfilter.org
Subject: Re: Many Many table rules
Date: Tue, 14 Sep 2004 14:24:05 -0500	[thread overview]
Message-ID: <41474555.1030207@pbl.ca> (raw)
In-Reply-To: <d82fbdb70409141006173a23f2@mail.gmail.com>

Michael Eck wrote:
> I have a bridging traffic shaper that uses htb and sfq.  My iptables
> and kernel are patched with ipp2p and layer-7 filtering to mark p2p
> traffic.  Currently, this unit is at the head end of a broadband
> network.  I'm dividing up my users into htb classes based on their
> location on the network.  This amounts to 5 rules per IP address, 1
> for generic traffic, and 4 for ipp2p and a few layer7 rules.  That
> puts me at about 820 rules for the inside interface portion of my
> iptables.

It might be a good idea to optimize things using user defined chains. 
That way, packet that matches your 820th rule, wouldn't need to go 
through 820 rules.

For example, simple solution would be to have rules that match only by 
protocol, and than from them jump into the chain where you match by IP 
address, something like:

   -A FORWARD -p tcp --dport aaa -j mychain
   -A FORWARD -p tcp --dport bbb -j mychain
   -A FORWARD -p udp --dport ccc -j mychain
   -A mychain -s a1.b1.c1.d1 -d e1.f1.g1.h1 -j ACCEPT
   -A mychain -s a2.b2.c2.d2 -d e2.f2.g2.h2 -j ACCEPT
       ... and so on ...
   -A mychain -j DROP

Or you could do it the other way around (first by IP addresses, and than 
by protocol)...  Even with simple setup, if you have 200 clients and you 
are allowing 5 protocols per client, in worst case packet would go 
through 205 rules instead of 1000 rules.

Another idea that might work for you is using statefull matching, and 
putting rule that matches ESTABLISHED packets as the first rule of 
INPUT, OUTPUT and FORWARD chains, for example:

   -A FORWARD -m state --state ESTABLISHED -j ACCEPT

If this is the very first rule in forward chain, 99.99% of your network 
traffic will be matched by it (so as performance goes, it's like you 
have only one rule instead of 820).

Only the very first packet of each connection would have to go through 
subsequent rules (say 400 rules on average?).  And if you presorted 
packets to user defined chains first, than this number will be even lower.

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7


  reply	other threads:[~2004-09-14 19:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-14 17:06 Many Many table rules Michael Eck
2004-09-14 19:24 ` Aleksandar Milivojevic [this message]
2004-09-15 12:21   ` Michael Eck
2004-09-15 15:57     ` Aleksandar Milivojevic

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=41474555.1030207@pbl.ca \
    --to=amilivojevic@pbl.ca \
    --cc=netfilter@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.