Mikrotik assigns by default from the top of the range, which is for many a bit unpleasent there even was a pool where most participants wanted the ability to change that: DHCP IP Pool Lease - In reverse??
Its a very small change it has no real potential to break anything hence please just add it to the next RouterOS that would make a lot of your users happy 
2 Likes
I categorise this under âIf it ainât broke, donât fix it. The ordering is slightly perverse, but it has a tiny advantage in setting up a new router on a system in that starting from the top, it is more likely to avoid any fixed assignments. And if you are not laid back enough to let DHCP assign as it will, you can always fix IP addresses within DHCP.
Well but for some people that is broken, also I am not asking about changing it for all just keep the default as is but please add an option to revert the order.
For example when I want to create a pool for VPN clients and then address them by hand after looking up the IP if it starts at .254 I have to type more and remember longer numbers then when it would start at .2, so the ascending order has a concrete benefit in certain scenarios. Short numbers are easier to remember (that also applies to the short therm memory) hence its more user friendly. To put it bluntly starting at the lower end is more inclusive than starting at the top.
1 Like
Sounds like a personal problem, I actually prefer starting at the higher numbers and working down.
Maybe if you put in your pool backwards, it would solve the issue.
Ip pool= 192.168.0.254-192.168.0.2 
Nope reversing in the UI does not change the behavioure.
Good for you that you prffer it thias way, and your prferenc want be negatively impacted by there being an option to switch it.
What I am saying is that the assignment of IPs should follow how the pool is laid out.
Agree it's always done in "reverse". But I don't think it's bad idea here to start low and go up. So +1 from me here. But I recommend filing it formally as a "Feature Request" on https://mikrotik.com/support
FWIW, there is an ugly workaround to express the multiple pool members as /32 individual IPs in the addresses= array. A simple :for loop could do it a config script to create the pool in config file. Since a pool to follow the order of the array list provided in the /ip/pool, you get the desired order. Now at expense that a pool configuration could fill an export if you have more than a LAN
Yup. IMO if you express an /ip/pool as 192.168.88.11-192.168.88.254 (low-to-high) then it should start with .11. And if you use 192.168.88.254-192.168.88.11 (high-to-low) it do the reverse.
While I suppose some assignment-order on the pool could work too, but I'm not sure about more attributes.
Now a new attribute to control DHCP pool assignment order would avoid breaking defconf that use the 192.168.88.11-192.168.88.254 if DHCP server followed the order specified.
Plot twist, when static lease on low number is created assignment will start from it up to higher number. Could be used as workaround.
Please somebody kindly enlighten me: why does IP address assignment order (either one) matter at all? Received IP address will be (pseudo) random anyway unless one sets a fixed leases for particular devices ... in which case address assignment order doesn't matter at all.
You would simply adjust your dhcp pool to not overlap with static assignments.
@mkx I have already explained that, when you add a new device that gets a random IP, possibly a temporary one you donât want to give a static address to, each time you want to address it you need to type out the IP and remember it correctly.
10.10.1.15 is faster to type and easier to remember then 10.10.1.235
Software should be inclusive and for example not discriminate against people with poor short therm memory
Indeed, it is common knowledge that you keep your DHCP pool clear of static assignments. What I am hinting at is but a small guard against mis-configration in the setting up stage of a network.
Thanks for explanation.
Though it doesn't hold water to me ... because theoretically every time one wants to address such device, one has to find the right address. And only then the "one digit less" becomes a thing. Until IP address changes for some reason.
Another thing to remember: when DHCP server has a long uptime, the pool will get "fragmented": some clients will be alive and will hold on to the addresses, some clients will be temporary and leases will expire eventually, becoming available to other clinets. And when this fragmentation happens, leased IP addresses will become (pseudo) random because DHCP server will have to fill in the voids between active addresses.
In general I have problems to understand a few "rules" revolving around DHCP. One of them being the rule to move "static leases" away from DHCP address pool. Unless there are multiple (un-coordinated) DHCP servers serving same L2 network moving static leases doesn't make any (technical) sense. Those addresses are reserved and DHCP server won't hand them out to some random client. Regardless of "pool membership". The only reason to do that is IMO to (more easily) assess the size of pool available to random DHCP clients (if static leases are within pool, then one has to count static leases and subtract that from total number of addresses in pool).
Personally I really don't care about the order in which DHCP address are leased, as a matter of fact I find it easier to remember when checking connected devices (in very small networks[1]) that they are leased from top to bottom because - when looking at connected devices (that are usually scanned in ascending order) - the first few devices found will be the statically assigned ones bottom to top, please read as desktops, NAS, printers, routers, switches, etc. (i.e. "the important ones") so if checking for those I can stop the network scan earlier, then there is a large "hole" and then come the DHCP ones (largely if not all wi-fi clients). Then - loosely - the first ones of these devices that come out in the scan will be the last ones to have joined the network.
BUT, this said, I wonder how much it would cost (in time of a Mikrotik programmer) adding an option like:
/ip dhcp server
add interface=bridge reverse-lease-order=no|yes (default=no)*
Or - as anav indirectly suggested - use the order in which the pool is given:
/ip pool
add name=dhcp_bridge ranges=192.168.88.10-192.168.88.254
vs.:
/ip pool
add name=dhcp_bridge ranges=192.168.88.254-192.168.88.10
IF that costs nothing or nearly nothing, why not adding it?
It would make a few people happy.
[1] which I maintain and that - yes, I am old school, besides old - are mainly cabled and using static IP's
on https://mikrotik.com/support i donât see a dedicated feature request option am I supposed to file a feature request as a support case? The way its worded there its for resolving issues, or does a missing feature count as an issue?
The interesting and important thing about this âsuggest a new featureâ option in the support system is that some of the features I requested this way have actually been implemented â while long discussions in the forum usually led nowhere.
1 Like
I have added 2 feature requests this one and an other one lets see if it works, it would be really awesome if it would
Maybe you should try the GUI solutions for managing your router? Then you wonât have to remember and type an IP but you can just click on the correct entry, select âmake staticâ, and then modify the IP that is already printed.
Also, when you are obsessive about having 2-digit IP addresses you can also change your pool to end at address 99, and when you fear that your pool may become exhausted you can add a ânext poolâ that starts at 100.
I like this suggestion. Except itâs changing the current default⌠is it only Mikrotik that does it this way? I must agree it caused mild surprise here.