ROS version 6.44.5, model RB3011 I have network 10.0.0.0/16, I have 35 devices connected to network. For some reason DHCP server assigns randomly IP addresses, for example 10.0.50 than starts assigning 10.0.0.63, 10.0.0.64, 10.0.0.66, jumps to 10.0.0.101. Does it keeps some addressees which were used before and how to remove them?
Why is that a problem?
If you want to keep them the same once assigned simply go into leases and make them static. Otherwise, the router is working just fine.
Remember RouterOS was not designed by an OCD programmer.
As shown in figure. I cannot figure our why DHCP creates this holes in IP address space. Yesterday I have updated RuterOS from 6.44.1 to 6.44.6 , at least started adding IP address 10.0.0.0-10.0.0.254 range. I only have 3 statically defined addresses 10.0.0.2, 10.0.0.3, 10.0.0.4 those are switches and Default GW 10.0.0.1
Let’s say router leased .30 to some device, then .31, then .32
When .30 lease expired, it can be leased again, but router won’t try to fill that gap. It will continue to lease .33 etc. if .32 is still active.
That is what you are talking about?
So once again, why does it bother you?
Well, there is no option that I know of in RouterOS to assign consecutive IP addresses.
For example, in dnsmasq we have this:
–dhcp-sequential-ip
Dnsmasq is designed to choose IP addresses for DHCP clients using a hash of the client’s MAC address. This normally allows a client’s address to remain stable long-term, even if the client sometimes allows its DHCP lease to expire. In this default mode IP addresses are distributed pseudo-randomly over the entire available address range. There are sometimes circumstances (typically server deployment) where it is more convenient to have IP addresses allocated sequentially, starting from the lowest available address, and setting this flag enables this mode. Note that in the sequential mode, clients which allow a lease to expire are much more likely to move IP address; for this reason it should not be generally used.
As stated even in the Dnsmasq documentation this could lead to problems in certain scenarios.
BUT, you could hack your way around this, if you really want to, using the next-pool feature and pools containing only one IP address (only way I could think of)
First, you create the last pool in the list which doesn’t have a next-pool and prevents our next line from spitting an error.
/ip pool add name=ocd-pool-254 ranges=10.0.0.254
And next we create the rest of them.
:for p from=253 to=10 do={ :ip pool add name=("ocd-pool-" . $p) ranges=("10.0.0." . $p) next-pool=("ocd-pool-" . ($p+1)) }
And of course you set your dhcp server to use the first pool, ocd-pool-10.
But, why? 
I think this is not issue!
There is not any issue, but I have a question: Why you need an /16 subnet for 35 devices?
I wanted to set first /24 but my manager wanted /16 
Thanks for answer. First I was worried that IP pool is going to deplete since it was already started assigning at 10.0.3.* I know there are 2^16-2 available addresses but… Also I was worried if there were some loops on network with one device requesting/receiving multiple IP addresses from DHCP
I had problem with QNAP storage didnt want to talk with 10.0.3 .* /16 addresses for some reason, it has 10.0.0.11/16 address . Other devices were working.
I dont have access to QNAP storage to inspect further. For now i have set on Mikrotik -->Store Leases on Disk never| hoping that will try to assign unused addresses after reboot. So far it is good
Interesting
No.. that won’t do it. I also set “never” to store leases on disk, to minimize flash wear and because except the IPs I’ve set static, I don’t care if the rest of them change IP addresses.
And even so, given the same poolsize/range, even after factory reset, devices tend to get the same IP address from that pool (behaviour similar to dnsmasqs default pseudo-randomly based on MAC hash), I have a mobile phone that always gets .198 from a pool range of .100 - .199.
You could use what I wrote above for the first /24 and after that use another big pool(s) because it’s one thing to have 200 pools and another to have 65k for the server to go through.
Here’s your technical reason not to use /16 … so either investigate the QNAP problem or persuade your manager that /16 is a no-go.
That’s because when client device sends its first DHCP DISCOVERY message, it may include preferred IP address. And if DHCP server doesn’t see anything wrong with it (e.g. it’s not within right L3 subnet or it’s already in use by some other device), it can send DHCP OFFER with requested IP address. Which most DHCP servers do. If client doesn’t include preferred IP address or it’s not acceptable to DHCP server, then DHCP server will choose one that suits (either it’s a static lease or random address from pool).
So it’s only the matter of clients remembering used addresses for all wireless networks they connected to …