Date: Thu, 14 Aug 2014 17:52:49 +0200 From: Willem Jan Withagen <wjw@digiware.nl> To: "Alexander V. Chernikov" <melifaro@yandex-team.ru>, Luigi Rizzo <rizzo@iet.unipi.it> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Luigi Rizzo <luigi@freebsd.org>, freebsd-ipfw <freebsd-ipfw@freebsd.org>, "Andrey V. Elsukov" <ae@freebsd.org> Subject: Re: [CFT] new tables for ipfw Message-ID: <53ECDB51.2030201@digiware.nl> In-Reply-To: <53ECD3DA.6060501@yandex-team.ru> References: <53EBC687.9050503@yandex-team.ru> <CA%2BhQ2%2Bg=A_rLHCVpBqn0AtFLu_gNGtzbmXvc-7JhpLqPSWw44A@mail.gmail.com> <53EC880B.3020903@yandex-team.ru> <CA%2BhQ2%2BiPPhy47eN0=KaSYBaNMdObY20yko7dRY1MMuP_mfnmOQ@mail.gmail.com> <53EC960A.1030603@yandex-team.ru> <CA%2BhQ2%2BgxVYmXb%2BHOw4qUm6tykmEvBRkrV0RhZsnC6B08FLKvdA@mail.gmail.com> <53ECA6B2.8010003@digiware.nl> <53ECD3DA.6060501@yandex-team.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14-8-2014 17:20, Alexander V. Chernikov wrote: > On 14.08.2014 16:08, Willem Jan Withagen wrote: >> On 2014-08-14 13:15, Luigi Rizzo wrote: >>> On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov < >>> melifaro@yandex-team.ru> wrote: >>> >>>> On 14.08.2014 14:44, Luigi Rizzo wrote: >>>> >>>> >>>> >>>> >>>> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov < >>>> melifaro@yandex-team.ru> wrote: >>>> >>>>> On 14.08.2014 13:23, Luigi Rizzo wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov < >>>>> melifaro@yandex-team.ru> wrote: >>>>> >>>>>> Hello list. >>>>>> >>>>>> I've been hacking ipfw for a while and It seems there is something >>>>>> ready >>>>>> to test/review in projects/ipfw branch. >>>>>> >>>>> >>>>> this is a fantastic piece of work, thanks for doing it and for >>>>> integrating the feedback. >>>>> >>>>> I have some detailed feedback that will send you privately, >>>>> but just a curiosity: >>>>> >>>>> ... >>>>>> >>>>>> Some examples (see ipfw(8) manual page for the description): >>>>>> >>>>>> >>>>>> ... >>>>>> >>>>>> >>>>>> ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" >>>>>> >>>>> >>>>> why do we need to specify mask lengths in the above ? >>>>> >>>>> Well, since we're hashing IP we have to know mask to cut host >>>>> bits in >>>>> advance. >>>>> (And the real reason is that I'm too lazy to implement hierarchical >>>>> matching (check /32, then /31, then /30) like how, for example, >>>>> >>>> >>>> oh well for that we should use cidr:radix >>>> >>>> Research results have never shown a strong superiority of >>>> hierarchical hash tables over good radix implementations, >>>> and in those cases one usually adopts partial prefix >>>> expansion so you only have, say, masks that are a >>>> multiple of 2..8 bits so you only need a small number of >>>> hash lookups. >>>> >>>> Definitely, especially for IPv6. So I was actually thinking about >>>> covering >>>> some special sparse cases (e.g. someone having a bunch of /32 and a >>>> bunch >>>> of /30 and that's all). >>>> >>>> Btw, since we're talking about "good radix implementation": what >>>> license >>>> does DXR have? :) >>>> Is it OK to merge it as another cidr implementation? >>>> >>> >>> "cidr" is a very ugly name, i'd rather use "addr" >>> >>> DXR has a bsd license and of course it is possible to use it. >>> You should ask Marko Zec for his latest version of the code >>> (and probably make sure we have one copy of the code in the source >>> tree). >>> >>> Speaking of features, one thing that would be nice is the ability >>> for tables to reference the in-kernel tables (e.g. fibs, socket >>> lists, interface lists...), perhaps in readonly mode. >>> How complex do you think that would be ? >> >> I'm a very happy user of ipfw and I think these are nice improvements >> and will make things more flexible... >> >> I have 2 nits to pick with the current version. >> >> I've found the notation ipnr:something rather frustrating when using >> ipv6 addresses. Sort of like typing a ipv6 address in a browser, the >> last :xx is always interpreted as portnumber, UNLESS you wrap it in []'s. >> compare >> 2001:4cb8:3:1::1 >> 2001:4cb8:3:1::1:80 >> [2001:4cb8:3:1::1]:80 >> The first and the last are the same host but a different port, the >> middle one is just a different host. >> >> Could/should we do the same in ipfw? > Well, we should, but I'm unsure if we have host:port notation anywhere > in current (or new) syntax: I can not answer that right from the top of my head. But I remember digging in the code to see how adresses were converted and how IPv6 fitted in there. And that because of the problem described above. But the main reason for "reporting" this, is that I forsee to possibility that with the new syntax it might be possible to run into this. But you have disgned the syntax, so I'll take your word for it that would not happen. >> And I keep running into the >> ipfw add deny all from table(50) to any >> notation. the ()'s need to be escaped in most any shell. Where as I >> look at the syntax there is little reason to require the ()'s. >> the keyword table always needs to be followed by a number (and in the >> new version a (word|number) ). > We need _some_ discriminator to ensure that the next parameter after > "to" or "from" is not hostname. > We also have some other places where tables are used: "via > interface|table(X)", lookup X, flow table(X) [new]. > I agree that parenthesis might not be the best choice. (and something > like :tablename:, %tablename%, or even table:tablename might look better). > Theoretically, we can support both (old/new) and show rules with new one > by default. (I'm looking at this from a parseable grammar view, perhaps not 100% fitting) Well my argument is that after the table-keyword "table" there would always be the table-identifier, be it a name or a number. So "table" is a reserved word, now this would exclude hostnames called "table", is that (your) problem? So while parsing the keyword would always consume the next token as the qualifier that goes with the table-keyword. If that results in a not parseable sentence then the sentence needs to be rejected. Regards, --WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53ECDB51.2030201>