Date: Mon, 13 Dec 2004 10:42:00 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Max Laier <max@love2party.net> Cc: freebsd-net@freebsd.org Subject: Re: per-interface packet filters Message-ID: <20041213104200.A62152@xorpc.icir.org> In-Reply-To: <200412131743.36722.max@love2party.net>; from max@love2party.net on Mon, Dec 13, 2004 at 05:43:26PM %2B0100 References: <20041213124051.GB32719@cell.sick.ru> <200412131743.36722.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 13, 2004 at 05:43:26PM +0100, Max Laier wrote: ... > > When managing a complex router with many interfaces the output > > of `ipfw show` (or ipf/pf analog) is getting long and difficult to > > understand. It is also important that many packets are checked > > against the rules that can never be applied to them, wasting CPU > > cycles. > > That's an error in the ruleset evaluation code then. Pf automatically jumps > over rules that cannot be matched after one failed. If you have a block of > 1000 rules "on xl0" and the first one does not match because of the interface > pf will continue checking with rule #1001. I am not sure if such shortcuts > are possible for ipfw, but I suggest looking into that first. well well well... what you say above just means that pf rules are internally stored 'per interface'. It is an optimization much like the one suggested in the original posting. I considered doing that when designing ipfw2 (implementing per-interface lists in addition to the global one, for backward compatibility), but then decided against it because 1) a simple initial switch based on the interface checks -- basically the way as julian suggested -- is very fast provided you don't have tens of interfaces (which, I admit, could be the case if you have many many vlans or ppp or ng nodes), and 2) this way you can do the initial demultiplexing in the most appropriate way for your configuration (e.g. based on protocol, interface name or type, direction, address ranges...) as opposed to TheOnlyWaySuppliedByTheSystem. Not that I am against adding the feature, but i think the performance gain is modest, and readability is not going to improve a lot because you have to remember the existance of global and per-interface rulesets (the former are mandatory for backward compatibility) and the criteria for using one or the other or both. In the end i think it confuses ideas even more. If you care about readability of the packet filter configuration, i think you are better off spending your time building suitable preprocessing tools, and commenting your configurations (remember that // style comments can be stored in ipfw2 rules and there is a listing mode that shows just action+comments, not even the rule bodies, so you can see what the configuration is supposed to do. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041213104200.A62152>