Date: Sat, 02 Aug 2014 01:08:46 +0400 From: "Alexander V. Chernikov" <melifaro@FreeBSD.org> To: freebsd-ipfw <freebsd-ipfw@freebsd.org>, "freebsd-net@freebsd.org" <freebsd-net@FreeBSD.org> Cc: Luigi Rizzo <rizzo@iet.unipi.it> Subject: ipfw named objejcts, table values and syntax change Message-ID: <53DC01DE.3000000@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
Hello all.
I'm currently working on to enhance ipfw in some areas.
The most notable (and user-visible) change is named table support.
The other one is support for different lookup algorithms for different
key types.
For example, new ipfw permits writing this:
ipfw table tb1 create type cidr
ipfw add allow ip from table(tl1) to any
ipfw add allow ip from any lookup dst-ip tb1
ipfw table if1 create type iface
ipfw add skipto tablearg ip from any to any via table(if1)
or even this:
ipfw table fl1 create type flow:src-ip,proto,dst-ip,dst-port
ipfw table fl1 add 10.0.0.5,tcp,10.0.0.6,80 4444
ipfw add allow ip from any to any flow table(fl1)
all these changes fully preserve backward compatibility.
(actually tables needs now to be created before use and their type needs
to match with opcode used, but new ipfw(8) performs auto-creation
for cidr tables).
There is another thing I'm going to change and I'm not sure I can keep
the same compatibility level.
Table values, from one point of view, can be classified to the following
types:
- skipto argument
- fwd argument (*)
- link to another object (nat, pipe, queue)
- plain u32 (not bound to any object) (divert/tee,netgraph,tag/utag,limit)
There are the following reasons why I think it is necessary to implement
explicit table values typing (like tables):
- Implementing fwd tablearg for IPv6 hosts requires indirection table
- Converting nat/pipe instance ids to names renders values unusable
- retiring old hack with storing saved pointer of found object/rule
inside rule w/o proper locking
- making faster skipto
So, as the result, table will have lookup key type (already done),
value type ('skipto', 'nexthop', 'nat', 'pipe', 'number', ..) and some
additional restrictions (like inability to add non-existing nat instance
id).
This change will break (at least) scenarios where people are
using one table for both nat/pipe instances (and keep nat ids in sync
with pipe ones). For example:
ipfw table 1 add 10.0.10.0/24 110
ipfw table 1 add 10.0.20.0/24 120
ipfw add 100 nat tablearg from table(1) to any via vlanX in
..
ipfw add 500 pipe tablearg from table(1) to any via ix0 out
It looks like it is not so easy to bind values for given table to
different objects (or different tasks) (and lack of compatibility kills
hope for MFC).
Ideas?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53DC01DE.3000000>