Date: Thu, 4 Jan 2001 23:44:49 -0800 (PST) From: Luigi Rizzo <rizzo@aciri.org> To: jon@abccom.bc.ca (Jon Simola) Cc: rizzo@aciri.org, ipfw@FreeBSD.ORG Subject: Re: Indexing IPFW rule Message-ID: <200101050744.f057ini96287@iguana.aciri.org> In-Reply-To: <Pine.BSF.3.96.1010104145254.462Z-100000@newmail.netbistro.com> from Jon Simola at "Jan 4, 2001 4: 4:17 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > on second thought... unless you find some more efficient way to
> > perform the first matching, the "index" ipfw action seems completely
...
> Yep, it's just that initial match that isn't pretty, and not simple to
...
> jump into those rule blocks (gives me the wonderful side effect of traffic
oh for traffic stats, you can replace the 'accept' rule with a "pipe N"
action, where pipe N is configured as
ipfw pipe N config mask src-ip 0xffffffff
(or use different masks to aggregate more).
> of skipto rules arranged in a tree structure. It's also the most "efficient
> way to perform the first matching," as you say.
i must disagree on the efficiency issue... your code still does
a linear scan of the ruleset which is only partly (maybe a factor
of 2-4) faster than letting ipfw do its own matches.
A more efficient way would be to install the access list in the
kernel in a way which can be accessed in O(1) time. A possible
example would be a 256-bit string which tells you which hosts
are enabled and which ones are not. You'd need a bit of parsing
in the (userland) ipfw code to build the bitmap starting from
a form like this:
ipfw add <any_action> match_dst_ip:0,1,25-31,44,45,37,96-100,\
112,116,117,119,118,200-255 ip from any to 1.2.3.0/24
into the bitmap, and viceversa when printing out.
The match would be on the portion of the address which is masked off,
so you can accommodate smaller or larger sets easily.
I'd definitely suggest this method, which looks straightforward
to implement, and reasonably easy to understand (and you can
still have traffic stats by replacing the action with a pipe!)
Only catch is that you might need more room in the ipfw struct.
cheers
luigi
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?200101050744.f057ini96287>