8.0 network problem

[David Warren]

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 <rsmith at xs4all.nl> 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/<http://www.xs4all.nl/%7Ersmith/>
> [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 at gmail.com