From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 13:56:54 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDBD5FC0; Fri, 19 Oct 2012 13:56:54 +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 09EE58FC08; Fri, 19 Oct 2012 13:56:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q9JDujNr096880; Sat, 20 Oct 2012 00:56:45 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 20 Oct 2012 00:56:45 +1100 (EST) From: Ian Smith To: "Andrey V. Elsukov" Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time In-Reply-To: <508138A4.5030901@FreeBSD.org> Message-ID: <20121020002249.X88114@sola.nimnet.asn.au> References: <508138A4.5030901@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ipfw@freebsd.org, net@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:56:54 -0000 On Fri, 19 Oct 2012 15:25:24 +0400, Andrey V. Elsukov wrote: > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and network stack, several locks acquired in the path of each packet, > and i have an ability to test this in the lab. > > So, i prepared the patch, that removes IPFIREWALL_FORWARD option from > the kernel and makes this functionality always build-in, but it is > turned off by default and can be enabled via the sysctl(8) variable > net.pfil.forward=1. > > http://people.freebsd.org/~ae/pfil_forward.diff > > Also we have done some tests with the ixia traffic generator connected > via 10G network adapter. Tests have show that there is no visible > difference, and there is no visible performance degradation. > > Any objections? Looks great. I'll no longer have to tell people on questions@ that using ipfw fwd is the only reason left not to just load the module. Taking the code on trust, only to comment on the documentation: ipfw.8: ======= To enable .Cm fwd -a custom kernel needs to be compiled with the option -.Cd "options IPFIREWALL_FORWARD" . +the +.Xr sysctl 8 +variable +.Va net.pfil.forward +should be set to 1. NOTES: ======= -# IPFIREWALL_FORWARD enables changing of the packet destination either -# to do some sort of policy routing or transparent proxying. Used by -# ``ipfw forward''. All redirections apply to locally generated -# packets too. Because of this great care is required when -# crafting the ruleset. ipfw(8) could perhaps incorporate that description (and warning) from NOTES in the entry under SYSCTLS where net.pfil.forward (or whatever :) would be expected to be described, apart from sysctl -d ? cheers, Ian > WBR, Andrey V. Elsukov