From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 20 11:06:54 2009 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D0DE1065675 for ; Mon, 20 Apr 2009 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1A6A38FC21 for ; Mon, 20 Apr 2009 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3KB6rVV033051 for ; Mon, 20 Apr 2009 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3KB6rBD033047 for freebsd-ipfw@FreeBSD.org; Mon, 20 Apr 2009 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Apr 2009 11:06:53 GMT Message-Id: <200904201106.n3KB6rBD033047@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 11:06:54 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 57 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 23 13:42:17 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405F2106566B for ; Thu, 23 Apr 2009 13:42:17 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [189.91.0.40]) by mx1.freebsd.org (Postfix) with SMTP id 6A43E8FC21 for ; Thu, 23 Apr 2009 13:42:15 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 20574 invoked by uid 1008); 23 Apr 2009 13:15:35 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-unknown (2008-06-10) on srvmail1 X-Spam-Level: X-Spam-Status: No, score=-0.4 required=4.8 tests=BAYES_00,RDNS_NONE, SUBJ_ALL_CAPS autolearn=no version=3.2.5-unknown Received: from unknown (HELO ?192.168.0.169?) (daniel@dgnetwork.com.br@189.91.0.65) by mail.mastercabo.com.br with SMTP; 23 Apr 2009 13:15:35 -0000 Message-ID: <49F06985.1000303@yan.com.br> Date: Thu, 23 Apr 2009 10:13:41 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 23 Apr 2009 14:12:44 +0000 Cc: Subject: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ddg@yan.com.br List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 13:42:17 -0000 Hi, My system is a FreeBSD 7.1R. When I add rules IPFW COUNT to 254 IPS from my network, one of my interfaces increases the latency, causing large delays in the network, when I delete COUNT rules, everything returns to normal, which can be ? My script: ipcount.php -- CUT -- -- CUT -- net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 262 net.inet.ip.fw.dyn_max: 10000 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 10000 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 1 net.inet.ip.fw.debug: 0 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 net.link.ether.ipfw: 1 net.link.bridge.ipfw: 0 net.link.bridge.ipfw_arp: 0 Thanks, Daniel From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 23 14:51:24 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23F8A1065677 for ; Thu, 23 Apr 2009 14:51:24 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: from ibctech.ca (v6.ibctech.ca [IPv6:2607:f118::b6]) by mx1.freebsd.org (Postfix) with SMTP id AA9D58FC1A for ; Thu, 23 Apr 2009 14:51:23 +0000 (UTC) (envelope-from steve@ibctech.ca) Received: (qmail 87495 invoked by uid 89); 23 Apr 2009 14:52:21 -0000 Received: from unknown (HELO ?IPv6:2607:f118::5?) (steve@ibctech.ca@2607:f118::5) by 2607:f118::b6 with ESMTPA; 23 Apr 2009 14:52:21 -0000 Message-ID: <49F08071.1070905@ibctech.ca> Date: Thu, 23 Apr 2009 10:51:29 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ddg@yan.com.br References: <49F06985.1000303@yan.com.br> In-Reply-To: <49F06985.1000303@yan.com.br> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:51:24 -0000 Daniel Dias Gonçalves wrote: > Hi, > > My system is a FreeBSD 7.1R. > When I add rules IPFW COUNT to 254 IPS from my network, one of my > interfaces increases the latency, causing large delays in the network, > when I delete COUNT rules, everything returns to normal, which can be ? How much latency? Can you provide examples of a with and without the count rules? What type of hardware are you testing this on? Steve From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 23 15:11:35 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45DDF1065670; Thu, 23 Apr 2009 15:11:35 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 1FC338FC14; Thu, 23 Apr 2009 15:11:34 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (vanquish.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Thu, 23 Apr 2009 11:01:25 -0400 id 00056405.0000000049F082C5.000091CE Date: Thu, 23 Apr 2009 11:01:24 -0400 From: Bill Moran To: ddg@yan.com.br Message-Id: <20090423110124.85788142.wmoran@collaborativefusion.com> In-Reply-To: <49F06985.1000303@yan.com.br> References: <49F06985.1000303@yan.com.br> Organization: Collaborative Fusion Inc. X-Mailer: Sylpheed 2.6.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:11:35 -0000 In response to Daniel Dias Gon=E7alves : >=20 > My system is a FreeBSD 7.1R. > When I add rules IPFW COUNT to 254 IPS from my network, one of my=20 > interfaces increases the latency, causing large delays in the network,=20 > when I delete COUNT rules, everything returns to normal, which can be ? Not sure what you mean by the "which can be" part of the question. But the answer, is "of course latency increases". Did you expect that this kind of traffic tracking to be free? It's not on any operating system or other networking device in existence. It takes CPU cycles and memory to do the tracking, and flipping bits in memory takes time. Therefore, your latency will increase when you add 512 counters to your rules. It's the overhead associated with such logging. Of course, you don't mention _how_much_ latency increases. I can only assume that it's to a degree that you find unacceptable. You also don't mention what hardware you're doing this on, but I would expect that on sufficiently beefy hardware the added latency is low enough not to be a problem. However, without those details, I expect that the following answer is the best you're going to get: If you need to so such logging and the latency increase is unacceptable, then get faster hardware to do it on or concoct some method to do it out of band so that the latency doesn't slow down the connections. > My script: >=20 > ipcount.php > -- CUT -- > $c=3D0; > $a=3D50100; > for($x=3D0;$x<=3D0;$x++) { > for($y=3D1;$y<=3D254;$y++) { > $ip =3D "192.168.$x.$y"; > system("/sbin/ipfw -q add $a count { tcp or udp } from=20 > any to $ip/32"); > system("/sbin/ipfw -q add $a count { tcp or udp } from=20 > $ip/32 to any"); > #system("/sbin/ipfw delete $a"); > $c++; > $a++; > } > } > echo "\n\nTotal: $c\n"; > ?> > -- CUT -- >=20 > net.inet.ip.fw.dyn_keepalive: 1 > net.inet.ip.fw.dyn_short_lifetime: 5 > net.inet.ip.fw.dyn_udp_lifetime: 10 > net.inet.ip.fw.dyn_rst_lifetime: 1 > net.inet.ip.fw.dyn_fin_lifetime: 1 > net.inet.ip.fw.dyn_syn_lifetime: 20 > net.inet.ip.fw.dyn_ack_lifetime: 300 > net.inet.ip.fw.static_count: 262 > net.inet.ip.fw.dyn_max: 10000 > net.inet.ip.fw.dyn_count: 0 > net.inet.ip.fw.curr_dyn_buckets: 256 > net.inet.ip.fw.dyn_buckets: 10000 > net.inet.ip.fw.default_rule: 65535 > net.inet.ip.fw.verbose_limit: 0 > net.inet.ip.fw.verbose: 1 > net.inet.ip.fw.debug: 0 > net.inet.ip.fw.one_pass: 1 > net.inet.ip.fw.autoinc_step: 100 > net.inet.ip.fw.enable: 1 > net.link.ether.ipfw: 1 > net.link.bridge.ipfw: 0 > net.link.bridge.ipfw_arp: 0 >=20 > Thanks, >=20 > Daniel > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 23 17:39:43 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46F6A1065673 for ; Thu, 23 Apr 2009 17:39:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7078FC15 for ; Thu, 23 Apr 2009 17:39:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 17A501181B6; Thu, 23 Apr 2009 10:39:43 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 278CC2D61A0; Thu, 23 Apr 2009 10:39:42 -0700 (PDT) Message-ID: <49F0A7DD.30206@elischer.org> Date: Thu, 23 Apr 2009 10:39:41 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: ddg@yan.com.br References: <49F06985.1000303@yan.com.br> In-Reply-To: <49F06985.1000303@yan.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 17:39:43 -0000 Daniel Dias Gonçalves wrote: > Hi, > > My system is a FreeBSD 7.1R. > When I add rules IPFW COUNT to 254 IPS from my network, one of my > interfaces increases the latency, causing large delays in the network, > when I delete COUNT rules, everything returns to normal, which can be ? > > My script: of course adding 512 rules, *all of which hav eto be evaluated* will add latency. you have several ways to improve this situation. 1/ use a differnet tool. By using the netgraph netflow module you can get accunting information that may be more useful and less impactful. 2/ you could make your rules smarter.. use skipto rules to make the average packet traverse less rules.. off the top of my head.. (not tested..) Assuming you have machines 10.0.0.1-10.0.0.254.... the rules below have an average packet traversing 19 rules and not 256 for teh SYN packet and 2 rules for others.. you may not be able to do the keep state trick if you use state for other stuff but in that case worst case will still be 19 rules. 2 check-state 5 skipto 10000 ip from not 10.0.0.0/24 to any 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 [16 count rules for 0-15] 80 skipto 10000 ip from any to any 100 [16 count rules for 16-31] keep-state 140 skipto 10000 ip from any to any 240 skipto 300 ip from not 10.0.0.32/28 [16 rules for 32-47] keep-state 280 skipto 10000 ip from any to any 300 [16 count rules for 48-63] keep-state 340 skipto 10000 ip from any to any 1030 skipto 1240 ip from not 10.0.0.64/27 to any 1040 skipto 1100 ip from not 10.0.0.64/28 to any [16 count rules for 64-79] keep-state 1080 skipto 10000 ip from any to any 1100 [16 rules for 80-95] keep-state 1140 skipto 10000 ip from any to any 1240 skipto 1300 ip from not 10.0.0.96/28 to any [16 count rules for 96-111] keep-state 1280 skipto 10000 ip from any to any 1300 [16 rules for 112-127] keep-state 1340 skipto 10000 ip from any to any 2020 skipto 3030 ip from not 10.0.0.128/26 to any 2030 skipto 2240 ip from not 10.0.0.128/28 to any [16 count rules for 128-143] keep-state 2080 skipto 10000 ip from any to any 2100 [16 rules for 144-159] keep-state 2140 skipto 10000 ip from any to any 2240 skipto 2300 ip from not 10.0.0.32/28 to any [16 count rules for 160-175] keep-state 2280 skipto 10000 ip from any to any 2300 [16 count rules for 176-191] keep-state 2340 skipto 10000 ip from any to any 3030 skipto 3240 ip from not 10.0.0.192/27 to any 3040 skipto 3100 ip from not 10.0.0.192/28 to any [16 count rules for 192-207] keep-state 3080 skipto 10000 ip from any to any 3100 [16 rules for 208-223] keep-state 3240 skipto 10000 ip from any to any 3240 skipto 3300 ip from not 10.0.0.224/28 to any [16 count rules for 224-239] keep-state 3280 skipto 10000 ip from any to any 3300 [16 count rules for 240-255] keep-state 3340 skipto 10000 ip from any to any 10000 #other stuff in fact you could improve it further with: 1/ either going down to a netmask of 29 (8 rules per set) or 2/ instead of having count rules make them skipto so you would have: 3300 skipto 10000 ip from 10.0.0.240 to any 3301 skipto 10000 ip from 10.0.0.241 to any 3302 skipto 10000 ip from 10.0.0.242 to any 3303 skipto 10000 ip from 10.0.0.243 to any 3304 skipto 10000 ip from 10.0.0.244 to any 3305 skipto 10000 ip from 10.0.0.245 to any 3306 skipto 10000 ip from 10.0.0.246 to any 3307 skipto 10000 ip from 10.0.0.247 to any 3308 skipto 10000 ip from 10.0.0.248 to any 3309 skipto 10000 ip from 10.0.0.249 to any 3310 skipto 10000 ip from 10.0.0.240 to any 3311 skipto 10000 ip from 10.0.0.241 to any 3312 skipto 10000 ip from 10.0.0.242 to any 3313 skipto 10000 ip from 10.0.0.243 to any 3314 skipto 10000 ip from 10.0.0.244 to any 3315 skipto 10000 ip from 10.0.0.245 to any thus on average, a packet would traverse half the rules (8). 3/ both the above so on average they would traverse 4 rules plus one extra skipto. you should be able to do the above in a script. I'd love to see it.. (you can also do skipto tablearg in -current (maybe 7.2 too) which may also be good.. (or not)) julian From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 24 15:26:12 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD3A5106566C for ; Fri, 24 Apr 2009 15:26:12 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [189.91.0.40]) by mx1.freebsd.org (Postfix) with SMTP id 127B28FC1A for ; Fri, 24 Apr 2009 15:26:11 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 35321 invoked by uid 1008); 24 Apr 2009 15:26:09 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-unknown (2008-06-10) on srvmail2 X-Spam-Level: X-Spam-Status: No, score=-1.3 required=4.8 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5-unknown Received: from unknown (HELO ?10.0.1.10?) (daniel@dgnetwork.com.br@200.243.216.68) by mail.mastercabo.com.br with SMTP; 24 Apr 2009 15:26:08 -0000 Message-ID: <49F1D992.9000001@yan.com.br> Date: Fri, 24 Apr 2009 12:24:02 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Steve Bertrand References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> In-Reply-To: <49F08071.1070905@ibctech.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ddg@yan.com.br List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 15:26:13 -0000 The latency in the interface em6 increased an average of 10ms to 200 ~ 300ms Hardware: CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU) Logical CPUs per core: 2 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 cpu2: on acpi0 p4tcc2: on cpu2 cpu3: on acpi0 p4tcc3: on cpu3 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! real memory = 9663676416 (9216 MB) avail memory = 8396738560 (8007 MB) em0: port 0x7000-0x703f mem 0xdfa00000-0xdfa1ffff irq 16 at device 8.0 on pci4 em1: port 0x7400-0x743f mem 0xdfa20000-0xdfa3ffff irq 17 at device 8.1 on pci4 em2: port 0x8000-0x803f mem 0xdfb00000-0xdfb1ffff irq 16 at device 8.0 on pci5 em3: port 0x8400-0x843f mem 0xdfb20000-0xdfb3ffff irq 17 at device 8.1 on pci5 em4: port 0x9000-0x903f mem 0xdfc00000-0xdfc1ffff irq 16 at device 8.0 on pci7 em5: port 0x9400-0x943f mem 0xdfc20000-0xdfc3ffff irq 17 at device 8.1 on pci7 em6: port 0xa000-0xa03f mem 0xdfd00000-0xdfd1ffff irq 16 at device 8.0 on pci8 em7: port 0xa400-0xa43f mem 0xdfd20000-0xdfd3ffff irq 17 at device 8.1 on pci8 fxp0: port 0xb000-0xb03f mem 0xdfe20000-0xdfe20fff,0xdfe00000-0xdfe1ffff irq 16 at device 4.0 on pci14 Steve Bertrand escreveu: > Daniel Dias Gonçalves wrote: > >> Hi, >> >> My system is a FreeBSD 7.1R. >> When I add rules IPFW COUNT to 254 IPS from my network, one of my >> interfaces increases the latency, causing large delays in the network, >> when I delete COUNT rules, everything returns to normal, which can be ? >> > > How much latency? Can you provide examples of a with and without the > count rules? What type of hardware are you testing this on? > > Steve > > > From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 24 15:35:05 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4F02106564A for ; Fri, 24 Apr 2009 15:35:05 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [189.91.0.40]) by mx1.freebsd.org (Postfix) with SMTP id EB2AB8FC14 for ; Fri, 24 Apr 2009 15:35:04 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 14367 invoked by uid 1008); 24 Apr 2009 15:35:03 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-unknown (2008-06-10) on srvmail1 X-Spam-Level: X-Spam-Status: No, score=-0.4 required=4.8 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5-unknown Received: from unknown (HELO ?10.0.1.10?) (daniel@dgnetwork.com.br@200.243.216.68) by mail.mastercabo.com.br with SMTP; 24 Apr 2009 15:35:02 -0000 Message-ID: <49F1DBAE.1080205@yan.com.br> Date: Fri, 24 Apr 2009 12:33:02 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Julian Elischer References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> In-Reply-To: <49F0A7DD.30206@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ddg@yan.com.br List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 15:35:06 -0000 Very good thinking, congratulations, but my need is another. The objective is a Captive Porrtal that each authentication is dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm testing is what is the maximum capacity of rules supported, therefore simultaneous user. Understand ? Thanks, Daniel Julian Elischer escreveu: > Daniel Dias Gonçalves wrote: >> Hi, >> >> My system is a FreeBSD 7.1R. >> When I add rules IPFW COUNT to 254 IPS from my network, one of my >> interfaces increases the latency, causing large delays in the >> network, when I delete COUNT rules, everything returns to normal, >> which can be ? >> >> My script: > > of course adding 512 rules, *all of which hav eto be evaluated* will > add latency. > > you have several ways to improve this situation. > > 1/ use a differnet tool. > By using the netgraph netflow module you can get > accunting information that may be more useful and less impactful. > > 2/ you could make your rules smarter.. > > use skipto rules to make the average packet traverse less rules.. > > off the top of my head.. (not tested..) > > Assuming you have machines 10.0.0.1-10.0.0.254.... > the rules below have an average packet traversing 19 rules and not 256 > for teh SYN packet and 2 rules for others.. > you may not be able to do the keep state trick if you use state for > other stuff but in that case worst case will still be 19 rules. > > 2 check-state > 5 skipto 10000 ip from not 10.0.0.0/24 to any > 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 > 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 > 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 > 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 > [16 count rules for 0-15] > 80 skipto 10000 ip from any to any > 100 [16 count rules for 16-31] keep-state > 140 skipto 10000 ip from any to any > 240 skipto 300 ip from not 10.0.0.32/28 > [16 rules for 32-47] keep-state > 280 skipto 10000 ip from any to any > 300 [16 count rules for 48-63] keep-state > 340 skipto 10000 ip from any to any > 1030 skipto 1240 ip from not 10.0.0.64/27 to any > 1040 skipto 1100 ip from not 10.0.0.64/28 to any > [16 count rules for 64-79] keep-state > 1080 skipto 10000 ip from any to any > 1100 [16 rules for 80-95] keep-state > 1140 skipto 10000 ip from any to any > 1240 skipto 1300 ip from not 10.0.0.96/28 to any > [16 count rules for 96-111] keep-state > 1280 skipto 10000 ip from any to any > 1300 [16 rules for 112-127] keep-state > 1340 skipto 10000 ip from any to any > 2020 skipto 3030 ip from not 10.0.0.128/26 to any > 2030 skipto 2240 ip from not 10.0.0.128/28 to any > [16 count rules for 128-143] keep-state > 2080 skipto 10000 ip from any to any > 2100 [16 rules for 144-159] keep-state > 2140 skipto 10000 ip from any to any > 2240 skipto 2300 ip from not 10.0.0.32/28 to any > [16 count rules for 160-175] keep-state > 2280 skipto 10000 ip from any to any > 2300 [16 count rules for 176-191] keep-state > 2340 skipto 10000 ip from any to any > 3030 skipto 3240 ip from not 10.0.0.192/27 to any > 3040 skipto 3100 ip from not 10.0.0.192/28 to any > [16 count rules for 192-207] keep-state > 3080 skipto 10000 ip from any to any > 3100 [16 rules for 208-223] keep-state > 3240 skipto 10000 ip from any to any > 3240 skipto 3300 ip from not 10.0.0.224/28 to any > [16 count rules for 224-239] keep-state > 3280 skipto 10000 ip from any to any > 3300 [16 count rules for 240-255] keep-state > 3340 skipto 10000 ip from any to any > > 10000 #other stuff > > in fact you could improve it further with: > 1/ either going down to a netmask of 29 (8 rules per set) > or > 2/ instead of having count rules make them skipto > so you would have: > 3300 skipto 10000 ip from 10.0.0.240 to any > 3301 skipto 10000 ip from 10.0.0.241 to any > 3302 skipto 10000 ip from 10.0.0.242 to any > 3303 skipto 10000 ip from 10.0.0.243 to any > 3304 skipto 10000 ip from 10.0.0.244 to any > 3305 skipto 10000 ip from 10.0.0.245 to any > 3306 skipto 10000 ip from 10.0.0.246 to any > 3307 skipto 10000 ip from 10.0.0.247 to any > 3308 skipto 10000 ip from 10.0.0.248 to any > 3309 skipto 10000 ip from 10.0.0.249 to any > 3310 skipto 10000 ip from 10.0.0.240 to any > 3311 skipto 10000 ip from 10.0.0.241 to any > 3312 skipto 10000 ip from 10.0.0.242 to any > 3313 skipto 10000 ip from 10.0.0.243 to any > 3314 skipto 10000 ip from 10.0.0.244 to any > 3315 skipto 10000 ip from 10.0.0.245 to any > > thus on average, a packet would traverse half the rules (8). > > 3/ both the above so on average they would traverse 4 rules plus one > extra skipto. > > you should be able to do the above in a script. > I'd love to see it.. > > (you can also do skipto tablearg in -current (maybe 7.2 too) > which may also be good.. (or not)) > > > julian > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 24 16:42:03 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 555BF10656A9; Fri, 24 Apr 2009 16:42:03 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 16DAE8FC20; Fri, 24 Apr 2009 16:42:02 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (vanquish.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Fri, 24 Apr 2009 12:42:02 -0400 id 000564DD.0000000049F1EBDA.0000E0CB Date: Fri, 24 Apr 2009 12:42:02 -0400 From: Bill Moran To: ddg@yan.com.br Message-Id: <20090424124202.951a82e1.wmoran@collaborativefusion.com> In-Reply-To: <49F1DBAE.1080205@yan.com.br> References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> <49F1DBAE.1080205@yan.com.br> Organization: Collaborative Fusion Inc. X-Mailer: Sylpheed 2.6.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ipfw@freebsd.org, Julian Elischer , freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 16:42:03 -0000 In response to Daniel Dias Gon=E7alves : > Very good thinking, congratulations, but my need is another. > The objective is a Captive Porrtal that each authentication is=20 > dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm= =20 > testing is what is the maximum capacity of rules supported, therefore=20 > simultaneous user. >=20 > Understand ? If you're only doing allow, then you'd be better off using a table, which has much better performance than a bunch of separate rules. If you're counting packets, I don't know if that approach will work or not. --=20 Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 24 17:11:12 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 633C2106566C for ; Fri, 24 Apr 2009 17:11:12 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 118E88FC1E for ; Fri, 24 Apr 2009 17:11:10 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n3OH0Bpc070463; Sat, 25 Apr 2009 03:00:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 25 Apr 2009 03:00:11 +1000 (EST) From: Ian Smith To: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= In-Reply-To: <49F1D992.9000001@yan.com.br> Message-ID: <20090425024635.O89549@sola.nimnet.asn.au> References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> <49F1D992.9000001@yan.com.br> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1854651572-1240592411=:89549" Cc: freebsd-ipfw@freebsd.org, Steve Bertrand Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 17:11:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1854651572-1240592411=:89549 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 24 Apr 2009, Daniel Dias Gonçalves wrote: > The latency in the interface em6 increased an average of 10ms to 200 ~ 300ms > Hardware: > CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3200.13-MHz 686-class CPU) > Logical CPUs per core: 2 > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0: on acpi0 > p4tcc0: on cpu0 > cpu1: on acpi0 > p4tcc1: on cpu1 > cpu2: on acpi0 > p4tcc2: on cpu2 > cpu3: on acpi0 > p4tcc3: on cpu3 > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > > real memory = 9663676416 (9216 MB) > avail memory = 8396738560 (8007 MB) In that case, there really is something else wrong. By my measurements, rummaging through most of >1000 rules on a old 166MHz Pentium to get to the icmp allow rules (ridiculous, I know) added about 2ms to local net pings via that box, ie 1ms each pass for about 900 rules, mostly counts. cheers, Ian --0-1854651572-1240592411=:89549-- From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 24 17:15:19 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F15010656D4 for ; Fri, 24 Apr 2009 17:15:19 +0000 (UTC) (envelope-from Anatoliy.Poloz@onetelecom.od.ua) Received: from main.merlin.com.ua (mail.onetelecom.od.ua [91.194.72.4]) by mx1.freebsd.org (Postfix) with ESMTP id D6E4B8FC1D for ; Fri, 24 Apr 2009 17:15:18 +0000 (UTC) (envelope-from Anatoliy.Poloz@onetelecom.od.ua) Received: from [192.168.67.95] (t0ly [192.168.67.95]) by main.merlin.com.ua (Postmaster) with ESMTP id 8072E5DCD72; Fri, 24 Apr 2009 20:04:07 +0300 (EEST) Message-ID: <49F1EFA4.7000107@onetelecom.od.ua> Date: Fri, 24 Apr 2009 19:58:12 +0300 From: "Anatoliy.Poloz" User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Bill Moran References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> <49F1DBAE.1080205@yan.com.br> <20090424124202.951a82e1.wmoran@collaborativefusion.com> In-Reply-To: <20090424124202.951a82e1.wmoran@collaborativefusion.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, Julian Elischer , ddg@yan.com.br, freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anatoliy.Poloz@onetelecom.od.ua List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 17:15:20 -0000 Bill Moran wrote: > In response to Daniel Dias Gonçalves : > >> Very good thinking, congratulations, but my need is another. >> The objective is a Captive Porrtal that each authentication is >> dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm >> testing is what is the maximum capacity of rules supported, therefore >> simultaneous user. >> >> Understand ? > > If you're only doing allow, then you'd be better off using a table, > which has much better performance than a bunch of separate rules. > > If you're counting packets, I don't know if that approach will work > or not. > if u need to count ip traffic for all clients u can use sipmple and more performance rule set, like this one: LOCAL_NET=192.168.0.0/24 ipfw pipe 100 config bw 0 mask src-ip 0xffffffff ipfw pipe 100 config bw 0 mask dst-ip 0xffffffff ipfw add 100 pipe 100 ip from ${LOCAL_NET} to any out ipfw add 200 pipe 200 ip from any to ${LOCAL_NET} in From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 24 17:31:15 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BFEF106566B for ; Fri, 24 Apr 2009 17:31:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qy0-f105.google.com (mail-qy0-f105.google.com [209.85.221.105]) by mx1.freebsd.org (Postfix) with ESMTP id 50F3B8FC20 for ; Fri, 24 Apr 2009 17:31:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qyk3 with SMTP id 3so2457167qyk.3 for ; Fri, 24 Apr 2009 10:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Dms0aXVyhyq29rkfEOyttN+NXXccjrmEfnka+0/kv7I=; b=OtUp3YVEfQgPqtCuCfKprgsjIKoAVzn/4h1uRmD2+mSxIOHwB3huYGtnKnFZxJhCdU 8G3pWVRJNUkG22moEz7bemUWX5JmTjp2Ajz+/6s/uSyTK6simNx8zyY/55YFo2R4HA8d H62gnrPM+VY8XMbeJ5f+tuvAVjIFYbJUt45JQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vqH1WU6EJtSQgiC1e7+aonJbHyMI1w22RPiLJD3FZXmY+D96L79QrPqse/24ojsjir eFzRqk1DLO4xLjpYRwRXdFfp+UlLKIwQAKTezuhWstWQB6/aLRBj7yYVoqjR2a7twKCg FtbRwf0Mjl3m+CJLJKwWnektxTl2E9vxs8ZSA= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.85.143 with SMTP id o15mr1663377qcl.1.1240592805948; Fri, 24 Apr 2009 10:06:45 -0700 (PDT) In-Reply-To: <49F06985.1000303@yan.com.br> References: <49F06985.1000303@yan.com.br> Date: Sat, 25 Apr 2009 01:06:45 +0800 X-Google-Sender-Auth: a837a73ca830f1b9 Message-ID: From: Adrian Chadd To: ddg@yan.com.br Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 17:31:16 -0000 You'd almost certainly be better off hacking up an extension to ipfw which lets you count a /24 in one rule. As in, the count rule would match on the subnet/netmask, have 256 32 (or 64 bit) integers allocated to record traffic in, and then do an O(1) operation using the last octet of the v4 address to map it into this 256 slot array to update counters for. It'd require a little tool hackery to extend ipfw in userland/kernel space to do it but it would work and be (very almost) just as fast as a single rule. 2c, Adrian 2009/4/23 Daniel Dias Gon=E7alves : > Hi, > > My system is a FreeBSD 7.1R. > When I add rules IPFW COUNT to 254 IPS from my network, one of my interfa= ces > increases the latency, causing large delays in the network, when I delete > COUNT rules, everything returns to normal, which can be ? > > My script: > > ipcount.php > -- CUT -- > $c=3D0; > $a=3D50100; > for($x=3D0;$x<=3D0;$x++) { > =A0 =A0 =A0 for($y=3D1;$y<=3D254;$y++) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 $ip =3D "192.168.$x.$y"; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 system("/sbin/ipfw -q add $a count { tcp or u= dp } from any to > $ip/32"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 system("/sbin/ipfw -q add $a count { tcp or u= dp } from $ip/32 > to any"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 #system("/sbin/ipfw delete $a"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 $c++; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 $a++; > =A0 =A0 =A0 } > } > echo "\n\nTotal: $c\n"; > ?> > -- CUT -- > > net.inet.ip.fw.dyn_keepalive: 1 > net.inet.ip.fw.dyn_short_lifetime: 5 > net.inet.ip.fw.dyn_udp_lifetime: 10 > net.inet.ip.fw.dyn_rst_lifetime: 1 > net.inet.ip.fw.dyn_fin_lifetime: 1 > net.inet.ip.fw.dyn_syn_lifetime: 20 > net.inet.ip.fw.dyn_ack_lifetime: 300 > net.inet.ip.fw.static_count: 262 > net.inet.ip.fw.dyn_max: 10000 > net.inet.ip.fw.dyn_count: 0 > net.inet.ip.fw.curr_dyn_buckets: 256 > net.inet.ip.fw.dyn_buckets: 10000 > net.inet.ip.fw.default_rule: 65535 > net.inet.ip.fw.verbose_limit: 0 > net.inet.ip.fw.verbose: 1 > net.inet.ip.fw.debug: 0 > net.inet.ip.fw.one_pass: 1 > net.inet.ip.fw.autoinc_step: 100 > net.inet.ip.fw.enable: 1 > net.link.ether.ipfw: 1 > net.link.bridge.ipfw: 0 > net.link.bridge.ipfw_arp: 0 > > Thanks, > > Daniel > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 24 21:58:15 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A62D1065678 for ; Fri, 24 Apr 2009 21:58:15 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id DF3208FC16 for ; Fri, 24 Apr 2009 21:58:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 624B814E101; Fri, 24 Apr 2009 14:58:46 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 774D52D605D; Fri, 24 Apr 2009 14:58:13 -0700 (PDT) Message-ID: <49F235F4.2030202@elischer.org> Date: Fri, 24 Apr 2009 14:58:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: ddg@yan.com.br References: <49F06985.1000303@yan.com.br> <49F0A7DD.30206@elischer.org> <49F1DBAE.1080205@yan.com.br> In-Reply-To: <49F1DBAE.1080205@yan.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW MAX RULES COUNT PERFORMANCE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 21:58:16 -0000 Daniel Dias Gonçalves wrote: > Very good thinking, congratulations, but my need is another. > The objective is a Captive Porrtal that each authentication is > dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm > testing is what is the maximum capacity of rules supported, therefore > simultaneous user. > > Understand ? > I think so. do not add rules. have a single rule that looks in a table and add entries to the table when needed. > Thanks, > > Daniel > > Julian Elischer escreveu: >> Daniel Dias Gonçalves wrote: >>> Hi, >>> >>> My system is a FreeBSD 7.1R. >>> When I add rules IPFW COUNT to 254 IPS from my network, one of my >>> interfaces increases the latency, causing large delays in the >>> network, when I delete COUNT rules, everything returns to normal, >>> which can be ? >>> >>> My script: >> >> of course adding 512 rules, *all of which hav eto be evaluated* will >> add latency. >> >> you have several ways to improve this situation. >> >> 1/ use a differnet tool. >> By using the netgraph netflow module you can get >> accunting information that may be more useful and less impactful. >> >> 2/ you could make your rules smarter.. >> >> use skipto rules to make the average packet traverse less rules.. >> >> off the top of my head.. (not tested..) >> >> Assuming you have machines 10.0.0.1-10.0.0.254.... >> the rules below have an average packet traversing 19 rules and not 256 >> for teh SYN packet and 2 rules for others.. >> you may not be able to do the keep state trick if you use state for >> other stuff but in that case worst case will still be 19 rules. >> >> 2 check-state >> 5 skipto 10000 ip from not 10.0.0.0/24 to any >> 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 >> 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 >> 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 >> 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 >> [16 count rules for 0-15] >> 80 skipto 10000 ip from any to any >> 100 [16 count rules for 16-31] keep-state >> 140 skipto 10000 ip from any to any >> 240 skipto 300 ip from not 10.0.0.32/28 >> [16 rules for 32-47] keep-state >> 280 skipto 10000 ip from any to any >> 300 [16 count rules for 48-63] keep-state >> 340 skipto 10000 ip from any to any >> 1030 skipto 1240 ip from not 10.0.0.64/27 to any >> 1040 skipto 1100 ip from not 10.0.0.64/28 to any >> [16 count rules for 64-79] keep-state >> 1080 skipto 10000 ip from any to any >> 1100 [16 rules for 80-95] keep-state >> 1140 skipto 10000 ip from any to any >> 1240 skipto 1300 ip from not 10.0.0.96/28 to any >> [16 count rules for 96-111] keep-state >> 1280 skipto 10000 ip from any to any >> 1300 [16 rules for 112-127] keep-state >> 1340 skipto 10000 ip from any to any >> 2020 skipto 3030 ip from not 10.0.0.128/26 to any >> 2030 skipto 2240 ip from not 10.0.0.128/28 to any >> [16 count rules for 128-143] keep-state >> 2080 skipto 10000 ip from any to any >> 2100 [16 rules for 144-159] keep-state >> 2140 skipto 10000 ip from any to any >> 2240 skipto 2300 ip from not 10.0.0.32/28 to any >> [16 count rules for 160-175] keep-state >> 2280 skipto 10000 ip from any to any >> 2300 [16 count rules for 176-191] keep-state >> 2340 skipto 10000 ip from any to any >> 3030 skipto 3240 ip from not 10.0.0.192/27 to any >> 3040 skipto 3100 ip from not 10.0.0.192/28 to any >> [16 count rules for 192-207] keep-state >> 3080 skipto 10000 ip from any to any >> 3100 [16 rules for 208-223] keep-state >> 3240 skipto 10000 ip from any to any >> 3240 skipto 3300 ip from not 10.0.0.224/28 to any >> [16 count rules for 224-239] keep-state >> 3280 skipto 10000 ip from any to any >> 3300 [16 count rules for 240-255] keep-state >> 3340 skipto 10000 ip from any to any >> >> 10000 #other stuff >> >> in fact you could improve it further with: >> 1/ either going down to a netmask of 29 (8 rules per set) >> or >> 2/ instead of having count rules make them skipto >> so you would have: >> 3300 skipto 10000 ip from 10.0.0.240 to any >> 3301 skipto 10000 ip from 10.0.0.241 to any >> 3302 skipto 10000 ip from 10.0.0.242 to any >> 3303 skipto 10000 ip from 10.0.0.243 to any >> 3304 skipto 10000 ip from 10.0.0.244 to any >> 3305 skipto 10000 ip from 10.0.0.245 to any >> 3306 skipto 10000 ip from 10.0.0.246 to any >> 3307 skipto 10000 ip from 10.0.0.247 to any >> 3308 skipto 10000 ip from 10.0.0.248 to any >> 3309 skipto 10000 ip from 10.0.0.249 to any >> 3310 skipto 10000 ip from 10.0.0.240 to any >> 3311 skipto 10000 ip from 10.0.0.241 to any >> 3312 skipto 10000 ip from 10.0.0.242 to any >> 3313 skipto 10000 ip from 10.0.0.243 to any >> 3314 skipto 10000 ip from 10.0.0.244 to any >> 3315 skipto 10000 ip from 10.0.0.245 to any >> >> thus on average, a packet would traverse half the rules (8). >> >> 3/ both the above so on average they would traverse 4 rules plus one >> extra skipto. >> >> you should be able to do the above in a script. >> I'd love to see it.. >> >> (you can also do skipto tablearg in -current (maybe 7.2 too) >> which may also be good.. (or not)) >> >> >> julian >> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >>