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
<melif...@freebsd.org <mailto:melif...@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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
