From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 02:45:45 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 1122D9C9 for ; Mon, 2 Jun 2014 02:45:45 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE1182C0D for ; Mon, 2 Jun 2014 02:45:44 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 674CF139CA for ; Sun, 1 Jun 2014 23:40:11 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-type:content-type:in-reply-to:references:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1401676809; x=1402540810; bh=7bR1mp7mqCa4 ZrCm+dxYWU1UnNCnfacjTWXPXpzlyac=; b=crVHbTZumtZxrLY4U1NccbkN3/ec IyVJagxYSXRzSJ4lkizy3N/UmqfuMGekKj6tEL7vaJF8MTpXvZ6DSpzo37idA4ba nMtW54eWp0wlvbcPiQ1qr/26Xr66KgcbkhpwOTlyM/3EkVFcLqAXuywL84pGPk2b K536024YoBGSbNw= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJEZmm43KExn for ; Sun, 1 Jun 2014 23:40:09 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 56A0F139C9 for ; Sun, 1 Jun 2014 23:40:09 -0300 (BRT) Message-ID: <538BE3F9.5040500@bsdinfo.com.br> Date: Sun, 01 Jun 2014 23:39:53 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: FreeBSD Net Subject: Re: Problem with ipfw table add 0.0.0.0/8 References: <5371084F.1060009@bsdinfo.com.br> <5371112B.2030209@bsdinfo.com.br> <5371E9E7.70400@smartspb.net> <5371F4C8.3080501@FreeBSD.org> <53720AA4.80909@smartspb.net> <537767C5.80205@FreeBSD.org> <53777F09.5030000@FreeBSD.org> In-Reply-To: <53777F09.5030000@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 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: Mon, 02 Jun 2014 02:45:45 -0000 Em 17/05/14 12:23, Alexander V. Chernikov escreveu: > On 17.05.2014 19:14, Andreas Nilsson wrote: >> >> >> >> On Sat, May 17, 2014 at 3:44 PM, Alexander V. Chernikov >> > wrote: >> >> On 13.05.2014 16:05, Dennis Yusupoff wrote: >> >> I think that universal table for all kind of data (ipv4, >> ipv6, ports, >> etc) is a bad idea by design. At least unless you haven't any >> ability to >> >> It is not always "universal" in kernel. >> Actually, different radix tables are used to store both IPv4 and >> IPv6 in single table. >> >> specify address family on add, to avoid attempts to guess >> what user >> meant. Something like "ipfw table X add DEEF.DE >> ipv6". >> >> I'm going to add explicit table type/naming setup soon. >> Idea is the following: >> >> 1) Existing table can be named and addressed by either number or >> name. >> However, you still need to assign table number manually. >> >> 2) Table type/name can be specified explicitly via one of the >> following commands: >> * ipfw table 1 create [type ] [name >> "table_name"] >> * ipfw table name "table_name" >> * ipfw table "table_name" type >> >> 3) ipfw(8) stops trying to guess appropriate type based on used >> value. Instead, >> it requests table type from kernel and interprets value according >> to returned type. >> Default type for all tables is cidr >> >> 4) Table(s) can be returned to default values using ipfw table >> destroy. >> Destroy means: >> * flush >> * table tries (or other structures) freed >> * type set to cidr >> >> >> >> >> >> 13.05.2014 14:32, Alexander V. Chernikov пишет: >> >> On 13.05.2014 13:46, Dennis Yusupoff wrote: >> >> May be this will help? See answer on >> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/189471 >> >> I'll try to fix it within a few days. >> >> Fixed in r266310. >> >> With all of these changes, would it be possible to get tablearg to >> store ipv6 as well? I seem to remember it is 32bit only today. > Well, I'd prefer not to increase tablearg directly. > It is probably possible to implement some kind of "nexthop" table adds > additional auto-filled nexthop array. >> >> Best regards >> Andreas > Could tell if this patch is to be incorporated into the 10-stable? http://svnweb.freebsd.org/base?view=revision&revision=266310 Thanks and good job for all. []'s Gondim