Date: Thu, 13 Jun 2002 22:41:08 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: "'Luigi Rizzo'" <rizzo@icir.org> Cc: arch@freebsd.org Subject: Re: ipfw rewrite - new snapshot available Message-ID: <Pine.BSF.4.21.0206132239250.97512-100000@InterJet.elischer.org> In-Reply-To: <20020613171319.D93980@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Luigi. I haven't had a chance to look at it yet.. Too busy at USENIX.. I'll try look at it after I et back after I do KSE-MIII after..... :-) On Thu, 13 Jun 2002, 'Luigi Rizzo' wrote: > [Bcc to -net] > > Hi, > as I mentioned in a posting to -net a few days ago, over the past > weeks I have done an extensive rewrite of the ipfw code (both userland > and kernel) in an attempt to make it faster, more flexible and more > manageable. > > The code is now almost ready for commit, so I would appreciate > some feedback if any of you feels like trying it and, even > better, run some performance test. You can fetch the code from > > http://info.iet.unipi.it/~luigi/ipfw5.20020613.tgz > > This is for a -current after May 15th, and replaces > > sys/netinet/ip_fw.c > sys/netinet/ip_fw.h > sys/netinet/ip_dummynet.c > sbin/ipfw/ipfw.c > > The idea behind this work was to replace the old ipfw rules > (macroinstructions) with a set of microinstructions, each of them > performing a single operation such as matching an address, or a > port range, or a protocol flag, etc. -- much in the spirit of BPF > and derivatives -- and to let the userland front-end compile ipfw(8) > commands into an appropriate set of microinstructions. > > There are several advantages in using this technique: first of all, > instructions are typically shorter and faster, because the old > code had to check for the presence of all the possible options > (there are over 25 of them!) in a rule, whereas the new one can > simply do just the things that are required. > > I have implemented all the actions (accept/deny/pipe/divert/forward > ...) and almost all the 25+ (ouch!) different options that can be > specified in a rule. The syntax for the userland program is 100% > backward compatible. > > I have also implemented a few extensions to demonstrate the flexibility > of the new approach: you can put "or" connectives between fields, > so you can write things like > > ipfw add allow ip from host1 or host2 or host3 or not net1/24 to any > > and the like, and this greatly simplifies writing rulesets as > you can imagine. > > Other extensions (in the form of address sets, multiple rule > chains to be used on layer-2 and layer-3 firewalls, etc. will > be trivial to implement. > > cheers > luigi > > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > -----------------------------------+------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" 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.4.21.0206132239250.97512-100000>