[Bug 1328] New: Please allow ipset add and del via the /proc/net/xt_ipset mechanism
bugzilla-daemon at netfilter.org
bugzilla-daemon at netfilter.org
Mon Mar 25 21:48:49 CET 2019
https://bugzilla.netfilter.org/show_bug.cgi?id=1328
Bug ID: 1328
Summary: Please allow ipset add and del via the
/proc/net/xt_ipset mechanism
Product: ipset
Version: unspecified
Hardware: x86_64
OS: All
Status: NEW
Severity: enhancement
Priority: P5
Component: default
Assignee: netfilter-buglog at lists.netfilter.org
Reporter: murf at parsetree.com
I measure the xt_recent hash table's speed to enter an ip into the hash, and
compared with ipset add speed. recent, via this method:
echo +<addr> >/proc/net/xt_recent/DEFAULT
is 13 times faster than ipset add <addr>
Now, ipset has these advantages against recent:
recent has size limits you must define when you load the module. Ugh.
ipset, on the other hand, at least in the newer versions, (the ones NOT on
centos 6, btw), has no size limit.
So, a list of IP's with CIDRs, like voipbl, takes around 90 seconds to load the
63k ip's. recent will do it in about 7 seconds. (well, estimated, as recent
can handle only 8k entries (or at least so it did over a year ago).)
Can you guys, someday, sometime, enable this other, faster way to load up the
ipset with multiple thousands of addresses?
You know, it might even be faster if you allow a whole batch of + and -addrs in
a file, to be dumped at a single shot:
cat ipfile > /proc/net/xt_ipset/someipset
Many thanks!
--
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20190325/8cb79af1/attachment.html>
More information about the netfilter-buglog
mailing list