Date: Mon, 23 Jan 2012 10:02:12 +0100 From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: Greg Hennessy <Greg.Hennessy@nviz.net>, freebsd-pf@freebsd.org Subject: Re: Getting Involved Message-ID: <CAPBZQG2nqsg45hhTnABWRSVoG6v2dX84_FmJP85ef9MNFc19RQ@mail.gmail.com> In-Reply-To: <E0053250-530D-4ADA-8230-E506814E475D@lists.zabbadoz.net> References: <CAConN%2BkZquK7MJ_6YPtEV=sJdqC%2BniRqMmp2ZgQL%2Bo2m1wvXSQ@mail.gmail.com> <CAPBZQG2S9T4v_4g09mXaukG4o3_4w8h51py6-iPoA%2BgmsuenUw@mail.gmail.com> <9EB23F6C23A8B6488E8BCC92A48E832612A5BC03A9@PEMEXMBXVS04.jellyfishnet.co.uk.local> <E0053250-530D-4ADA-8230-E506814E475D@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 22, 2012 at 3:50 AM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > > On 21. Jan 2012, at 23:26 , Greg Hennessy wrote: > > >>> > >> There is one catch. > >> FreeBSD does not want to break compatibility of old syntax and that is > why > >> i did not port the latest version of pf(4). > > > > Shades of the versioning/maintenance issues surrounding putting Perl in > the base way back in the day. > > > >> What is there now makes it 'trivial' to go to the latest pf(4) version > in > > > > Does that include the performance improvements which came with new > version? > > Would be interesting to know what impact if any they would have on the > FreeBSD PF port. > > Whatever performance improvements you are talking about is basically > irrelevant the way pf is written and designed, which is just another > obstacle in tracking Open. FreeBSD is no longer a UP-like operating > system. We'd need a larger mix of (just to name some) fine grained locking > (currently the 1 lock basically halts the network stack per packet going > through pf), a lot more cache friendly data structures, affinity, ... in > that area. Taking it to 10G or eventually 40G is really a different step > than squeezing another 50Mbit/s out of it by some optimization and > entangling it more and more with the rest of the network stack etc. > > > >> Open but there needs to be a layer of translation > >> for the old syntax to new syntax. > > > > As a one off translation when someone upgrades Major version numbers to > the FreeBSD version hosting the new PF code? > > Or run every time when someone loads the security policy for now and the > foreseeable future? > > Let's say pf ruleset instead of security policy (which is also used in > various other ways). The basic problem is that the syntax is known to > management tools but also the user space-kernel API is exposed to 3rd party > tools. Breaking any is bad. The latter we can break with major versions > though preferably we'd love not to. The way things are written it's > basically not possible not to break it even when bringing in cherry picked > features like NAT64 etc. It's an obstacle to some of our consumers though. > The moment you update your kernel and pfctl doesn't speak the same > language anymore you lost your firewall. And it's not uncommon to upgrade > a kernel going from x.y to x.y+n for example, wait a week or two before > updating all user land etc. > > It's the same problem with pfsync; you can have two old version ones, > reboot the first, not able to sync things to the new as it doesn't > understand the old anymore and by the time you reboot the 2nd things > *oops*. That's not an upgrade path for a HA setup unfortunately and we had > that happen way too often to our users - once again with 9. > > There are solutions to this as well, depending on the work you put on to it. > > >> That is the only reason its not been done. > > > > I can see the issues, hope it's not intractable. > > The new syntax is a significant improvement, shame about lack of thought > given to backward compatibility. > > You are preaching to the wrong choir:( > > > > With your expert knowledge on this Ermal, is it possible to run both > old and new PF parsers in there to generate a policy which would run > against the newer packet filtering engine code? > > If you write the translation stub you might succeed. Have fun... *cough* > > Depending on the experience *cough* you can be more confident. This depends on two factors and depending on which side you put it, sponsored side or free cycle development side! > > > Defaulting to the old syntax, with say something like a ' > later_pf_enable="yes"'' in rc.conf or a single 'use' line at the top of > pf.conf to switch to the new syntax? > > You can even have two different pf's loadable by the kernel (at least one > at a a time) if doing it clever given pfil hooks. But maintaining more > than 1 is not going to happen for and in Free. > > I do not think this is doable at all! > > There are basically two options: 1) we can make it work well or 2) you > can always have the newest syntax and regularly break and not perform. > Pick any single one at this point and let us know which one you'd prefer. > > > It is not so simple as you make it be. The changes help in this regard and there are people on Open side that want SMP scalability, but there is no commitment as always. > A couple of developers lately had this discussion (though not everyone was > present). I'll however be curious which way our users want it to be ... > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > It does not matter how good you are. It matters what good you > do!_______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > -- Ermal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPBZQG2nqsg45hhTnABWRSVoG6v2dX84_FmJP85ef9MNFc19RQ>