From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 24 11:07:05 2011 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 7244B1065674 for ; Mon, 24 Oct 2011 11:07:05 +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 609D48FC12 for ; Mon, 24 Oct 2011 11:07:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9OB75Yf025331 for ; Mon, 24 Oct 2011 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9OB74SQ025329 for freebsd-ipfw@FreeBSD.org; Mon, 24 Oct 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Oct 2011 11:07:04 GMT Message-Id: <201110241107.p9OB74SQ025329@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, 24 Oct 2011 11:07:05 -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/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157796 ipfw [ipfw] IPFW in-kernel NAT nat loopback / Default Route o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int o kern/156770 ipfw [ipfw] [dummynet] [patch]: performance improvement and f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw IPFIREWALL does not allow specify rules with ICMP code o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o f kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n p 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/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/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 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/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw 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 40 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Oct 25 13:46:06 2011 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 C7B35106564A for ; Tue, 25 Oct 2011 13:46:06 +0000 (UTC) (envelope-from gsn.adm@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 986258FC0A for ; Tue, 25 Oct 2011 13:46:06 +0000 (UTC) Received: by iaky10 with SMTP id y10so879780iak.13 for ; Tue, 25 Oct 2011 06:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=lq5sYAgtHyr/+//rq//hMPfUM0YCfHpZlpJquPo9a1g=; b=eJoHn1GweVRah+cg23R/dh+eljXmT/pdf76JwHnLzqf2jpOy0pTe9CGPXlBwIn3SvD Lol9zr+33suwF/blb6pKqRMc8KDUwLXHZ0sQoZjFZ/8jmbKzRGvCUv17aKsHOnPS48f1 McrkJd4x+kE+Ge55N7r7wa9RckR/NNQkIp5nU= MIME-Version: 1.0 Received: by 10.231.27.29 with SMTP id g29mr356760ibc.11.1319548782823; Tue, 25 Oct 2011 06:19:42 -0700 (PDT) Received: by 10.231.155.134 with HTTP; Tue, 25 Oct 2011 06:19:42 -0700 (PDT) Date: Tue, 25 Oct 2011 16:19:42 +0300 Message-ID: From: =?KOI8-R?B?88XSxcfBIOfPzt7B0s/X?= To: freebsd-ipfw@freebsd.org X-Mailman-Approved-At: Tue, 25 Oct 2011 13:47:25 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw features 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, 25 Oct 2011 13:46:06 -0000 Hi all. Is there some plans to make ipfw can change ip header fields of going throught packets, like TTL, DF flag etc. pf and iptables can, so maybe in freebsd 9 it will be implemented? thanks. From owner-freebsd-ipfw@FreeBSD.ORG Tue Oct 25 16:00:15 2011 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 E3919106566B for ; Tue, 25 Oct 2011 16:00:15 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8FBDC8FC13 for ; Tue, 25 Oct 2011 16:00:15 +0000 (UTC) Received: by vcbfo13 with SMTP id fo13so890926vcb.13 for ; Tue, 25 Oct 2011 09:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=RrKKMF0T9BETNzJ1vVf8d5xalxf8RZX4inSUSl1jEwM=; b=genPEZHfAHaNEHAbqAUqV3epg8XEWhT4n9U1hXt9nB8x7BA62hDnurf0QE6/mHAtLB wwmg22i+7og2LZTzrE7Lx0a/qlhQPLaW7cWe4CQU61BBdVNDZHdf697VJuXd3nZ/0WZh WIxUMxQq4Sx1VXqkvnHo5V4t/lp6OoASzZVmE= Received: by 10.52.240.145 with SMTP id wa17mr28361972vdc.118.1319557012728; Tue, 25 Oct 2011 08:36:52 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.101]) by mx.google.com with ESMTPS id hl5sm27942945vdb.18.2011.10.25.08.36.51 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 08:36:51 -0700 (PDT) Message-ID: <4EA6D78F.6010607@gmail.com> Date: Tue, 25 Oct 2011 11:36:47 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ipfw rule processing performances 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, 25 Oct 2011 16:00:16 -0000 Hi all, I am using ipfw with a fairly small amount of rules (~200). Most of those are skipto rules to different blocking and pass-through blocks. I use ipfw tags, ALTQ, nat, fwd and several deny and allow rules and I do not use/need tables. What I find is around 400Mbps of traffic (~40kpps) an extremely high amount of cpu usage related to firewall processing. What I would like to know is if there is an ongoing work to optimise ipfw and/or gather ideas on how to do that. I realise my question has a large scope but I am not interested in optimizing my ruleset I'd like to get a feel for how code wise the current processing could be optimized (using multiple input TX/RX queues for example, etc...). Thanks, Karim. From owner-freebsd-ipfw@FreeBSD.ORG Tue Oct 25 16:51:55 2011 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 7EEA9106566C for ; Tue, 25 Oct 2011 16:51:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 491928FC12 for ; Tue, 25 Oct 2011 16:51:54 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 0EDE47300A; Tue, 25 Oct 2011 18:50:39 +0200 (CEST) Date: Tue, 25 Oct 2011 18:50:39 +0200 From: Luigi Rizzo To: Karim Message-ID: <20111025165039.GA8255@onelab2.iet.unipi.it> References: <4EA6D78F.6010607@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EA6D78F.6010607@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw rule processing performances 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, 25 Oct 2011 16:51:55 -0000 On Tue, Oct 25, 2011 at 11:36:47AM -0400, Karim wrote: > Hi all, > > I am using ipfw with a fairly small amount of rules (~200). Most of > those are skipto rules to different blocking and pass-through blocks. I > use ipfw tags, ALTQ, nat, fwd and several deny and allow rules and I do > not use/need tables. > > What I find is around 400Mbps of traffic (~40kpps) an extremely high > amount of cpu usage related to firewall processing. > > What I would like to know is if there is an ongoing work to optimise > ipfw and/or gather ideas on how to do that. > > I realise my question has a large scope but I am not interested in > optimizing my ruleset I'd like to get a feel for how code wise the > current processing could be optimized (using multiple input TX/RX queues > for example, etc...). we did some performance evaluation a couple of years ago, mostly related to dummynet but there are some ipfw data too. http://info.iet.unipi.it/~luigi/papers/20100304-ccr.pdf in summary, on a modern CPU i would expect to get to 200kpps with moderate cpu usage, unless you have an expensive or poorly designed ruleset. Unfortunately tags are very expensive, but i have no idea of the nat overhead. cheers luigi > Karim. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Tue Oct 25 23:11:17 2011 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 33C34106566B for ; Tue, 25 Oct 2011 23:11:17 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id E48F88FC14 for ; Tue, 25 Oct 2011 23:11:16 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p9PMi0Y2052392 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Oct 2011 15:44:03 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4EA73BAB.70607@freebsd.org> Date: Tue, 25 Oct 2011 15:43:55 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Karim References: <4EA6D78F.6010607@gmail.com> In-Reply-To: <4EA6D78F.6010607@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw rule processing performances 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, 25 Oct 2011 23:11:17 -0000 On 10/25/11 8:36 AM, Karim wrote: > Hi all, > > I am using ipfw with a fairly small amount of rules (~200). Most of > those are skipto rules to different blocking and pass-through > blocks. I use ipfw tags, ALTQ, nat, fwd and several deny and allow > rules and I do not use/need tables. > > What I find is around 400Mbps of traffic (~40kpps) an extremely high > amount of cpu usage related to firewall processing. > > What I would like to know is if there is an ongoing work to optimise > ipfw and/or gather ideas on how to do that. > > I realise my question has a large scope but I am not interested in > optimizing my ruleset I'd like to get a feel for how code wise the > current processing could be optimized (using multiple input TX/RX > queues for example, etc...). > > Thanks, > > Karim. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" I find that the structure of teh ruleset has a huge affect on the cpu usage. for example I immediately split incoming and outgoing packets apart and send them to different groups of rules. I also have different groups of rules for internal and external rules. so my rulesets usually start with: skipto 1000 all from any to any in recv ${OUTSIDE_INTERFACE} skipto 2000 all from any to any in recv ${INSIDE_INTERFACE} skipto 3000 all from any to any out xmit ${OUTSIDE_INTERFACE} skipto 4000 all from any to any out xmit ${INSIDE_INTERFACE} allow all from any to any via lo0 drop all from any to any I also try use tables whenever possible. From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 26 03:53:04 2011 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 48BD1106564A; Wed, 26 Oct 2011 03:53:04 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AFBF38FC0C; Wed, 26 Oct 2011 03:53:03 +0000 (UTC) Received: by wwi18 with SMTP id 18so1732134wwi.31 for ; Tue, 25 Oct 2011 20:53:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.206.211 with SMTP id fv19mr7010705wbb.27.1319599813953; Tue, 25 Oct 2011 20:30:13 -0700 (PDT) Received: by 10.180.81.193 with HTTP; Tue, 25 Oct 2011 20:30:13 -0700 (PDT) In-Reply-To: <4EA73BAB.70607@freebsd.org> References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> Date: Tue, 25 Oct 2011 23:30:13 -0400 Message-ID: From: Michael Sierchio To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Karim , freebsd-ipfw@freebsd.org Subject: Re: ipfw rule processing performances 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: Wed, 26 Oct 2011 03:53:04 -0000 On Tue, Oct 25, 2011 at 6:43 PM, Julian Elischer wrote= : > I find that the structure of teh ruleset has a huge affect on the cpu usa= ge. > > for example I immediately split incoming and outgoing packets apart and s= end > them to different groups of rules. > I also have different groups of rules for internal and external rules. > so my rulesets usually start with: > > skipto 1000 =A0all from any to any in recv ${OUTSIDE_INTERFACE} > skipto 2000 all from any to any in recv ${INSIDE_INTERFACE} > skipto 3000 all from any to any out xmit ${OUTSIDE_INTERFACE} > skipto 4000 all from any to any out xmit ${INSIDE_INTERFACE} > allow all from any to any via lo0 > drop all from any to any > > I also try use tables whenever possible. I've found the same to be true, and use a scheme similar to what Julian describes - I have rules grouped based on interface and direction. Having larger tables and fewer table lookups is faster, in my experience - such that I have a big block list (~20,000 nets) and a small whitelist (~20 nets) ... - M From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 26 04:46:42 2011 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 2E5A31065670 for ; Wed, 26 Oct 2011 04:46:42 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [IPv6:2a02:6b8:0:602::4]) by mx1.freebsd.org (Postfix) with ESMTP id A00A98FC12 for ; Wed, 26 Oct 2011 04:46:41 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward4.mail.yandex.net (Yandex) with ESMTP id E31DE50383A; Wed, 26 Oct 2011 08:46:39 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1319604400; bh=pZ6kWecRd8HTYLhqumSQt9a3+FmGv3452bpOpziH/MA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UmnrmwJ1OSlHQq+xVuSeDk3WyCLb/ZKCp3Aat/pZJKXIWVORmBK+srCisauSW84Lu Qd/MbMHy2W/eop7LKiY6HGcMTMpvt4gYqxwLvvFxxR3mqmvDvkbDAYiAave5ZP5hjB nVpsCKTmmAHjIHPY9w63/Ln1ZMHe5WXHcDvSyW78= Received: from smtp3.mail.yandex.net (localhost [127.0.0.1]) by smtp3.mail.yandex.net (Yandex) with ESMTP id C093F1BA0254; Wed, 26 Oct 2011 08:46:39 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1319604399; bh=pZ6kWecRd8HTYLhqumSQt9a3+FmGv3452bpOpziH/MA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=BJ5rEL+s6Rb3KpHlJY+EReQ8MTHJUgqGNBDKlkrIuQ9dUHibNTJMvC0kGtRNDVEUj KTWIPfQk+OpDxJCiiggrArazVv8JhsqSk8EPhFS93gbn/Xh7dTmQWVF9QejaTlO5eI Dndg54OS9V0fmJfpZyAm0S7CFXzxiR5ofYCIGpWU= Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp3.mail.yandex.net (nwsmtp/Yandex) with ESMTP id kdFWs92i-kdFKVfq8; Wed, 26 Oct 2011 08:46:39 +0400 X-Yandex-Spam: 1 Message-ID: <4EA790AE.9040705@yandex.ru> Date: Wed, 26 Oct 2011 08:46:38 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: =?KOI8-R?Q?=F3=C5=D2=C5=C7=C1_=E7=CF=CE=DE=C1=D2=CF=D7?= References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw features 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: Wed, 26 Oct 2011 04:46:42 -0000 On 25.10.2011 17:19, Серега Гончаров wrote: > Hi all. Is there some plans to make ipfw can change ip header fields of > going throught packets, like TTL, DF flag etc. pf and iptables can, so maybe > in freebsd 9 it will be implemented? thanks. You can use ng_patch(4) for that. -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 26 18:29:04 2011 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 62B101065773 for ; Wed, 26 Oct 2011 18:29:04 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 17C338FC16 for ; Wed, 26 Oct 2011 18:29:03 +0000 (UTC) Received: by vws11 with SMTP id 11so2610020vws.13 for ; Wed, 26 Oct 2011 11:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=o2hb1+oKdRRPo+jzP3IYu9Iwy4zn4wubRYiZNCTKhQ4=; b=djcBdMYLCR6BwS7eMck3IFQV/Odbm9UNX3UAEEhgohrugDyeSvpa7SJc2yIXnblNM7 9fCahslHe7iuVeYtGFtnh4og0L3HqE1rHzCya0h+af9smw9XfMK9meCP1CiItBEnZpFS jfKWbPghjqPSebFSIzmOUDUfdzTRiR1cI+YeQ= Received: by 10.52.30.42 with SMTP id p10mr119616vdh.127.1319653743242; Wed, 26 Oct 2011 11:29:03 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.218]) by mx.google.com with ESMTPS id p2sm237638vdi.22.2011.10.26.11.29.01 (version=SSLv3 cipher=OTHER); Wed, 26 Oct 2011 11:29:02 -0700 (PDT) Message-ID: <4EA85168.5020103@gmail.com> Date: Wed, 26 Oct 2011 14:28:56 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipfw rule processing performances 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: Wed, 26 Oct 2011 18:29:04 -0000 On 11-10-25 11:30 PM, Michael Sierchio wrote: > On Tue, Oct 25, 2011 at 6:43 PM, Julian Elischer wrote: > >> I find that the structure of teh ruleset has a huge affect on the cpu usage. >> >> for example I immediately split incoming and outgoing packets apart and send >> them to different groups of rules. >> I also have different groups of rules for internal and external rules. >> so my rulesets usually start with: >> >> skipto 1000 all from any to any in recv ${OUTSIDE_INTERFACE} >> skipto 2000 all from any to any in recv ${INSIDE_INTERFACE} >> skipto 3000 all from any to any out xmit ${OUTSIDE_INTERFACE} >> skipto 4000 all from any to any out xmit ${INSIDE_INTERFACE} >> allow all from any to any via lo0 >> drop all from any to any >> >> I also try use tables whenever possible. > I've found the same to be true, and use a scheme similar to what > Julian describes - I have rules grouped based on interface and > direction. Having larger tables and fewer table lookups is faster, in > my experience - such that I have a big block list (~20,000 nets) and a > small whitelist (~20 nets) ... > > - M > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" Hi, Thanks to everyone who contributed I will try to digest all the information and see how I can improve my ruleset. Couple of points I've identified so far: 1) As Luigi's article points out route lookups are expensive due to locking (I am using verrervpath ...) 2) ipfw_nat performance impact is an unknown at the moment (?) 3) Using mbuf tags (IPFW_TAG) is costly (so is ALTQ due to pf_tags and FORWARD_IP due to m_tag). In other words policy based routing is costly. 4) Its preferable to split incoming and outgoing packets apart as early as possible in the ruleset Anything else I'm missing? Regards, Karim. From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 26 18:39:27 2011 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 40A5A106566C for ; Wed, 26 Oct 2011 18:39:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id EF6348FC13 for ; Wed, 26 Oct 2011 18:39:26 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p9QIdOvt057785 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 11:39:25 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4EA853D7.4010305@freebsd.org> Date: Wed, 26 Oct 2011 11:39:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Karim References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> <4EA85168.5020103@gmail.com> In-Reply-To: <4EA85168.5020103@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw rule processing performances 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: Wed, 26 Oct 2011 18:39:27 -0000 On 10/26/11 11:28 AM, Karim wrote: > On 11-10-25 11:30 PM, Michael Sierchio wrote: >> On Tue, Oct 25, 2011 at 6:43 PM, Julian >> Elischer wrote: >> >>> I find that the structure of teh ruleset has a huge affect on the >>> cpu usage. >>> >>> for example I immediately split incoming and outgoing packets >>> apart and send >>> them to different groups of rules. >>> I also have different groups of rules for internal and external >>> rules. >>> so my rulesets usually start with: >>> >>> skipto 1000 all from any to any in recv ${OUTSIDE_INTERFACE} >>> skipto 2000 all from any to any in recv ${INSIDE_INTERFACE} >>> skipto 3000 all from any to any out xmit ${OUTSIDE_INTERFACE} >>> skipto 4000 all from any to any out xmit ${INSIDE_INTERFACE} >>> allow all from any to any via lo0 >>> drop all from any to any >>> >>> I also try use tables whenever possible. >> I've found the same to be true, and use a scheme similar to what >> Julian describes - I have rules grouped based on interface and >> direction. Having larger tables and fewer table lookups is faster, in >> my experience - such that I have a big block list (~20,000 nets) and a >> small whitelist (~20 nets) ... >> >> - M >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to >> "freebsd-ipfw-unsubscribe@freebsd.org" > Hi, > > Thanks to everyone who contributed I will try to digest all the > information and see how I can improve my ruleset. Couple of points > I've identified so far: > > 1) As Luigi's article points out route lookups are expensive due to > locking (I am using verrervpath ...) > 2) ipfw_nat performance impact is an unknown at the moment (?) > 3) Using mbuf tags (IPFW_TAG) is costly (so is ALTQ due to pf_tags > and FORWARD_IP due to m_tag). In other words policy based routing is > costly. > 4) Its preferable to split incoming and outgoing packets apart as > early as possible in the ruleset > > Anything else I'm missing? read up on all the things you can do with tablearg.. sometimes a single table can replace dozens of rules. > > Regards, > > Karim. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 26 21:39:22 2011 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 B94D9106566B; Wed, 26 Oct 2011 21:39:22 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6F08FC0A; Wed, 26 Oct 2011 21:39:21 +0000 (UTC) Received: by wyi40 with SMTP id 40so2828232wyi.13 for ; Wed, 26 Oct 2011 14:39:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.206.211 with SMTP id fv19mr11917690wbb.27.1319665161256; Wed, 26 Oct 2011 14:39:21 -0700 (PDT) Received: by 10.180.81.193 with HTTP; Wed, 26 Oct 2011 14:39:21 -0700 (PDT) In-Reply-To: <4EA853D7.4010305@freebsd.org> References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> <4EA85168.5020103@gmail.com> <4EA853D7.4010305@freebsd.org> Date: Wed, 26 Oct 2011 14:39:21 -0700 Message-ID: From: Michael Sierchio To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: Karim , freebsd-ipfw@freebsd.org Subject: Re: ipfw rule processing performances 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: Wed, 26 Oct 2011 21:39:22 -0000 On Wed, Oct 26, 2011 at 11:39 AM, Julian Elischer wrote: > read up on all the things you can do with tablearg.. sometimes a single > table can replace dozens of rules. Julian - would you be so kind as to give an example? - M From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 27 00:14:21 2011 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 50B6D106566B for ; Thu, 27 Oct 2011 00:14:21 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2180F8FC13 for ; Thu, 27 Oct 2011 00:14:20 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p9R0EGLl058841 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 17:14:19 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4EA8A254.9070700@freebsd.org> Date: Wed, 26 Oct 2011 17:14:12 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Michael Sierchio References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> <4EA85168.5020103@gmail.com> <4EA853D7.4010305@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Karim , freebsd-ipfw@freebsd.org Subject: Re: ipfw rule processing performances 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, 27 Oct 2011 00:14:21 -0000 On 10/26/11 2:39 PM, Michael Sierchio wrote: > On Wed, Oct 26, 2011 at 11:39 AM, Julian Elischer wrote: > >> read up on all the things you can do with tablearg.. sometimes a single >> table can replace dozens of rules. > Julian - would you be so kind as to give an example? > > - M > off the top of my head: implement an ad-hoc RErouting table using fwd tablearg implement entirely differnt rules for a complicated set of subnets using skipto tablearg arbitrarily slow down all the traffic from everyone you don't like in the company using "lookup" and queue. from the man page: The tablearg argument can be used with the following actions: nat, pipe, queue, divert, tee, netgraph, ngtee, fwd, skipto action parameters: tag, untag, rule options: limit, tagged. and... # addresses we don't want to be seeing coming from outside.. ${fwcmd} table 1 add 10.0.0.0/8 ${fwcmd} table 1 add 172.16.0.0/12 ${fwcmd} table 1 add 192.168.0.0/16 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes # RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST (class D), # and class E) on the outside interface ${fwcmd} table 1 add 0.0.0.0/8 ${fwcmd} table 1 add 169.254.0.0/16 ${fwcmd} table 1 add 192.0.2.0/24 ${fwcmd} table 1 add 224.0.0.0/4 ${fwcmd} table 1 add 240.0.0.0/4 From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 27 04:23:42 2011 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 593D41065755; Thu, 27 Oct 2011 04:23:42 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 9B7208FC0A; Thu, 27 Oct 2011 04:23:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p9R3rUEK025338; Thu, 27 Oct 2011 14:53:30 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 27 Oct 2011 14:53:30 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <4EA8A254.9070700@freebsd.org> Message-ID: <20111027143807.B98377@sola.nimnet.asn.au> References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> <4EA85168.5020103@gmail.com> <4EA853D7.4010305@freebsd.org> <4EA8A254.9070700@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Karim , freebsd-ipfw@freebsd.org, Michael Sierchio Subject: Re: ipfw rule processing performances 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, 27 Oct 2011 04:23:42 -0000 On Wed, 26 Oct 2011, Julian Elischer wrote: > On 10/26/11 2:39 PM, Michael Sierchio wrote: > > On Wed, Oct 26, 2011 at 11:39 AM, Julian Elischer > > wrote: > > > > > read up on all the things you can do with tablearg.. sometimes a single > > > table can replace dozens of rules. > > Julian - would you be so kind as to give an example? > > > > - M > > > off the top of my head: > > implement an ad-hoc RErouting table using fwd tablearg > implement entirely differnt rules for a complicated set of subnets using > skipto tablearg But in this context, isn't skipto tablearg time-expensive, in that it can't use the cached target of a normal skipto, but must to walk the ruleset from the skipto to the resulting rule each time? > arbitrarily slow down all the traffic from everyone you don't like in the > company using "lookup" and queue. > > from the man page: > > The tablearg argument can be used with the following > actions: nat, pipe, queue, divert, tee, netgraph, ngtee, fwd, skipto > action parameters: tag, untag, rule options: limit, tagged. > > and... > > # addresses we don't want to be seeing coming from outside.. > ${fwcmd} table 1 add 10.0.0.0/8 > ${fwcmd} table 1 add 172.16.0.0/12 > ${fwcmd} table 1 add 192.168.0.0/16 > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > # RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST (class > D), > # and class E) on the outside interface > ${fwcmd} table 1 add 0.0.0.0/8 > ${fwcmd} table 1 add 169.254.0.0/16 > ${fwcmd} table 1 add 192.0.2.0/24 > ${fwcmd} table 1 add 224.0.0.0/4 > ${fwcmd} table 1 add 240.0.0.0/4 Indeed, I was entirely bemused by the arguments against incorporating this into rc.firewall a year or two ago .. cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 27 07:37:59 2011 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 D33A1106564A for ; Thu, 27 Oct 2011 07:37:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 943E08FC16 for ; Thu, 27 Oct 2011 07:37:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A04157300A; Thu, 27 Oct 2011 09:53:27 +0200 (CEST) Date: Thu, 27 Oct 2011 09:53:27 +0200 From: Luigi Rizzo To: Ian Smith Message-ID: <20111027075327.GA29389@onelab2.iet.unipi.it> References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> <4EA85168.5020103@gmail.com> <4EA853D7.4010305@freebsd.org> <4EA8A254.9070700@freebsd.org> <20111027143807.B98377@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111027143807.B98377@sola.nimnet.asn.au> User-Agent: Mutt/1.4.2.3i Cc: Karim , freebsd-ipfw@freebsd.org, Julian Elischer , Michael Sierchio Subject: Re: ipfw rule processing performances 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, 27 Oct 2011 07:37:59 -0000 On Thu, Oct 27, 2011 at 02:53:30PM +1100, Ian Smith wrote: > On Wed, 26 Oct 2011, Julian Elischer wrote: > > On 10/26/11 2:39 PM, Michael Sierchio wrote: > > > On Wed, Oct 26, 2011 at 11:39 AM, Julian Elischer > > > wrote: > > > > > > > read up on all the things you can do with tablearg.. sometimes a single > > > > table can replace dozens of rules. > > > Julian - would you be so kind as to give an example? > > > > > > - M > > > > > off the top of my head: > > > > implement an ad-hoc RErouting table using fwd tablearg > > implement entirely differnt rules for a complicated set of subnets using > > skipto tablearg > > But in this context, isn't skipto tablearg time-expensive, in that it > can't use the cached target of a normal skipto, but must to walk the > ruleset from the skipto to the resulting rule each time? Since late 2009 it does a binary search on the rules so it is log(N) in the number of rules, not so slow. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 27 12:48:30 2011 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 D6F74106566B; Thu, 27 Oct 2011 12:48:30 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9338FC15; Thu, 27 Oct 2011 12:48:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p9RCmUmG043106; Thu, 27 Oct 2011 23:48:31 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 27 Oct 2011 23:48:30 +1100 (EST) From: Ian Smith To: Luigi Rizzo In-Reply-To: <20111027075327.GA29389@onelab2.iet.unipi.it> Message-ID: <20111027234648.J98377@sola.nimnet.asn.au> References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> <4EA85168.5020103@gmail.com> <4EA853D7.4010305@freebsd.org> <4EA8A254.9070700@freebsd.org> <20111027143807.B98377@sola.nimnet.asn.au> <20111027075327.GA29389@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Karim , freebsd-ipfw@freebsd.org, Julian Elischer , Michael Sierchio Subject: Re: ipfw rule processing performances 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, 27 Oct 2011 12:48:30 -0000 On Thu, 27 Oct 2011, Luigi Rizzo wrote: > On Thu, Oct 27, 2011 at 02:53:30PM +1100, Ian Smith wrote: > > On Wed, 26 Oct 2011, Julian Elischer wrote: > > > On 10/26/11 2:39 PM, Michael Sierchio wrote: > > > > On Wed, Oct 26, 2011 at 11:39 AM, Julian Elischer > > > > wrote: > > > > > > > > > read up on all the things you can do with tablearg.. sometimes a single > > > > > table can replace dozens of rules. > > > > Julian - would you be so kind as to give an example? > > > > > > > > - M > > > > > > > off the top of my head: > > > > > > implement an ad-hoc RErouting table using fwd tablearg > > > implement entirely differnt rules for a complicated set of subnets using > > > skipto tablearg > > > > But in this context, isn't skipto tablearg time-expensive, in that it > > can't use the cached target of a normal skipto, but must to walk the > > ruleset from the skipto to the resulting rule each time? > > Since late 2009 it does a binary search on the rules so it is log(N) in the > number of rules, not so slow. Might have known I was a couple of years behind the times, on form :) cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 28 05:04:27 2011 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 95B09106566C for ; Fri, 28 Oct 2011 05:04:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0428FC19 for ; Fri, 28 Oct 2011 05:04:27 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p9S54OG0067868 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Oct 2011 22:04:25 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4EAA37D3.1080905@freebsd.org> Date: Thu, 27 Oct 2011 22:04:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ian Smith References: <4EA6D78F.6010607@gmail.com> <4EA73BAB.70607@freebsd.org> <4EA85168.5020103@gmail.com> <4EA853D7.4010305@freebsd.org> <4EA8A254.9070700@freebsd.org> <20111027143807.B98377@sola.nimnet.asn.au> In-Reply-To: <20111027143807.B98377@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Karim , freebsd-ipfw@freebsd.org, Michael Sierchio Subject: Re: ipfw rule processing performances 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, 28 Oct 2011 05:04:27 -0000 On 10/26/11 8:53 PM, Ian Smith wrote: > On Wed, 26 Oct 2011, Julian Elischer wrote: > > On 10/26/11 2:39 PM, Michael Sierchio wrote: > > > On Wed, Oct 26, 2011 at 11:39 AM, Julian Elischer > > > wrote: > > > > > > > read up on all the things you can do with tablearg.. sometimes a single > > > > table can replace dozens of rules. > > > Julian - would you be so kind as to give an example? > > > > > > - M > > > > > off the top of my head: > > > > implement an ad-hoc RErouting table using fwd tablearg > > implement entirely differnt rules for a complicated set of subnets using > > skipto tablearg > > But in this context, isn't skipto tablearg time-expensive, in that it > can't use the cached target of a normal skipto, but must to walk the > ruleset from the skipto to the resulting rule each time? not necessarily if you have the destinations being normal skiptos following the selection rule, you might select from one of a small number of destination skiptos (which are cached) for an arbitrarily large set client addresses, with a single table lookup. the time to walk a small number of rules is small.. > > arbitrarily slow down all the traffic from everyone you don't like in the > > company using "lookup" and queue. > > > > from the man page: > > > > The tablearg argument can be used with the following > > actions: nat, pipe, queue, divert, tee, netgraph, ngtee, fwd, skipto > > action parameters: tag, untag, rule options: limit, tagged. > > > > and... > > > > # addresses we don't want to be seeing coming from outside.. > > ${fwcmd} table 1 add 10.0.0.0/8 > > ${fwcmd} table 1 add 172.16.0.0/12 > > ${fwcmd} table 1 add 192.168.0.0/16 > > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > > # RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST (class > > D), > > # and class E) on the outside interface > > ${fwcmd} table 1 add 0.0.0.0/8 > > ${fwcmd} table 1 add 169.254.0.0/16 > > ${fwcmd} table 1 add 192.0.2.0/24 > > ${fwcmd} table 1 add 224.0.0.0/4 > > ${fwcmd} table 1 add 240.0.0.0/4 > > Indeed, I was entirely bemused by the arguments against incorporating > this into rc.firewall a year or two ago .. > > cheers, Ian > From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 28 15:29:50 2011 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 5270E1065675 for ; Fri, 28 Oct 2011 15:29:50 +0000 (UTC) (envelope-from gpm@hotplug.ru) Received: from gate.pikinvest.ru (gate.pikinvest.ru [87.245.155.170]) by mx1.freebsd.org (Postfix) with ESMTP id 0BDD18FC15 for ; Fri, 28 Oct 2011 15:29:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailgate.pik.ru (Postfix) with ESMTP id D3D451C0831; Fri, 28 Oct 2011 19:10:32 +0400 (MSD) Received: from EX03PIK.PICompany.ru (unknown [192.168.156.51]) by mailgate.pik.ru (Postfix) with ESMTP id D1B711C0822; Fri, 28 Oct 2011 19:10:32 +0400 (MSD) Received: from EX21PIK.PICompany.ru ([192.168.156.131]) by EX03PIK.PICompany.ru with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 19:10:17 +0400 Received: from [192.168.148.9] (192.168.148.9) by EX21PIK.PICompany.ru (192.168.156.131) with Microsoft SMTP Server id 14.1.218.12; Fri, 28 Oct 2011 19:10:16 +0400 Message-ID: <4EAAC5C5.6090803@hotplug.ru> Date: Fri, 28 Oct 2011 19:09:57 +0400 From: Emil Muratov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: , Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2011 15:10:17.0059 (UTC) FILETIME=[B36F9330:01CC9583] Cc: Subject: ipfw reass brakes ipv6 operation 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, 28 Oct 2011 15:29:50 -0000 Hi all I've got into some strange behavior with ipv6. Somehow ipfw reassembly totally brakes it's operation. As soon as I add a rule "ipfw add 100 reass all from any to any in" all ipv6 operation is not available any more, I can only ping6 localhost. Outgoing ipv6 packets are OK, I can see them via tcpdump on an interface stf0 and after that leaving encapsulated in ip4 through another interface. But all incoming ipv6 packets are blackholed. I can see them arriving as an encapsulated payload in ip4 and after that they disappear. I don't know if this a bug or a feature, using "ipfw add reass ip4 from any to any in" works as a workaround. Shouldn't reass just pass ipv6 packets intact? Or if it is a feature than maybe there should be a note in IPFW(8) man page to not to use reass for anything except ip4? Thanks. From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 28 17:02:43 2011 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 F1C851065672; Fri, 28 Oct 2011 17:02:43 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (mail.ciam.ru [91.209.218.18]) by mx1.freebsd.org (Postfix) with ESMTP id A78448FC15; Fri, 28 Oct 2011 17:02:40 +0000 (UTC) Received: from [46.242.19.18] (helo=[172.16.100.20]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1RJpWo-0005TO-Tw; Fri, 28 Oct 2011 20:43:35 +0400 Message-ID: <4EAADBB6.5090901@FreeBSD.org> Date: Fri, 28 Oct 2011 20:43:34 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Emil Muratov References: <4EAAC5C5.6090803@hotplug.ru> In-Reply-To: <4EAAC5C5.6090803@hotplug.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipfw reass brakes ipv6 operation 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, 28 Oct 2011 17:02:44 -0000 28.10.2011 19:09, Emil Muratov wrote: > > Hi all > > I've got into some strange behavior with ipv6. Somehow ipfw reassembly > totally brakes it's operation. > As soon as I add a rule "ipfw add 100 reass all from any to any in" all > ipv6 operation is not available any more, > I can only ping6 localhost. Outgoing ipv6 packets are OK, I can see them > via tcpdump on an interface stf0 and after that leaving encapsulated in > ip4 through another interface. But all incoming ipv6 packets are > blackholed. I can see them arriving as an encapsulated payload in ip4 > and after that they disappear. I don't know if this a bug or a feature, > using "ipfw add reass ip4 from any to any in" works as a workaround. > Shouldn't reass just pass ipv6 packets intact? Or if it is a feature > than maybe there should be a note in IPFW(8) man page to not to use > reass for anything except ip4? Yes, reass implemented only for ipv4 and breaks ipv6 packets. It should be fixed, not documented.