I can only repeat myself: for the hash:*net* types the testing with a host
address is special and handled as the kernel would test an IP address.
However network addresses are handled as a whole and overlapping is *not*
checked. It's documented in the manpage.
I can understand that to a point as far as adding/deleting
elements/subranges goes - it makes sense. Testing, however, is a
different story.
Maybe an example helps: when you add 10.6.0.0/16, you add an "apple". You
can also add 10.6.0.0/24, a "pear". Nothing prevents you, both can be the
member of the set, because overlapping is not handled. At deleting,
testing they are handled as "apple" and "pear", too. If "pear" is not
added to the set, it's not "in" the set as a member - even if we know,
that the elements of "apple" fully cover the elements of "pear". However
at testing 10.16.224.1[/32] you test a "seed", which is checked inside
"apple".
Your basic presumption above is wrong - 10.16.224.1 *is* a member - i.e.
it belongs, in network terms at least - to both 10.16.0.0/16 and
10.16.224.0/24 ranges. Similarly, 10.16.224.0/24 also belongs to
10.16.0.0/16 in the same way that 10.16.224.1 does to 10.16.224.0/24 and
10.16.0.0/16.
10.16.224.1 is a member of the 10.16.224.0/24 "set", which, in turn, is
also a member of 10.16.0.0/16 "set" (in mathematical as well as in
networking terms). They are both in a way "subsets". Any tests for
matching a subset belonging to a bigger set should return positive
results. In the case of ipset they don't and that is my point.
There are no "apples" and "oranges" compared here as both ranges belong
to each other, so they are not different from each other, apart from the
fact that one set is bigger than the other. Basic grasp of maths would
tell you all that.
Merging with already existing elements (or breaking up if a network from a
larger network were deleted) would be very expensive. I know, you compare
the types to iptreemap, but iptreemap was a very special case where
merging/breaking up was a natural process and costed almost nothing.
No, I don't make comparisons with iptreemap at all - there is no
iptreemap set type involvement here, so there is no need for me to
mention that type of set.
My basic (and only!) issue is that subnet ranges testing should either
be implemented properly or not tested at all. The way I see it, that is
not the case and I pointed out above why I think that is.
That's all well and good for hosts, but ip ranges should either be tested
properly or testing of those should be disabled altogether (which, if
introduced, would be a severe restriction for me - I am not going to run a
couple of thousand "ipset t" tests just to see that all of the single IP
addresses in the range I am interested in match - that simply isn't going to
happen!).
I don't quite follow you here:
OK, if I have 10.16.0.0/16 as a member and then test a subnet range
which is covered by the /16 address - again, lets say 10.16.1.0/24 - I
expect to get a match as clearly, from both mathematical as well as
networking terms, all "members" of 10.16.1.0/24 are also "members" of
10.16.0.0/16, so the test result should return a positive. It doesn't!
I can understand a negative result if I test the other way around - not
all "members" of 10.16.0.0/16 would belong to 10.16.1.0/24 and returning
a negative test result in this instance is OK.
It doesn't work like that in ipset though - ipset seems to be operating
either on "exact match" (say if I have 10.16.0.0/16 as a member and test
with 10.16.0.0/16) or when a single ip address is tested, which I don't
think is right and that was my point all along.
--
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
