NPF(Paketfilter) - Dokumentation gibts hier

[darktrym]

Da ein neuer Mitspieler das Feld betritt, gibts wieder Material:

Introducing NPF in NetBSD 6.0
NPF - the packet fillter of NetBSD
und die etwas ältere Aufnahme(für die es noch nicht kennen) vom BSDday11.

Einige Feature werden bekanntlich noch nachgeliefert bspw. im Rahmen des Gsoc12, glaube NAT Sachen.


PS: Ändert erstmal nichts daran, dass ipf(kürzliches Update), pf im Kernel bleiben.

[Lord_x]

Kann mir jemand den Sinn dahinter erklären, warum jetzt schon wieder das Rad neu erfunden wird?
Ich meine FreeBSD baut an einer SMP Variante von PF...

[h^2]

Zitat von Lord_x

Kann mir jemand den Sinn dahinter erklären, warum jetzt schon wieder das Rad neu erfunden wird?
Ich meine FreeBSD baut an einer SMP Variante von PF...

NetBSD war schon länger dabei... und NetBSD war von Anfang an nicht auf Syntax-Kompatilität mit OpenBSD PF aus. FreeBSD's neues PF geht zumindest mit der alten (unter FreeBSD vorher verwendeten) PF Syntax.
Zumindest wenn ich das alles richtig verstanden habe.

[darktrym]

Gesucht war eine performante, integrierte/modularer und wartbarer Paketfilter. Das alles ist pf nicht. Und FreeBSD pf Umbau kam einige Zeit später, nachdem npf nahezu komplett war.

[Kamikaze]

Wenn es um in-Kernel Parallelisierung geht ist die Portierbarkeit von Code wahrscheinlich sowieso minimal. Mit einem gemeinsamen Projekt wäre da wahrscheinlich gar nicht so viel gewonnen.

[Yamagi]

Genau das ist der - bzw. ein wichtiger - Punkt. Zwar haben DragonflyBSD, FreeBSD, NetBSD und OpenBSD ursprünglich die gleiche Basis gehabt. Doch die Kernel sind nun viele Jahre voneinander divergiert, gerade die SMP-Integration FreeBSD und NetBSD haben beide Systeme stark voneinander und von OpenBSD entfremdet. Kernelcode ist daher nur noch sehr aufwändig portabel, ein Aufwand der sich oft nicht mehr lohnt. Das betrifft gerade OpenBSD, dessen Code oft nicht SMP-fähig und daher aus Sicht der anderen Systeme unperformant ist.

[laemodost]

Jetzt wärs mal schön, wenn "jemand" mal Benchmarks fährt, wie die einzelnen Paketfilter unter Last laufen und ob es da messbare Unterschiede gibt, oder ob das Ganze nicht nur eine Glaubensfrage ist.

[h^2]

Zitat von laemodost

Jetzt wärs mal schön, wenn "jemand" mal Benchmarks fährt, wie die einzelnen Paketfilter unter Last laufen und ob es da messbare Unterschiede gibt, oder ob das Ganze nicht nur eine Glaubensfrage ist.

Ja, ich fände benchmarks auch toll.

Es wird immer so viel geredet über theoretische und praktische Vorteile und Nachteile, und jeder behauptet was anderes. FreeBSD behauptet es sei schneller als OpenBSD, OpenBSD meint es macht keinen Unterschied, schneller als Linux wollen beide sein und richtige Zahlen gibts nirgends...

[darktrym]

Was soll ein Benchmark denn bringen?
Unterschiedliche Compiler, Kernel Locking UND Paketfilter.

[HUE]

Hi,

wie wäre es denn mal wenn wir unsere Freundinnen benchmarken würden?


Liebe Grüsse an Diese...


HUE

[laemodost]

Nö, man kann ja auf der gleichen HW

FreeBSD mit ipf, ipfw, pf und SMP-pf testen
NetBSD mit ipf und npf
OpenBSD mit pf
Linux mit iptables

Und dann mal schauen, wie sie sich untereinander schlagen.

[h^2]

Zitat von HUE

wie wäre es denn mal wenn wir unsere Freundinnen benchmarken würden?

Solche Kommentare führen sicherlich nicht dazu, dass sich Frauen in diesem Forum wohler fühlen. Think about it.

Zitat von darktrym

Was soll ein Benchmark denn bringen?
Unterschiedliche Compiler, Kernel Locking UND Paketfilter.

Zitat von laemodost

Nö, man kann ja auf der gleichen HW

FreeBSD mit ipf, ipfw, pf und SMP-pf testen
NetBSD mit ipf und npf
OpenBSD mit pf
Linux mit iptables

Und dann mal schauen, wie sie sich untereinander schlagen.

