Several points.
First, the error message itself tells you what is wrong. The
target is a prefix (subnet), so .151/32 is OK but .151/24 is not because non-zero bits of the address exist on the bit positions that are zero in the mask. The only place where you can use the shortcut form of .151/24 is when you define the IP address together with the subnet this way; everywhere else (item of an
address-list,
dst-address of a
route,
target of
/queue simple item, ...) the address bits must be zero where the mask bits are zero.
Second, there are two basic categories of queues - the pcq ones and the rest, which is the "normal" ones. The "normal" ones have no embedded intelligence, so they handle all the traffic of the target equally. The pcq ones behave as autonomous queue trees - they autonomously sub-classify the traffic they get and they apply the limitations to each class separately. You can define which properties of a stream (connection) will be taken into account. Any combination of source address, destination address, source port, destination port can be used for that.
So to reach your goal of giving each tenant some guaranteed bandwidth and possibly also some bonus bandwidth they can use while others aren't maxing out their guaranteed quotas, you have two options:
- to configure a dedicated simple queue for each tenant, setting its target to the individual IP address of the tenant
- to configure a single pcq-type simple queue for all of them, setting its target to the whole subnet (10.0.0.0/24 in your case) and setting its pcq-classifier to dst-address for the download queue and to src-address for the upload queue.
The first approach is more complex, the second one may be too limiting when you want to give different bandwidth limits to different tenants. But you can combine the approaches as the rules in
/queue simple (and in
/queue tree as well) are evaluated top to botom until first match, like firewall rules. So if there are some small businesses among the tenants, you assign them e.g. addresses from 10.0.0.0/28, put the queue rules for them higher in the list, with this more specific prefix (10.0.0.0/28) in
target, and then place the single queue rule for "the rest", with
target=10.0.0.0/24.
See
https://wiki.mikrotik.com/wiki/Manual:Q ... Q_Examples for more details.
Third, I suppose each tenant will get just a single IP address from you and you expect them to NAT their home network to it. So you probably want to make sure that they don't connect a switch and use multiple addresses from 10.0.0.0/24 to overcome the bandwidth limitations, which is complicated unless the switch they are connected to is a managed one and you can somehow enforce a single MAC per port on it. But if the router doing the NAT is provided by you, you can restrict the service only to known MAC addresses. Tenants who wish to use their own routers will have to tell you the MAC address of its WAN interface so that you could allow it.
Outside the bandwidth shaping topic:
- it is a recommended security measure to prevent direct L2 forwarding between tenants, because if one of them has some malware on their gear, it cannot spread to the other ones (unless it manages to infect your own gear of course, so make sure your firewall prevents tenants from managing any of your own gear). This is called port isolation and it also requires a manageable switch supporting such function.
- unless you get an IP address from 100.64.0.0/10 from the upstream ISP, it is recommendable to use this range for the tenants. The thing is that this range is not in conflict with any private IP range the tenants may choose for their LAN, nor it is a public range so they won't ever need to connect to anything in that range
