Problem with ipfw table add 0.0.0.0/8

[Marcelo Gondim]

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 
>> <melifaro at freebsd.org <mailto:melifaro at freebsd.org>> 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
>>         <http://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 <cidr|u32|ifindex|iface>] [name
>>     "table_name"]
>>     * ipfw table <num|name> name "table_name"
>>     * ipfw table "table_name" type <cidr|u32|ifindex|iface>
>>
>>     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
>>     <num|all|name> 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