From owner-freebsd-net@FreeBSD.ORG Sun Jun 15 12:46:00 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45319F12; Sun, 15 Jun 2014 12:46:00 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0593D272A; Sun, 15 Jun 2014 12:46:00 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Ww5tc-00080f-M8; Sun, 15 Jun 2014 12:34:36 +0400 Message-ID: <539D9502.5080102@FreeBSD.org> Date: Sun, 15 Jun 2014 16:43:46 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: ipfw table matching algorithm question References: <539C9BD5.70302@FreeBSD.org> <539D70BB.70203@freebsd.org> <20140615215526.U609@sola.nimnet.asn.au> <539D8BDD.2080104@FreeBSD.org> <20140615221726.P609@sola.nimnet.asn.au> In-Reply-To: <20140615221726.P609@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Sierchio , freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 12:46:00 -0000 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 >