firewall high-load performance
smithi at nimnet.asn.au
Wed Jun 11 08:24:20 UTC 2008
Woj, another of the few joys of -digests: two birds with one stone:
> is there a way to check on running system how much CPU time is used to
> perform firewalling/traffic manager - be it pf or ipfw?
Sure, compare ping times / traffic throughput with firewall turned off
and on? I recall that a FreeBSD 2.2.6 P166 with about 1000 ipfw rules
added up to ~2ms to ping times through - on a local 10Mbps network :)
On Wed, 11 Jun 2008 00:35:14 +0200 (CEST)
Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl> wrote:
(quoting Matthew Seaman)
> > High load may or may not be a problem depending on your traffic patterns.
> > I've seen pf firewalls suffer by running out of state-table space in
> > situations where there are a lot of fairly short-lived but low volume
> > network connections. The default is 10,000 states. If your firewall machine
> is this state-table a hash table or something similar. if so - making it
> much bigger than CPU cache may actually slow down things because DRAM
> access latency is huge on modern machines.
There was some discussion of the efficiency of ipfw stateful rules in
recent weeks, over on -net IIRC. As someone else mentioned, that's the
place to be if you're interested in net stuff, and are prepared to sit
back and read some real expertise before saying too much for a while :)
ipfw hashes src.ip ^ dst.ip ^ src.port ^ dst.port for connections in a
default of 256 buckets, which is very fast when there are no collisions;
duplicates however are added to a linked list, which gets slow if large,
such as for raw IP or ICMP where 'port' numbers = 0. I'm not sure what
stateful rules really mean in those contexts anyway, but there was talk
of increasing both the (default) no. of buckets and maximum stetes kept,
the memory penalty being pretty insignificant on today's hardware.
I tend to doubt that processor caching is an issue one way or the other.
> > On the whole I'd go with pf every time simply based on how much more
> > manageable it is compared to ipfw -- you have to try, hard, to lock
> > yourself out when reloading a new pf ruleset.
> i already learned well locking myself after making mistake in ipfw rules
> now i run screen and do something like that
> cd /etc
> cp firewall firewall.old
> cp firewall firewall.new
> <edit> firewall.new
> cp firewall.new firewall;/etc/rc.d/ipfw restart;sleep 100;cp firewall.old firewall;/etc/rc.d/ipfw restart
> then i have 100 seconds to quickly test new rules, at least to make sure
> i'm not locked.
Yeah that'll work, as suggested in the manual's example.
I also wouldn't mind seeing some proper empirical comparisons between
ipfw and pf. Many of the reasons sometimes offered to prefer pf have
been addressed in ipfw more recently (like in-kernel NAT for 7.x) and
development of both is always ongoing, so it's still largely personal
preference. I've been using ipfw for just over 10 years and am fairly
familiar with it, and there are plenty of options I've not yet tried.
Anyone reading the handbook these days would think ipfw was deprecated,
and one day I hope to do a number on the ipfw section there; it contains
out and out factual errors, some misconceptions and poor examples, still
the author does declare his familiarity is otherwise, ipf as I recall.
BTW I'm not dissing pf in any way, I've just never tried it. ipfw plus
dummynet has done everything well that I've needed to do so far, mostly
on networks smaller even than yours :)
More information about the freebsd-questions