Am 22.01.2011 10:04, schrieb Edward O'Callaghan:
I agree, however I have no doubt it will be added soon since this is
also a limitation for NetBSD usage of NPF as well.. more my point, +1
to EOL'ing older solutions that are no longer maintained or scalable.
One of the things that I myself consider a 'feature' of Dragonfly is
less old junk running in kernel space (both important on a security
and stability stand point) and a less bulky userland.
NPF is the new kid on the block. Let's the how it behaves in practice, I
for one will consider looking at it in-depth as soon as it is officially
released with NetBSD, not before.
In regard to "no longer maintained"? What would that be? As far as I can
see ipf is at version 5.1.0, which is from beginning of 2010.
Regarding scalability you should also look at the "need to scale". Most
setups will be fully satisfied with a UP machine as a router/firewall.
E.g. I ran OpenBSD 4.5/pf on a MicroSparc II @ 70MHz on a 10MBit DSL
Line, no problem. I now use DF/pf with 1,5GHz VIA C7 and there is tons
of resources left, even when I also run squid, dansguardian, clamav,
ntop.. etc on the router So, scalability is good in general terms, but
you also have to keep in mind when and where it is actually needed and
used. The mentioned 200-300 MB/s is another game of course, but that is
not the average setup we are approaching.
I am not saying we need to keep ipf, but I find this "all new is all
good" approach in regard to NPF a little odd. Has anyone actually looked
at the sources and ran it yet to get an opinion or this is just
repetition of advertisement slogans? ;)
PF is a very good packet filter in my eyes, it's actively maintained and
feature-rich. Of course there is room for improvement. E.g. I want to
look into making state lookups SMP capable at some point, which I think
will give a good performance boost on SMP hardware, for those who need it.
Jan
--
professional: http://www.oscar-consult.de
private: http://neslonek.homeunix.org/drupal/
