Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Jun 2014 16:43:46 +0400
From:      "Alexander V. Chernikov" <melifaro@FreeBSD.org>
To:        Ian Smith <smithi@nimnet.asn.au>
Cc:        Michael Sierchio <kudzu@tenebras.com>, freebsd-net@FreeBSD.org
Subject:   Re: ipfw table matching algorithm question
Message-ID:  <539D9502.5080102@FreeBSD.org>
In-Reply-To: <20140615221726.P609@sola.nimnet.asn.au>
References:  <CAHu1Y73LrdrWTZ4D_q=x67D3OdG9QpCy952-piwN0j6HRNsG9Q@mail.gmail.com> <539C9BD5.70302@FreeBSD.org> <539D70BB.70203@freebsd.org> <20140615215526.U609@sola.nimnet.asn.au> <539D8BDD.2080104@FreeBSD.org> <20140615221726.P609@sola.nimnet.asn.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On 15.06.2014 16:36, Ian Smith wrote:
> On Sun, 15 Jun 2014 16:04:45 +0400, Alexander V. Chernikov wrote:
>   > On 15.06.2014 16:01, Ian Smith wrote:
>   > > On Sun, 15 Jun 2014 18:08:59 +0800, Julian Elischer wrote:
>   > >   > On 6/15/14, 3:00 AM, Alexander V. Chernikov wrote:
>   > >   > > On 14.06.2014 21:35, Michael Sierchio wrote:
>   > >   > > > Luigi -
>   > >   > > >
>   > >   > > > Does table entry matching use a longest prefix match?
>   > >   > > I'm not Luigi, but the answer is "yes" anyway :)
>   > >   >
>   > >   > this may be about to change, because tables are getting  a rewrite,
>   > >   > but IP-based tables use the same code that the routing tables use.
>   > >
>   > > It'd be a bit anti-POLA for the longest prefix match behaviour to
>   > > change, though, especially with some tablearg usage.  Alexander?
>   > Well, "cidr" table are LPM by their nature.
>   > Additional algorithms for matching may be introduced (dxr, hashed tables for
>   > host-only prefixes)
>   > but it won't influence user-visible behavior for given type.
>
> Thanks for the confirmation .. nothing too scary so far, then .. but in
> what manner do you see integrating DXR into firewall table usage?
DXR (or any other similar algorithm) returns next hop index in case of 
match.
The only thing that is needed - is to add another indirection table w 
idx -> u32 values (or even IPv6 nexthop values).

You can take a look at current radix bindings here:
http://svnweb.freebsd.org/base/projects/ipfw/sys/netpfil/ipfw/ip_fw_table_algo.c?revision=267469&view=markup
>
> cheers, Ian
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539D9502.5080102>