Date: Wed, 11 Jun 2008 18:23:52 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Cc: freebsd-questions@freebsd.org Subject: Re: firewall high-load performance Message-ID: <Pine.BSF.3.96.1080611165146.18537C-100000@gaia.nimnet.asn.au> In-Reply-To: <20080611061921.1CE6C10656BD@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 :) cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1080611165146.18537C-100000>