From owner-freebsd-net@FreeBSD.ORG Sun Jun 15 12:36:25 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 BBB4AA58; Sun, 15 Jun 2014 12:36:25 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 363692641; Sun, 15 Jun 2014 12:36:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s5FCaKls066941; Sun, 15 Jun 2014 22:36:20 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 15 Jun 2014 22:36:20 +1000 (EST) From: Ian Smith To: "Alexander V. Chernikov" Subject: Re: ipfw table matching algorithm question In-Reply-To: <539D8BDD.2080104@FreeBSD.org> Message-ID: <20140615221726.P609@sola.nimnet.asn.au> References: <539C9BD5.70302@FreeBSD.org> <539D70BB.70203@freebsd.org> <20140615215526.U609@sola.nimnet.asn.au> <539D8BDD.2080104@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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:36:25 -0000 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? cheers, Ian