From owner-freebsd-isp Sat May 16 20:02:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA19764 for freebsd-isp-outgoing; Sat, 16 May 1998 20:02:37 -0700 (PDT) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA19755 for ; Sat, 16 May 1998 20:02:35 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA01620; Sat, 16 May 1998 19:51:41 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd001617; Sun May 17 02:51:37 1998 Date: Sat, 16 May 1998 19:51:34 -0700 (PDT) From: Julian Elischer To: John Woodruff cc: Heikki Suonsivu , freebsd-isp@FreeBSD.ORG Subject: Re: ipfw musings (was: Re: Bandwidth limiter available) In-Reply-To: <355E455C.167EB0E7@us.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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