On Wed, 8 Jun 2011, Mr Dash Four wrote:
> 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.
Current behaviour cannot be modified easily. There's no overlap checking
(and aggregation/breaking up) in ipset, so it can't be prevented that
someone adds overlapping elements to a set:
add 10.16.0.0/16
add 10.16.1.0/24
Now if 10.16.1.0/24 is tested as you suggest, one cannot tell whether the
explicit network 10.16.1.0/24 is added to the set or the tested elements
are just the members of a larger network.
Currently:
test 10.16.1.1 => test explicit and implicit membership
test 10.16.1.0/24 => test explicit membership only
What you propose is to test explicit and implicit membership in all cases.
My top priority now is to get the kernel in sync with ipset 6.7. It's just
a much higher problem, because a lot of features and fixes are missing,
even from the newest kernel version.
Best regards,
Jozsef
-
E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
--
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
