From owner-freebsd-questions@FreeBSD.ORG Thu Jan 26 16:11:34 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5517216A420 for ; Thu, 26 Jan 2006 16:11:34 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34C5F43D4C for ; Thu, 26 Jan 2006 16:11:32 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 403025DCB; Thu, 26 Jan 2006 11:11:31 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56296-08; Thu, 26 Jan 2006 11:11:29 -0500 (EST) Received: from [192.168.1.3] (pool-68-160-211-174.ny325.east.verizon.net [68.160.211.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 6CE3A5C6B; Thu, 26 Jan 2006 11:11:29 -0500 (EST) Message-ID: <43D8F4B2.5080102@mac.com> Date: Thu, 26 Jan 2006 11:11:30 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ikaney@crisiant.com References: <20060126115051.8840D43D45@mx1.FreeBSD.org> In-Reply-To: <20060126115051.8840D43D45@mx1.FreeBSD.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-questions@freebsd.org Subject: Re: Bridging Firewall Machine Questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 16:11:34 -0000 Ian Kaney wrote: > Hi there. I wonder if somebody could help me with an issue I'm experiencing. You've asked an interesting question, but there's a lack of data ("vmstat -i", dmesg, "sysctl net"). You might obtain better results by putting together some details, maybe as files in a directory being served by HTTP, and sending a link. > I've put together a bridging firewall using FreeBSD 5.X. The traffic routes > through fine and presently I'm using IPFW, default policy is set to deny, > with certain rules/ports allowed to pass through. The three interfaces that > are being bridged are all gigabit speed. The server is using Intel/Broadcom > gigabit network cards. The machine that is performing the bridging is a Dual > Opteron 246 with 2GB memory. > > The issue that I'm finding is that the CPU runs out of power when the links > are being hit hard. The em0 (fibre) device in particular runs at about 6% > consistently with normal traffic (~40Mbits/s) being pushed through the > bridge. This means the machine would run out of CPU power when the link was > being utilised at around ~650Mbits/s. Is this unavoidable or is this a > symptom of more CPU power being required? Are the CPU's busy handling interrupts, in which case enabling interrupt coalescing (-link0 flag, depending on the NIC) or maybe using device polling might help? Have you tried enabling fast-forwarding sysctl? Or are you busy processing the traffic in your IPFW ruleset, in which case changing and optimizing your ruleset will likely remove the bottleneck you see. It's also possible that running the system in single-processor mode might actually behave better for this kind of workload, because you avoid all the SMP locking... > I've also had problems with the bridge running out of dynamic rules. I've > raised them to silly figures however I'm always wary that if a machine had a > Trojan or some other form of malware that attempted a DoS attack, the bridge > would probably fall over after exhausting its dynamic rule count and cause > more issues. Could this be fixed perhaps by setting the default policy of > IPFW to accept, or do the dynamic rules get created anyway when bridging? Dynamic rules shouldn't get created unless your ruleset tells IPFW to make them, or unless something like natd generates rules dynamicly for active FTP traffic. It's entirely possible to replace dynamic rules with appropriate static rules for your most common types of traffic, which may be faster and avoid filling up the dynamic session table. For example, instead of doing "pass tcp from me to any smtp keep-state": # outside SMTP to pi add pass tcp from any HIPORTS to PI 25 setup add pass tcp from PI 25 to any HIPORTS established # permit SMTP exchange between pi and pong add pass tcp from PI HIPORTS to PONG 25 setup add pass tcp from PONG 25 to PI HIPORTS established add pass tcp from PONG HIPORTS to PI 25 setup add pass tcp from PI 25 to PONG HIPORTS established # track SMTP from inside to outside and block SMTP from outside add pass log logamount 20 tcp from INET HIPORTS to any 25 setup add pass tcp from INET HIPORTS to any 25 established add unreach filter-prohib log tcp from any to INET 25 [ Where PI and PONG are macros which expand to the IP addresses of my external MX relay and the internal reader box, respectively, HIPORTS means 1024-65535, and INET refers to the internal network. ] -- -Chuck