per-interface packet filters

[Luigi Rizzo]

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