Easy to see that 10.10.0.137/255.255.0.255 (256 addresses) is translated by Mikrotik to ip address range 10.10.0.137-10.10.255.137. But this address range is actually consists of (tested):
What I’m doing wrong?
It’s a bug in netmask-to-range translation?
Or in range interpretation?
Or 10.10.0.137/255.255.0.255 it totally invalid and not supported address?
Is there any other way to specify ip address with non-continuous netmask?
This is a situation where the bitmap address lists I mentioned at the Amsterdam MUM could be useful.
People who want noncontinuous ranges of addresses in a filter but do not want the overhead they envision when
picturing a hashed list of subnets in an address list (actually it is not that bad, but still…) could use a bitmap
address list. You fill it with addresses and subnets, maybe you could even have some wildcard notation,
and the matching is still very quick and not dependent on the number of entries in the list.
It could be nice but how would such a netmask translate into a prefix length?
Netlink, used to communicate to the kernel routing engine, needs prefix lengths, not quad dot netmasks.
That means that any such route or rule must be expanded to contiguous elements for sending to the kernel. The results would be a total mess. In your example: describe one route, generate 256 routes, which must exist individually in kernel routing space. Now try to read them back and reaggregate them.
@normis,
thank you. Sad but “do not argue with weather”.
Probably it would be wise to issue an error when entering not continuous netmask instead of convert it to the wrong range…
Could you please provide a link to consideration or sample of the mentioned “bitmap address list” ? As I understood such mechanism does not yet exists, right?
PS. In my network configuration I have 56 filials (second octet of address) with 27 address-groups based on third octed with different access rights. So I should create 27 address-lists with 56 elements in each based on “use address lists” aproach. Yes, for-loops are very useful, but…
Not referring to that, but to the feature in Linux “ipset” (I presume that is what is below address lists)
to create a set that is a bitmap instead of a hash list of addresses or subnets (which I think you are using).
With a bitmap ipset you can check if an address is in the list by only checking a single bit that is computed
from the address. Unfortunately in ipset bitmap the set has to be pre-created and it has a fixed maximum
size of /16. That is probably where the site you refer to would come in, it would be nice if you could
create a bitmap for the entire internet. Also for dynamic blacklisting of attackers, etc.
Of course to store the entire range of 0.0.0.0 - 223.255.255.255 in a set you would need 448MB of memory,
or 512MB for the entire 0.0.0.0 - 255.255.255.255 range. That is where bitmap compression becomes useful.
But for the purpose as indicated in this thread and the one you refer to, a list limited to a /16 range would
also be useful.
Furthermore, in “ipset” it is also possible to make a set that as members has other sets. That would
translate to an address list that has address lists as members. Each of them could be a /16 bitmap and
this way you can have a slightly larger workable set for a bitmap, e.g. the 172.16.0.0/12 range as 16 bitmaps.