From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 16 19:08:41 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDDE1F99; Thu, 16 Apr 2015 19:08:40 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81A08A59; Thu, 16 Apr 2015 19:08:40 +0000 (UTC) Received: by wiax7 with SMTP id x7so18474884wia.0; Thu, 16 Apr 2015 12:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tds6XN9gf7gno6qYg3tT/dSgxZ2+eVUw6v+kTqSpaV0=; b=wBesyMishPTTmoqjgTum2aKOinL1wGio6HskbXs+jMxu7VwkkJf0OZ6aHY14NLPTnX zK/zyWgZl6egHiiG4GvmMDi51bNdG+RSVh5YyFHXu8lQOF9SHBqyVuKlLFexPNqUhH/Y vri9kRUCbnQTavk3tkJXOtyQwus6uTTdcXZcOoIV2bu1hi4K2sRFVqaQ5wzRdT0fXimb iSXhPrqJVt98iAq80B5A04bk4gQOxMPRnu4J4evkgrxMX1HPvSdgUHqMQpAyaZR3fKGe SQCniX3gNR7PpbQ5ucU4h9jrCO2yr4AHSGcU8ioV3Oczhhjo1QyJemjMfqxhTZsnezod V4og== MIME-Version: 1.0 X-Received: by 10.194.2.145 with SMTP id 17mr62164292wju.79.1429211319080; Thu, 16 Apr 2015 12:08:39 -0700 (PDT) Received: by 10.27.52.132 with HTTP; Thu, 16 Apr 2015 12:08:39 -0700 (PDT) In-Reply-To: <20150416164024.B93161@sola.nimnet.asn.au> References: <20150414210901.GA10620@strugglingcoder.info> <552F2F82.1060506@freebsd.org> <20150416164024.B93161@sola.nimnet.asn.au> Date: Thu, 16 Apr 2015 12:08:39 -0700 Message-ID: Subject: Re: ipfw on just inbound and not outbound From: Jason Wolfe To: Ian Smith Cc: Julian Elischer , hiren panchasara , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 19:08:41 -0000 Ian, It's not so much the induced latency, but the CPU usage. Simply invoking ipfw causes a noticeable amount of overhead, and with a single rule it clocks in at 5% on the hardware in question. This ranks ipfw_chk in as the 2nd hungriest function, just below tcp_output in the IRQ handler threads with a single rule. With 3 rules, it overtakes the top spot (each adding ~ .3% -.5%). If there were an easy way to gain back that 5% on outbound traffic, we'd gladly take it. It sounds like being able to disconnect paths from ipfw might be a science project for the future, though it does seem it could garner some wider interest. Jason On Thu, Apr 16, 2015 at 12:12 AM, Ian Smith wrote: > On Thu, 16 Apr 2015 11:41:54 +0800, Julian Elischer wrote: > > On 4/15/15 5:09 AM, hiren panchasara wrote: > > > Apologies if this is something silly but I want to completely eliminate > > > ipfw from outgoing traffic perspective. I just want to have it on > > > incoming. I can always add "allow ip from any to any out" as the first > > > rule but that is still ipfw doing something. > > > > > > Is there a way to tell ipfw to not look at outbound traffic at all? > > no > > > > > > OR, the rule I mentioned is the best that can be done here? > > yes > > > > this touches on something I've been thinking of for a while.. per > > interface/direction rule sets. > > but that doesn't exist yet. > > > > you could write a kernel module that would disconnect the outgoing packet > > filter hooks > > but "hack" comes to mind as a description there. > > > > actually.... you could use the ipfw netgraph hook and only hook it up for > > incoming packets, > > but it would probably be not much more efficient than just having the rule, > > and more complicated to set up. > > I'm wondering if the cost of that one rule is even worth worrying about. > > Hiren, you might try running iperf (ono): > > a) after 'ipfw disable firewall' > > b) after just 'ipfw add 20000 allow ip from any to any' > > c) after say 1000 rules before getting to (b) by such as: > > for i in `jot - 0 999`; do > ipfw add $((i*10+1000)) count ip from any to any > done > > to then calculate a cost per rule. Tens or hundreds of ns? > > Of course, whether that cost is significant depends on the sort of pps > rates you're having (or hoping :) to deal with on the box in question .. > > > > cheers, > > > Hiren > > > > > > ps: Please keep me cc'd as I am not subscribed. > > cheers, Ian