Date: Sat, 16 May 1998 19:51:34 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: John Woodruff <jjw@us.net> Cc: Heikki Suonsivu <hsu@clinet.fi>, freebsd-isp@FreeBSD.ORG Subject: Re: ipfw musings (was: Re: Bandwidth limiter available) Message-ID: <Pine.BSF.3.95.980516194843.17001F-100000@current1.whistle.com> In-Reply-To: <355E455C.167EB0E7@us.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 May 1998, John Woodruff wrote: > Heikki Suonsivu wrote: > > There has to be better address-matching code than a linear list. > > True, but judicious use of skipto helps. In the best case, you > might be able to do a binary decision tree. I do this on an > ordinary ipfw firewall: first split is on ifc and direction, > second is on protocol, then sequence of from/to rules. > > > It may be easy to use, but ipfw is too inefficient implementation > > for this use. We used a single dedicated P150 to do byte counting > > for about 400 networks, totalling of 800 ipfw lines (one for > > incoming traffic, one for outgoing traffic). > > Exactly what I mean. With one skipto, looking simply at which > direction the packet was traveling in, you could cut the average > time spent traversing this list in half. > > Even though skipto is also a linear search, the whole loop is > only two lines of code. Resolveing the goto's in add_entry() > probably isn't worth the complexity. > > > Another serious problem with ipfw is that all packets are > > processed independent of the interface used, which makes the > > performance problem worse. > > Agreed - I was surprised when I found the head of the chain > wasn't hanging off the ifp and/or protocol, which is why I > wrote my rules starting with skipto. Does someone who knows > want to explain why this is(nt)? Some rules are valid for all or some interfaces, and some rules might be good for both incoming and outgoing rules... SKIPTO is teh right way to go and I am woking slowly on pre-resolving the skipto rules (as you suggest is not worth doing :-) > > Does anyone want to re-implement ipfw to work as a tree? > If so, the next step might be an optimizer in /sbin/ipfw. > > PS: /sbin/ipfw desperately needs to understand comments and > to give sane diagnostics. I havn't looked at -current; is > it's /sbin/ipfw any better? I use a perl macro preproc... yes it has # comments :-) (or maybe the commit message was in my imagination) > -- > John Woodruff, Sr. Network Engineer, US Net - 301-361-USNET > Washington/Baltimore/Richmond ISP - $6.95/month for full PPP! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" 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.95.980516194843.17001F-100000>