Re: ipset -R

[Mr Dash Four <mr.dash.four@googlemail.com>]

> 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!