From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 27 11:06:56 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 BFAAA1065670 for ; Mon, 27 Apr 2009 11:06:56 +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 ABEDD8FC1E for ; Mon, 27 Apr 2009 11:06:56 +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 n3RB6uj7002325 for ; Mon, 27 Apr 2009 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3RB6u70002321 for freebsd-ipfw@FreeBSD.org; Mon, 27 Apr 2009 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Apr 2009 11:06:56 GMT Message-Id: <200904271106.n3RB6u70002321@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, 27 Apr 2009 11:06:57 -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 Mon Apr 27 16:11:27 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 80DEE1065734 for ; Mon, 27 Apr 2009 16:11:27 +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 5D1DC8FC3B for ; Mon, 27 Apr 2009 16:11:17 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 81338 invoked by uid 1008); 27 Apr 2009 16:11:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-unknown (2008-06-10) on srvmail1 X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.8 tests=AWL,BAYES_00,RDNS_NONE 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; 27 Apr 2009 16:11:15 -0000 Message-ID: <49F5D8A3.3050805@yan.com.br> Date: Mon, 27 Apr 2009 13:09:07 -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> <49F1DBAE.1080205@yan.com.br> <49F235F4.2030202@elischer.org> In-Reply-To: <49F235F4.2030202@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: Mon, 27 Apr 2009 16:11:40 -0000 Julian, You could give an example of rules with tables? Julian Elischer escreveu: > 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" >>> >>> > > _______________________________________________ > 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 Mon Apr 27 16:21:40 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 CD068106566C for ; Mon, 27 Apr 2009 16:21:40 +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 1415A8FC23 for ; Mon, 27 Apr 2009 16:21:39 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 91718 invoked by uid 1008); 27 Apr 2009 16:21:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-unknown (2008-06-10) on srvmail1 X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.8 tests=AWL,BAYES_00,RDNS_NONE 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; 27 Apr 2009 16:21:38 -0000 Message-ID: <49F5DB12.7080502@yan.com.br> Date: Mon, 27 Apr 2009 13:19:30 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ian Smith References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> <49F1D992.9000001@yan.com.br> <20090425024635.O89549@sola.nimnet.asn.au> In-Reply-To: <20090425024635.O89549@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, Steve Bertrand , 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: Mon, 27 Apr 2009 16:21:41 -0000 What may be happening ? I'm with polling enabled on all interfaces, can you influence ? 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 If I disable the polling, no network interface work, begins to display "em4 watchdog timeout". Ian Smith escreveu: > 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 From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 27 16:24:22 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 7B6C9106564A for ; Mon, 27 Apr 2009 16:24:22 +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 D01328FC14 for ; Mon, 27 Apr 2009 16:24:21 +0000 (UTC) (envelope-from ddg@yan.com.br) Received: (qmail 93547 invoked by uid 1008); 27 Apr 2009 16:24:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-unknown (2008-06-10) on srvmail3 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.8 tests=BAYES_00,RDNS_NONE 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; 27 Apr 2009 16:24:19 -0000 Message-ID: <49F5DBB3.6030500@yan.com.br> Date: Mon, 27 Apr 2009 13:22:11 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Adrian Chadd References: <49F06985.1000303@yan.com.br> In-Reply-To: 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: Mon, 27 Apr 2009 16:24:22 -0000 Going to another example. If I wanted that each authentication (username and password) in captive portal, set up rules limiting the speed of the user's IP, as I do? I can create two rules for the in / out for each user associated with a pipe? When simulating this with a script adding hundreds of rules, the latency also increases, as resolve this ? Adrian Chadd escreveu: > 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çalves : > >> 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 -- >> > $c=0; >> $a=50100; >> for($x=0;$x<=0;$x++) { >> for($y=1;$y<=254;$y++) { >> $ip = "192.168.$x.$y"; >> system("/sbin/ipfw -q add $a count { tcp or udp } from any to >> $ip/32"); >> system("/sbin/ipfw -q add $a count { tcp or udp } from $ip/32 >> to any"); >> #system("/sbin/ipfw delete $a"); >> $c++; >> $a++; >> } >> } >> 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" >> >> > _______________________________________________ > 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 Tue Apr 28 03:40:49 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 433161065670; Tue, 28 Apr 2009 03:40:49 +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 D62F68FC19; Tue, 28 Apr 2009 03:40:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qyk3 with SMTP id 3so723256qyk.3 for ; Mon, 27 Apr 2009 20:40:48 -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=U1Taw6rg38DV4UiX+yKbevTRWu+NTeKOJ4UOE4M5Qzw=; b=QkaDm6qR6puuaxymm+Emgedr7DuxD+twrtxpDP9oOkfWWuHjMY3HeEhp3s0Mxif9JK l6dmnXkWWitAlO11wCuCmF56nJYW4MUytDR9GHhnCwUh1mBvKEDpbHIPncpuw6rZv9ww anCdhuOkfTmpJwhEiSfH0bFs0a0xzNVF+sQlA= 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=RKGve2mLzD2KFK13vx7y6GtkF3+pAdQWFz4LXxJ4Uo2kFRhMrrCSEnFx/Ir6nB7quJ 6hYxxNdxQt3DWAcgKthHgapkwUD5y4EHkSSCa7ttnDACWZjZSd1RBd4BoarXpCtpAbHl /A33g9Ql7dZwpQA9eA2CyWasJMXCXEra1/jlM= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.229.96.1 with SMTP id f1mr3346976qcn.103.1240890048184; Mon, 27 Apr 2009 20:40:48 -0700 (PDT) In-Reply-To: <49F5DBB3.6030500@yan.com.br> References: <49F06985.1000303@yan.com.br> <49F5DBB3.6030500@yan.com.br> Date: Tue, 28 Apr 2009 11:40:48 +0800 X-Google-Sender-Auth: 125868ae51dbce0c 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: Tue, 28 Apr 2009 03:40:49 -0000 You may want to investigate using pf; i'm not sure whether they handle this better. Me, I'd investigate writing a "tree" ipfw rule type. Ie, instead of having a list of rules, all evaluated one at a time, I'd create a rule implementing a subrule match on ip/netmask with some kind of action (allow, deny, count, pipe, etc) rather than having it all be evaluated O(n) style. 2c, Adrian 2009/4/28 Daniel Dias Gon=E7alves : > Going to another example. > If I wanted that each authentication (username and password) in captive > portal, set up rules limiting the speed of the user's IP, as I do? I can > create two rules for the in / out for each user associated with a pipe? W= hen > simulating this with a script adding hundreds of rules, the latency also > increases, as resolve this ? > > Adrian Chadd escreveu: >> >> 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 >>> interfaces >>> increases the latency, causing large delays in the network, when I dele= te >>> 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 =A0for($y=3D1;$y<=3D254;$y++) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0$ip =3D "192.168.$x.$y"; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0system("/sbin/ipfw -q add $a count { tcp or = udp } from any >>> to >>> $ip/32"); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0system("/sbin/ipfw -q add $a count { tcp or = udp } 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" >>> >>> >> >> _______________________________________________ >> 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" >> >> >> > > _______________________________________________ > 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 Tue Apr 28 04:33:41 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 1DBBA1065677 for ; Tue, 28 Apr 2009 04:33:41 +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 72F778FC0A for ; Tue, 28 Apr 2009 04:33:40 +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 n3S4XaSZ022453; Tue, 28 Apr 2009 14:33:38 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 28 Apr 2009 14:33:36 +1000 (EST) From: Ian Smith To: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= In-Reply-To: <49F5DB12.7080502@yan.com.br> Message-ID: <20090428135053.Y89549@sola.nimnet.asn.au> References: <49F06985.1000303@yan.com.br> <49F08071.1070905@ibctech.ca> <49F1D992.9000001@yan.com.br> <20090425024635.O89549@sola.nimnet.asn.au> <49F5DB12.7080502@yan.com.br> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1620027708-1240893216=:89549" Cc: freebsd-ipfw@freebsd.org, Steve Bertrand , 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: Tue, 28 Apr 2009 04:33:41 -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-1620027708-1240893216=:89549 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 27 Apr 2009, Daniel Dias Gonçalves wrote: > What may be happening ? I'm with polling enabled on all interfaces, can you > influence ? > > 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 > > If I disable the polling, no network interface work, begins to display "em4 > watchdog timeout". Sorry, no ideas about polling, but this doesn't smell like just an IPFW issue. I was pointing out that despite 20 times the CPU clock rate, probably at least 30 times CPU throughput and likely 10 times the tick rate, you appear to be suffering something like 30 to 900 times the increased latency to be expected by traversing 'too many' ipfw rules. > Ian Smith escreveu: > > 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-1620027708-1240893216=:89549-- From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 28 06:51:59 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 74CAC106564A for ; Tue, 28 Apr 2009 06:51:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 559E38FC0A for ; Tue, 28 Apr 2009 06:51:59 +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 6E02F14DDAD; Mon, 27 Apr 2009 23:51:59 -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 62B7E2D6229; Mon, 27 Apr 2009 23:51:58 -0700 (PDT) Message-ID: <49F6A796.4060100@elischer.org> Date: Mon, 27 Apr 2009 23:52:06 -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> <49F235F4.2030202@elischer.org> <49F5D8A3.3050805@yan.com.br> In-Reply-To: <49F5D8A3.3050805@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: Tue, 28 Apr 2009 06:51:59 -0000 Daniel Dias Gonçalves wrote: > Julian, > > You could give an example of rules with tables? I'm sorry I forgot that you want to count packets from each client. tables won't work for that. for counting I suggest the technique I show below, but for just allowing, you can add allowable addresses to a table, e.g. table 1 add 1.2.3.4 and test it with allow ip from table (1) to any > > Julian Elischer escreveu: >> 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" >>>> >>>> >> >> _______________________________________________ >> 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 May 1 20:22:34 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 42EEE106564A; Fri, 1 May 2009 20:22:34 +0000 (UTC) (envelope-from marta@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 0A74B8FC12; Fri, 1 May 2009 20:22:33 +0000 (UTC) (envelope-from marta@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 1002) id 6CCCD730A1; Fri, 1 May 2009 22:09:31 +0200 (CEST) Date: Fri, 1 May 2009 22:09:31 +0200 From: Marta Carbone To: freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Message-ID: <20090501200931.GA55379@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: SoC2009: Ipfw and dummyent improvements 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, 01 May 2009 20:22:34 -0000 Hello, my name is Marta Carbone, I am at the first year of my PhD program in Information Engineering at the University of Pisa. As part of the Google SoC I will work on FreeBSD ipfw and dummynet. My mentor is Luigi Rizzo. The main goal of the project is to revise and improve the ipfw and dummynet subsystems. The project will mainly involve: - the kernel source code, making it more manageable, splitting large functions, improving the microinstruction compiler; - the userland kernel-interface, identifying locking issues or performance problems. A more detailed version of the proposal can be found on the FreeBSD Wiki page: http://wiki.freebsd.org/SOC2009MartaCarbone marta