Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Aug 2009 18:44:40 -0400
From:      Chris Buechler <cbuechler@gmail.com>
To:        Tom Uffner <tom@uffner.com>
Cc:        pf@freebsd.org
Subject:   Re: packet forwarding/firewall performance question
Message-ID:  <d64aa1760908131544o9200f8fj6f84a662876b527d@mail.gmail.com>
In-Reply-To: <4A8484E4.6090504@uffner.com>
References:  <4A8484E4.6090504@uffner.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 13, 2009 at 5:25 PM, Tom Uffner<tom@uffner.com> wrote:
> I am curious what level of performance I should expect from the
> firewall box described below in terms of packets/sec and bytes/sec.
>
> it is an 800 MHz VIA c3 with a Gigabit switch on the inside interface
> and 20 Mbs symetric Fios on the outside. both interfaces are 100 Mbs.
> it is running sshd, bsnmpd, sendmail (outbound only), bind9 (serving
> local domain info & queries from 5-15 machines on the LAN) and isc-dhcpd.
> it acts as a border firewall/router for a small LAN w/ 5 static external
> addresses & the rest NATed.
>

Keeping this on pf since you aren't running -current.

With what sounds like a nearly identical box, I've gotten 100 Mb wire
speed with 7.x-based pfSense versions, which should be virtually
identical to stock FreeBSD performance. I would expect 100 Mb wire
speed with CPU to spare, using out of the box settings.


> so far in preliminary tests, enabling polling on the network interfaces
> reduces my performance slightly both to/from and through the box.

That's to be expected, the only benefit of polling is to prevent live
lock under extreme load. With only 100 Mb NICs I doubt if you could
even get into that scenario with an 800 MHz CPU.


> net.inet.ip.fastforwarding doesn't seem to make much difference either
> way but i haven't done very thorough testing of it.

I believe that has more impact with routing, and little or none when
firewalling/NATing.

> increasing
> net.inet.tcp.sendbuf_max & recvbuf_max may have helped, but again, not
> sufficiently tested.

I don't think that has any impact on traffic through the system,
rather that's for traffic initiated by the system, but not completely
sure.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d64aa1760908131544o9200f8fj6f84a662876b527d>