Date: Thu, 4 Jan 2001 16:04:17 -0800 (PST) From: Jon Simola <jon@abccom.bc.ca> To: Luigi Rizzo <rizzo@aciri.org> Cc: ipfw@FreeBSD.ORG Subject: Re: Indexing IPFW rule Message-ID: <Pine.BSF.3.96.1010104145254.462Z-100000@newmail.netbistro.com> In-Reply-To: <200101041724.f04HOgc92175@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Jan 2001, Luigi Rizzo wrote:
> on second thought... unless you find some more efficient way to
> perform the first matching, the "index" ipfw action seems completely
> overkill if you use dynamic rules: just put a check-state first,
> followed by an ordinary skipto to go to the beginning of the table,
> and then insert all rules you need. This is extremely flexible, as
> you can use different patterns on the "jump table" (which is not
> a jump table anymore) and quite efficient after the first time
> because the check-state matches quickly.
Yep, it's just that initial match that isn't pretty, and not simple to
implement. Currently, for each /24 I've got 256 rules for inbound and 256 for
outbound traffic, and 84 rules each way (arranged in a 3 level quad-tree) to
jump into those rule blocks (gives me the wonderful side effect of traffic
stats as well). I'm running full duplex 100Meg through a PPro 180, so I'm very
interested in speeding the firewall up as much as possible.
That's why I did the index idea, it's basically a skipto with a variable
destination, and it's a *lot* easier to comprehend than my nasty collection
of skipto rules arranged in a tree structure. It's also the most "efficient
way to perform the first matching," as you say.
>
> ipfw add 1000 check-state
> ipfw add 1001 skipto 10000 <some match pattern>
> ...
> ipfw add 10000 allow ip from 10.0.0.1 to any
ipfw add 10000 allow ip from 10.0.0.1 to any keep-state ?? :)
> ipfw add 10000 deny ip from 10.0.0.2 to any
> ipfw add 10000 deny ip from 10.0.0.3 to any
> ipfw add 10000 allow ip from 10.0.0.4/28 to any
> ...
> ipfw add 10000 allow ip from 10.0.0.254 to any
>
> > There are some ways to solve the efficiency problem, but probably
> > the simplest one is to to keep your code but put a "keep-state"
> > option in each of the branch targets and in the index rule -- this
> > way the matching will install a dynamic rule which can be then
> > tested in O(1) time because this is supported by a hash table.
---
Jon Simola <jon@abccom.bc.ca> | "In the near future - corporate networks
Systems Administrator | reach out to the stars, electrons and light
ABC Communications | flow throughout the universe." -- GITS
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1010104145254.462Z-100000>