DragonFly BSD
DragonFly kernel List (threaded) for 2011-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

[no subject]


Date:

y=ZG@mail.gmail.com>
From: Jan Lentfer <Jan.Lentfer@web.de>
Subject: Re: Time to let go of ipfilter
Date: Sat, 22 Jan 2011 14:37:05 +0100
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:kernel@crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel@crater.dragonflybsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
References: <AANLkTimjM2J4nQ9-Nuv3Z88pEdsbp8jYkKcUht=FwEuY@mail.gmail.com>	<AANLkTind5QG_bZA+uhrT5BQqYmyNLsjq6YrzVWXLVWOm@mail.gmail.com>	<201101211602.p0LG2mRv009793@apollo.backplane.com>	<20110121193033.1B25919D496@mail.netbsd.org>	<201101212217.p0LMH0P7017513@apollo.backplane.com>	<72c983e5e708847d211383d03dbff6a0.squirrel@webmail.exetel.com.au>	<AANLkTiku-VxZQzRDo1Bd5M-bpYgHKWkrKiKkeVa3Nube@mail.gmail.com>	<20110122082312.GA990@sekishi.zefyris.com> <AANLkTik=S5O1DA78ObwEJ-paiUTdV5vEUM7LOym1
y=ZG@mail.gmail.com>
In-Reply-To: <AANLkTik=S5O1DA78ObwEJ-paiUTdV5vEUM7LOym1y=ZG@mail.gmail.com>
Sender: kernel-errors@crater.dragonflybsd.org
Errors-To: kernel-errors@crater.dragonflybsd.org
Lines: 45
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1295704181 crater_reader.dragonflybsd.org 888 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14845

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/




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]