Date: Thu, 23 Jun 2005 00:15:57 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-net@freebsd.org, Jeremie Le Hen <jeremie@le-hen.org> Subject: Re: Policy routing idea (Was: ipfw: Would it be possible to continue processing rest of rules after match ?) Message-ID: <20050622221557.GU738@obiwan.tataz.chchile.org> In-Reply-To: <20050622114513.A97519@xorpc.icir.org> References: <42B7B352.8040806@suutari.iki.fi> <20050621170649.B82876@xorpc.icir.org> <42B94023.3090202@suutari.iki.fi> <20050622053307.B90964@xorpc.icir.org> <42B98FA0.3030805@suutari.iki.fi> <20050622092452.A95367@xorpc.icir.org> <20050622183400.GS738@obiwan.tataz.chchile.org> <20050622114513.A97519@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> i don;t understand what is the problem in defining a second action > 'setnexthop' which behaves as a nonblocking 'forward'. Implementationwise > you can share most of the code, it is just a matter of putting and > perhaps a flag in the structure that stores the nexthop depending > on the action specified on the command line. Same for printing. > > It does not break POLA and it lets you have both behaviours at > almost no cost. > > maybe net.inet.ip.fw.one_pass should not exist, but now it is > there and once again, we have to keep it for POLA. You are complely right. My wish would be to make ipfw minimalist, in other word no need to have either "setnexthop" or "tee" actions (respectively using non-blocking "forward" and "divert"). But this is pointless anyway as it would break POLA. Just for information, does this principle requires FreeBSD to keep existing option forever, or are there some scarce situations where some superfluous options could be deleted ? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050622221557.GU738>