I haven't perused netfilter code yet, so what I'll say is highly conjectural.
IMO, the single (1) rule will be a lot faster:
* Only 1 (one) check for whitelist
* x checks for blacklist-checks
Total checks (worst-case): 1+x (and if the negated result of whitelist
check == false, no need for x blacklist-checks)
Best case: 1 check ( IP in whitelist, so ! whitelist == false,
iptables' rule is short-circuited )
Rule (2):
* A total of x times ( whitelist check + blacklist-check )
Total checks (worst-case): x * 2
Best case: x * 1 ( only check against whitelist, but repeated for x rules )
The above makes perfect sense and is more or less what I assumed would
be the case, though I thought of even a better way, which would remove
the need of using a list-type set:
-m set ! --match-set whitelist src -j $BLACKLIST_PROCESSING_CHAIN
where $BLACKLIST_PROCESSING_CHAIN contains all the blacklist elements
and another jump to DROP - as is the case at present. There are at least
two major advantages as far as I can see: 1) I could log/see the number
of packets dropped for each particular blacklist-x set (something I
would have lost with the use of list-type set as everything would have
been lumbered in one place); and 2) performance-wise there won't be any
difference from what is the case at present - with deleting set members
and only using the blacklist-x sets, although I have to admit that if I
have used a single list-type set with a single iptables statement I
think the performance would have been a little bit better.
IMO, iptables lookups are much more expensive than ipset lookups. (
IOW, n * iptables checks is much more expensive than 1 * iptables
check against a setlist with n members ). So, the speedup of (1)
against (2) will be even more significant.
Absolutely - the main reason I switched to ipset, as asking iptables to
traverse through more than, say, 2500 statements in a single chain is
asking for trouble!
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
