Date: Sun, 01 Jun 2014 23:39:53 -0300 From: Marcelo Gondim <gondim@bsdinfo.com.br> To: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Problem with ipfw table add 0.0.0.0/8 Message-ID: <538BE3F9.5040500@bsdinfo.com.br> In-Reply-To: <53777F09.5030000@FreeBSD.org> References: <5371084F.1060009@bsdinfo.com.br> <F78BF3AC-F031-4528-A4C1-5B22E88CEC00@dataix.net> <5371112B.2030209@bsdinfo.com.br> <5371E9E7.70400@smartspb.net> <5371F4C8.3080501@FreeBSD.org> <53720AA4.80909@smartspb.net> <537767C5.80205@FreeBSD.org> <CAPS9%2BSv8jj7R4aTeyYwxEs8=UQuS4UqFzASmrYggzqF4bOPf=g@mail.gmail.com> <53777F09.5030000@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org <mailto:melifaro@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?538BE3F9.5040500>