Max entries for ipsets

[Steve8291]

I was wondering if you could help me in understanding the wiki page for iprange.
I've been trying to understand how to best reduce my ip sets. From what I can tell an ipset can be millions of entries long and there will be no appreciable loss in speed. The only trade off is in ram usage. The larger the set the greater the ram. Do you know if that is really the case?

I have a raw country.list that is 19193 entries long, with 19 CIDRs, and takes up .48MB or ram by running
ipset list country.list
If I run iprange like this:
iprange -v --ipset-reduce 0 --ipset-reduce-entries 100000 country.list >/dev/null
I get a set that contains:
3 CIDR prefixes
64012 entries
Ram now nearing 1.5MB

I have other sets using as much as 23MB of ram, 26 CIDR prefixes, and over 90000 entries. I could reduce them further but they are going to get tremendously huge.
Do you have any thoughts on if this will slow the network down or if the only adverse effect is ram consumption?
Is there an amount of ram I should be trying to keep my sets under?

Thanks for creating such a great tool.

[ktsaou]

ok nice. Thanks!

When you say it takes 48MB or ram, what do you measure? iprange memory? kernel ipset memory?

[Steve8291]

I am using ipset to output the info on the set. So I assume this is system ram that ipset is using for that set. Ex:
ipset list blacklist | head
Output:

Name: blacklist
Type: hash:net
Revision: 6
Header: family inet hashsize 2048 maxelem 9120
Size in memory: 162232
References: 1
Members:
208.73.23.46
66.227.214.36
67.77.115.132

[ktsaou]

Can you post the one it says 48MB?

[Steve8291]

Had to regenerate it since I deleted it. Can't figure out what I did to get that really large list but here is one that is pretty big.

root@server:~/ipset# ipset list firehol | head
Name: firehol
Type: hash:net
Revision: 6
Header: family inet hashsize 262144 maxelem 553894
Size in memory: 15288088
References: 0
Members:
45.40.164.136/30
67.225.148.128/28
198.12.105.90/31

That's 14.6MB (13403576 bytes) after being reduced with the default settings in iprange.

root@server:~/ipset# iprange -v firehol.list >/dev/null
iprange: Loading from firehol.list
iprange: Loaded optimized firehol.list
iprange: Printing combined ipset having 90684 entries, 1605155240 unique IPs

553894 printed CIDRs, break down by prefix:
	- prefix /7 counts 3 entries
	- prefix /8 counts 10 entries
	- prefix /9 counts 11 entries
	- prefix /10 counts 21 entries
	- prefix /11 counts 47 entries
	- prefix /12 counts 93 entries
	- prefix /13 counts 180 entries
	- prefix /14 counts 471 entries
	- prefix /15 counts 1242 entries
	- prefix /16 counts 2733 entries
	- prefix /17 counts 2908 entries
	- prefix /18 counts 5602 entries
	- prefix /19 counts 9214 entries
	- prefix /20 counts 13026 entries
	- prefix /21 counts 16681 entries
	- prefix /22 counts 20766 entries
	- prefix /23 counts 24620 entries
	- prefix /24 counts 29608 entries
	- prefix /25 counts 30336 entries
	- prefix /26 counts 34600 entries
	- prefix /27 counts 39488 entries
	- prefix /28 counts 45964 entries
	- prefix /29 counts 54200 entries
	- prefix /30 counts 63693 entries
	- prefix /31 counts 74571 entries
	- prefix /32 counts 83806 entries

totals: 553894 lines read, 90684 distinct IP ranges found, 26 CIDR prefixes, 553894 CIDRs printed, 1605155240 unique IPs
completed in 0.58285 seconds (read 0.21686 + think 0.00000 + speak 0.36599)

[ktsaou]

Well, this is the trade off.

As the wiki page says, for each prefix in an ipset, another lookup is made by the kernel. If you give it 20 prefixes, the kernel will do 20 lookups for each packet it checks against this ipset.

Depending on the amount of traffic on your systems and the design of your firewall, this may or may not affect performance. In general, the kernel is very fast, and most probably you will notice increased CPU utilization and system load if the amount of traffic is huge.

The design of your firewall is important too. You should utilize the connection tracker, so that only the first packet of each connection is checked against the ipset. So, once the connection is accepted, all other packets will just flow unchecked. If you use firehol, set FIREHOL_RULESET_MODE="optimal" at the top of your configuration. It does exactly that. (the default is FIREHOL_RULESET_MODE="accurate", which checks all packets in both directions: https://github.com/firehol/firehol/blob/b59bf2524f395b9e9f2832653a6f53c27f5fdc40/sbin/firehol#L378-L395)

[Steve8291]

Thanks. I am using connection tracker so it should all work out fine.
I think I figured out the source of some of my confusion though:
ipset -v setname >/dev/null
Gives the original info on the set before it was optimized.
I was using that to check for the present optimized state of the set.
Is there any way to have iprange check the present level of optimization?

[ktsaou]

Is there any way to have iprange check the present level of optimization?

Something like this?

ipset -L NAME | grep ^[0-9] | iprange -v >/dev/null

[Steve8291]

Just gives me the same result.
I have a set I've optimized down to 1 prefix and saved.
When I look at it I can see they all have 1 prefix.
Running iprange -v on it shows it has 8 CIDR prefixes.
I think it must only show the output of running the defaults:
iprange -v --ipset-reduce 20 --ipset-reduce-entries 16384