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 <
melif...@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 <
melif...@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 <
melif...@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:
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.
Thanx for the nice work,
--WjW
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
