From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 23:41:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8FBDB16A404 for ; Fri, 30 Mar 2007 23:41:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (outE.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 7D23F13C45D for ; Fri, 30 Mar 2007 23:41:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 30 Mar 2007 16:12:24 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 9B2BE125D4D; Fri, 30 Mar 2007 16:41:39 -0700 (PDT) Message-ID: <460DA02D.8010509@elischer.org> Date: Fri, 30 Mar 2007 16:41:33 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Kevin Day References: <460D75CE.70804@elischer.org> <98FE1AAF-DF19-43A8-A5B6-010C852AF489@dragondata.com> In-Reply-To: <98FE1AAF-DF19-43A8-A5B6-010C852AF489@dragondata.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: IPFW update frequency X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 23:41:40 -0000 Kevin Day wrote: > > On Mar 30, 2007, at 3:40 PM, Julian Elischer wrote: > >> I have been looking at the IPFW code recently, especially with respect >> to locking. >> There are some things that could be done to improve IPFW's behaviour >> when processing packets, but some of these take a >> toll (there is always a toll) on the 'updating' side of things. >> >> For example. I can make IPFW lock-free during processing of packets >> (i.e. not holding any locks while traversing the >> list) which would solve problems we have with lock-order reversals >> when it needs to look at the socket layer (which needs socket layer >> locks). Unfortunatly this would make it a lot more expensive >> in the case where new rules are being added to the list. possibly a LOT >> more expensive. Now, this would only matter if one was adding (or >> deleting) >> hundreds of rules per second to the firewall, but as I've discovered, >> there's always SOMEONE that is doing the very thing you imagine that >> no-one would ever do. >> >> In my imagination, most of the people who did this sort of thing don't >> need to do it any more as tables obviate the need for that sort of thing. >> >> Is there anyone out there who is adding hundreds (or even dozens) of >> rules >> per second on a continuous basis, or who wants rule changing to >> be a really efficient operation? >> (does it matter to you if it takes a few milliSecs to add a rule?) >> >> Julian > > Would this apply to "dynamic rules", using the keep-state keyword? > That'd be a killer for us. > no, just to the main firewall list where rules a re put manually. > If not, the only problem I'd have is that my ipfw startup script adds > about 20,000 rules on a reboot. 20,000 rules multiplied by any > significant amount of time would be bad, just from a > reboot-recovery-time angle. But, if it improved overall performance, I > probably wouldn't mind too much. :) now, what could I add to the firewall to make that come down to, say, 100 rules? I have the following in my list of things to add: ** adding of 'variables (registers) to hold values for the duration of the filter run. ** ipfw add 100 set (register number) value ipfw add 100 set (register number) tablearg ip from table (x) to any ipfw [action] if (register number) gt value (lt,le,ge,eq,neq) ipfw [action] if (register number) in table (x) (registers and table values can be addresses) ** computed skipto ** ipfw skipto tablearg ip from table (2) to any ** adding items to tables automatically ** ipfw loadto table 3 (source, value) ip from any to table (3) ** ability to select WHICH table arg ** ipfw skipto tablearg2 ip from table (1) to table (2) >