Date: Sat, 17 May 2014 23:58:44 +0400 From: "Alexander V. Chernikov" <melifaro@FreeBSD.org> To: Barney Wolff <barney@databus.com> Cc: Dennis Yusupoff <dyr@smartspb.net>, FreeBSD Net <freebsd-net@freebsd.org>, Marcelo Gondim <gondim@bsdinfo.com.br> Subject: Re: Problem with ipfw table add 0.0.0.0/8 Message-ID: <5377BF74.6010006@FreeBSD.org> In-Reply-To: <20140517195754.GA1087@pit.databus.com> 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> <20140517195754.GA1087@pit.databus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17.05.2014 23:57, Barney Wolff wrote: > On Sat, May 17, 2014 at 05:44:37PM +0400, 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 <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 > Please avoid violating POLA. I for one have scripts that automatically add > entries and would need to be modified if separate ipfw tables become required > for ipv4 and ipv6. I'd have no problem, of course, with changes to ipfw I haven't said anything about splitting IPv4 and IPv6 tables. > internals as long as the existing public API continues to work. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5377BF74.6010006>