Ken Gunderson <[EMAIL PROTECTED]> writes: > I've been using pf a long while now - since before it featured > "tables". Out of habit I mostly define things using lists, and reserve > tables for really large things like spamd, bogons, and things that I > need to change/update on the fly. More recently I'm wondering if > tables shouldn't be used for more or less everything. Are there any > reasons to prefer lists over tables (or vice versa) for the smaller > sized stuff, e.g. /29 - /26 subnets? Any comments about when should one > not use tables?
If you look at your PF rules using the pfstat command, you'll see that all the rules that have lists are expanded into several rules, one per list item if you have one list (if you have two lists, then the number of rules will be the number of all possible pairs of items from both lists). A rule that contains one or two tables will not get expanded. The items of a table are stored non-linearly, so checking a packet against a table is more efficient than linearly going through a bunch of rules. The way I understand it, the tables are preferable because (1) checking a packet against a table is more efficient, and (2) you can modify the tables at run time without changing the rule set. Whether it is worthwhile for you to change from lists to tables depends, probably, on the size of your rule set, size of the lists, and the amount of filtered traffic. I am having problems with using tables with nested anchors. I seem to not be able to use tables at the second level of nested anchors. :( I need to do some more testing, after which I'll send a bug report about it. -- Arcady Genkin : CDF Systems Administrator http://www.cdf.toronto.edu/~agenkin/contact.html
