Problem with ipfw table add 0.0.0.0/8

[Alexander V. Chernikov]

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