Ja, genau, dass die Kernels unterschieldich sind ist ja Teil der Rechnung. Es geht mir ja auch nicht um die potentielle, theoretische Überlegenheit von einem System oder Ansatz, sondern ob das Ganze real die Arbeit und die Diskussion darüber wert ist.

[HUE]

So,

was soll dieses ständige Vergleichen der Geschwindigkeit der Systeme? Ist es nicht egal wie die Geschwindigkeit eines Produktes ist, oder dessen Qualität? Qualität ist doch die Summe aus Geschwindigkeit, Features, Sicherheit, elegante Algorithmen, Speicherverbrauch und so weiter!

Ich habe mit Linux mal angefangen, mich dann doch über dessen Undurchsichtigkeit an Net/OpenBSD seit 2001 versucht und dabei geblieben. Es ist einfach ein solides System, das *BSD. Genau das was ich brauche.

Deswegen finde ich es toll, wenn sich Entwickler die Mühe machen, etwas weiter zu entwickeln, oder neu zu entwerfen.


Wenn aber dann die ständige Diskussion sich nur um Benchmarks dann dreht und Anzahl der Funktionen, verliere ich die Lust am Forum.

Dann bleibe ich lieber beim Lesen der FAQ oder Wiki, da bleibt das Unwesentliche aussen vor.

Ich danke hiermit Eurer Geduld mit mir, ich werde am Forum nun kein Interesse mehr zeigen und meinen Account löschen.

HUE

[bofh_hannibal]

Zitat von HUE

So,

was soll dieses ständige Vergleichen der Geschwindigkeit der Systeme? Ist es nicht egal wie die Geschwindigkeit eines Produktes ist, oder dessen Qualität? Qualität ist doch die Summe aus Geschwindigkeit, Features, Sicherheit, elegante Algorithmen, Speicherverbrauch und so weiter!

Ich habe mit Linux mal angefangen, mich dann doch über dessen Undurchsichtigkeit an Net/OpenBSD seit 2001 versucht und dabei geblieben. Es ist einfach ein solides System, das *BSD. Genau das was ich brauche.

Deswegen finde ich es toll, wenn sich Entwickler die Mühe machen, etwas weiter zu entwickeln, oder neu zu entwerfen.


Wenn aber dann die ständige Diskussion sich nur um Benchmarks dann dreht und Anzahl der Funktionen, verliere ich die Lust am Forum.

Dann bleibe ich lieber beim Lesen der FAQ oder Wiki, da bleibt das Unwesentliche aussen vor.

Ich danke hiermit Eurer Geduld mit mir, ich werde am Forum nun kein Interesse mehr zeigen und meinen Account löschen.

HUE

Hallo HUE,

Benchmarks sind schon wichtig.

Denn wenn es darum geht ein neues Firewall System zu implementieren (beim Kunden, oder in der eigenen Firma) dann muss man Systeme auch vergleichen können.

Es reicht leider nicht mehr aus nur mit Sicherheit zu argumentieren, sondern die Performance muss auch stimmen.
Dem Kunden ist es letztendlich egal ob es ein Linux system, Windows system oder BSD system ist. Die Leistung muss passen.
Und wenn der Kunde dann noch einen Artikel in der iX oder anderen "Fach"-Zeitschriften liest die beim Vergleich der Systeme für Linux sprechen, dann wird er zu xx% auch eine Linux Firewall haben wollen.

Beispielsweise sehe ich im 10 Gbit Ethernet Bereich schwarz für die PF unter OpenBSD bei vollast (ohne SMP funktion).
Leider hatte ich so ein System noch nicht in den Händen, aber ich denke das bei einem großen Regelwerk (sagen wir 500 Regeln und mehr) die Kisten unter Last schon probleme bekommen könnten (CPU Load auf einer Core, ....).

Für Standard FW Setups ist es heute fast egal was man nimmt. Es geht aber denke ich auch um die Enterprise, HPC Systeme und Rot/Schwarz Umgebungen. Letzteres ist sowieso sehr speziell auf Sicherheit getrimmt.
Das FreeBSD jetzt die PF mit SMP weiter entwickelt finde ich klasse. Denn dann können auch moderne Multicore CPU's genutzt werden :-)
Wenn dann noch netmap dazu kommt in FBSD 10, dann wird es interessant wie viele pakete pro sekunden durch den filter kommen, und wieviele ohne filter.

Mfg,

euer bofh

[Kamikaze]

Zitat von bofh_hannibal

Das FreeBSD jetzt die PF mit SMP weiter entwickelt finde ich klasse. Denn dann können auch moderne Multicore CPU's genutzt werden :-)

Nur so zur Erinnerung, wir sind hier im Thread zu NPF, der PF weiterentwicklung von NetBSD.

Auf FreeBSD waren wir nur gekommen weil die Frage im Raum stand, warum man mehrere SMP-fähige PF Versionen braucht.