From owner-freebsd-isp Sat May 16 19:03:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA13202 for freebsd-isp-outgoing; Sat, 16 May 1998 19:03:22 -0700 (PDT) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from home.us.net (home.us.net [198.240.72.28]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA13196 for ; Sat, 16 May 1998 19:03:19 -0700 (PDT) (envelope-from jjw@us.net) Received: from q.jjw.us.net (q.jjw.us.net [207.244.202.2]) by home.us.net (8.8.8/8.8.8) with SMTP id WAA17939; Sat, 16 May 1998 22:03:10 -0400 (EDT) X-Provider: US Net - Advanced Internet Services - 301-361-USNET - info@us.net Where Business Connects! (tm) -- http://www.us.net/ Message-ID: <355E455C.167EB0E7@us.net> Date: Sat, 16 May 1998 22:03:08 -0400 From: John Woodruff Organization: US Net X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Heikki Suonsivu CC: freebsd-isp@FreeBSD.ORG Subject: ipfw musings (was: Re: Bandwidth limiter available) References: <199805150331.FAA01765@labinfo.iet.unipi.it.newsgate.clinet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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)? 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... -- 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