From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 01:08:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64D8C106564A for ; Wed, 7 Jul 2010 01:08:03 +0000 (UTC) (envelope-from davideugenewarren@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 0E2558FC15 for ; Wed, 7 Jul 2010 01:08:02 +0000 (UTC) Received: by vws6 with SMTP id 6so8751840vws.13 for ; Tue, 06 Jul 2010 18:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ECCCc7KlVgP8pyCHUWV2IEKwaYXipREjbd05QvoKYcg=; b=n3NQdwYo0lqwDy7tVs0PVkWA6ANx0ttYc837ujpXfzGO8YsPt7im5cmsYRk2jqpOsa WsFmsYEA+zNjKDxu3uHuaB9ny5p9iWsaby4iMTBT7pCJ+NqoR/1R1OaoS9r5Gvyl4Cku EYaBReFa273YCoo1GHGsLsq/21gG06SSIAbhQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LtKYaSYNm5YX3/exrb8K6hS1m1g0hETbOogX0tEfTzOUy9uz8eqiyMBTIhtRoRbTSj x/K4+fdfbCbGbH2+OENglt3zAMufYf8rJPWl+vrtoeJ9SgkdZ8X9PAzeae/IdoFdo5Pp g/hhxBZwbFYlw8G2r6hD4JHkl1CfykENCniN4= MIME-Version: 1.0 Received: by 10.220.62.72 with SMTP id w8mr2931016vch.209.1278464873424; Tue, 06 Jul 2010 18:07:53 -0700 (PDT) Received: by 10.220.190.1 with HTTP; Tue, 6 Jul 2010 18:07:53 -0700 (PDT) In-Reply-To: <20100706212830.GA63307@slackbox.erewhon.net> References: <20100705055105.GA21681@icarus.home.lan> <20100706174155.GA56410@slackbox.erewhon.net> <20100706203222.GA68830@icarus.home.lan> <20100706212830.GA63307@slackbox.erewhon.net> Date: Tue, 6 Jul 2010 20:07:53 -0500 Message-ID: From: David Warren To: Roland Smith Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Max Laier , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: 8.0 network problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 01:08:03 -0000 Hi all, Max was on to something when he wrote: "Furthermore, remember that the OP can move to another NIC and the problem goes away[1]. I know there have been issues in the past reported with em(4) and pf ALTQ, but that isn't in use here." In fact, when I was testing possible firewall issues I had simply turned off pf rather than switched NICs. Swapping nfe0 and em0 into the int_if and ext_if roles, respectively, seems to have remedied the problem. This means that at least some of the problems that I was encountering stemmed from em's interactions with my Intel NIC, or em in combination with pf, or something along. I'm perplexed about the issue, but I'm satisfied with the network performance that I've got now. Notably, none of the changes to pf when em was still the internal interface had a substantial effect. I'd be happy to run more tests on the original setup if anyone wants to chase down whatever was causing those problems. Let me know, and many thanks to all. Take care, Dave On Tue, Jul 6, 2010 at 4:28 PM, Roland Smith wrote: > On Tue, Jul 06, 2010 at 01:32:22PM -0700, Jeremy Chadwick wrote: > > Back to the problem at hand: > > > > I wonder if it's lack of "quick" on some rules which is causing the > > problem; hard to say, > > That would stop evaluation of further rules, sure. But it seems most of the > rules concern the external interface. > > _Assuming_ that the samba clients are on the internal interface, it would > make > sense to put the few rules concerning that interface as early as possible > in > the list of filter rules, and indeed add the quick keyword. > > Alternatively, one could consider adding this interface to the list of > skipped > interfaces. This would at least be useful for testing purposes, since it > would > preclude pf from processing packages on this interface. If this fixes the > problem, there is some problem in the ruleset. > > > and I'm not sure how to "benchmark" pf. > > Looking at the output of 'pfctl -vvs rules' would be a start, I think. If > the > rules that are matched most are at the end of the filter rules, all > previous > rules are evaluated, AFAIK. For more info try 'pfctl -vvs all'. > > In the past I found it useful to set up a point-to-point connection between > two FreeBSD machines, and then do some throughput measusrements using > e.g. nc(1). Start with pf disabled, then enhance the ruleset rule-by-rule > and > see if performance is influenced. A couple of years ago I did this, and > IIRC > the largest influence I could find was the type of ethernet adapter > used. Can't find any notes from that experiment but I could repeat it if is > deemed interesting. > > > Furthermore, remember that the OP can move to another NIC and the > > problem goes away[1]. I know there have been issues in the past > > reported with em(4) and pf ALTQ, but that isn't in use here. > > There are lots of other crappy ethernet adapters out there. E.g. re(4) and > rl(4) tend to suck in my experience. Of course if the hardware was changed > but > not the relevant filter rules, it would default to "pass". :-) > > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) > -- Post-doctoral Fellow Neurology Department University of Iowa Hospitals and Clinics davideugenewarren@gmail.com