From: Mr Dash Four <mr.dash.four@googlemail.com>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: "netfilter@vger.kernel.org" <netfilter@vger.kernel.org>
Subject: Re: ipset v6.latest bugs?
Date: Tue, 26 Apr 2011 16:04:29 +0100 [thread overview]
Message-ID: <4DB6DEFD.6020101@googlemail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1104261542470.1834@blackhole.kfki.hu>
> Due to the restarting bug (add the first element again) and failing as it
> is already added, the resizing happened once.
OK, I'll wait for this to be fixed then.
> As I wrote, for a few weeks I won't have time to deal with adding new
> features.
>
No worries, I was just not sure why was this dropped as port ranges used
to be part of other sets implemented in this version, not to mention
that these features existed across the board in earlier ipset versions too.
In the meantime I may be sticking with 4.5 until this is implemented as
I have boxes which I cannot upgrade to the new version of ipset due to
constrains with the kernel, so I do not have the appetite, nor desire,
to spend long hours altering my entire build just because the hash:net
set in the new ipset version can't handle ip ranges - it would be a
nightmare to maintain two different build paths simply because of that
single issue. I suspect that was the reason why iptree(map) sets got
"converted" to hash:ip instead of hash:net.
>> ipset -L on a iptreemap type set tells different - it contains a single
>> element - 10.1.0.0/16 - and that's it! It is even better because I could use
>> both forms - cidr and ranges alike - and it shows me the ip address ranges
>> when I list the actual set. In that respect iptreemap's implementation is much
>> better than what currently exists with hash:net set in 6.4!
>>
>
> iptreemap is clever enough to collapse the successive elements into ranges
> in the output. But internally all network, range added to an iptreemap
> type is expanded into the individual IP addresses.
>
Maybe that would explain the massive amount of time it takes to load all
these address ranges and hog my entire system in the process?
next prev parent reply other threads:[~2011-04-26 15:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-25 11:55 ipset v6.latest bugs? Mr Dash Four
2011-04-25 20:03 ` Jozsef Kadlecsik
2011-04-25 20:36 ` Mr Dash Four
2011-04-25 21:51 ` Jozsef Kadlecsik
2011-04-26 0:38 ` Mr Dash Four
2011-04-26 13:57 ` Jozsef Kadlecsik
2011-04-26 15:04 ` Mr Dash Four [this message]
2011-04-26 23:18 ` Mr Dash Four
2011-04-27 7:15 ` Jozsef Kadlecsik
2011-04-27 12:00 ` Mr Dash Four
2011-04-27 21:27 ` Jozsef Kadlecsik
2011-04-27 21:40 ` Mr Dash Four
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DB6DEFD.6020101@googlemail.com \
--to=mr.dash.four@googlemail.com \
--cc=kadlec@blackhole.kfki.hu \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).