On Thu, Jan 15, 2004 at 04:54:12PM +1300, Russell Fulton wrote:
> My question for the list is what is a sensible value for "n"?
I can't find the reference off-hand, but a benchmark showed the
break-even point is below 10 addresses (a table with more addresses is
faster than individual rules per address).
The constant cost of the table lookup isn't high, though. So even if you
get tables with just 1-10 entries, the slight performance hit is usually
by far outweighed by the advantages of a simpler ruleset design.
The advantage of tables is that you can modify the address lists cheaply
(without reloading the rules). You could use tables as conditions for
branching into subrulesets (anchors). If a host can fall into a category
that requires not just a single rule, but a more complex policy, an
anchor per category might be a good idea. Then you can even modify
categories (and associations of hosts with categories) without ever
touching the main ruleset. Which greatly reduces conflicts when a daemon
needs to make changes automatically.
As an example,
main ruleset
anchor category-1 from <table-1>
anchor category-2 from <table-2>
...
<global rules>
anchor ruleset, for instance category-1:first, only evaluated when
source matches table-1
pass from any to any port 80 keep state
pass from any to any port 445 keep state
...
Now, the daemon would have to modify only the tables and subrulesets,
and manual changes to the global rules (and reloading the main ruleset)
wouldn't interfere with the automatically managed anchors and tables.
A simpler setup would be
main ruleset
anchor automatic
<global rules>
single anchor for automatic rules, always evaluated, but containing
multiple subrulesets, all of which are evaluated
automatic:category-1
pass from <table-1> to any port 80 keep state
...
automatic:category-2
pass from <table-2> to any port 445 keep state
...
This doesn't use conditional evaluation of the anchor (so all rules of
all subrulesets are always evaluated), but requires only a single
anchor. This is what authpf does.
I wouldn't start putting category rules into the main ruleset for
performance reasons (because a table only contains a single address),
unless you really hit the CPU limit with ruleset evaluations (which is
rare when filtering statefully, as evaluation only occurs once per
connection, not once per packet).
Daniel
