MikroTik

I'll probably need to email support for this, but I thought I'd check on here first, I did a search and didn't find mention of this, also I can't find any info on the wiki (besides the general description).

I've got a RB 493AH, with 5.1 (just updated to 5.5, still doing it), and have finally set it up to do DHCP for my network (mainly as an emergency replacement while I deal with a down Windows Server), I've inputted all the settings for DHCP server, interface, IP pool, static leases, etc.

Then I noticed the first client pick up an ip, but it wasn't what I expected.

IP Pool
192.168.0.1-192.168.0.253

I expected it to get 192.168.0.1 as it's the first ip in the pool, nothing else on the network is using it, no, it got 192.168.0.253 instead. I shortened the lease time and changed the range to end 252, it got .252. I changed it to 192.168.0.11-192.168.0.19, it picked up .19

I've looked for a reverse order option somewhere, I even entered the pool in reverse, eg. 192.168.0.19-192.168.0.11 (which I thought it would complain about, but no, it accepted it), but it didn't make any difference.

Granted, this is purely an admin preference thing, and maybe my OCD, but I don't like it, I want it to start at a lower number and go up, is there a way to do this I'm missing?

PS. Not to be confused with this post: http://forum.mikrotik.com/viewtopic.php?f=2&t=36044
Where it was reversing the IP e.g. 254.20.10.10 instead of 10.10.20.254.

PPS. Ah, I have found a post, not much help, and looks like this has been the behaviour for quite a few years: http://forum.mikrotik.com/viewtopic.php?f=1&t=7747

Edit: I've added a Poll, but I'd like to point out only out of curiosity, since results can be skewed by all manner of things, politics, popularity, plus we all know there are people with nothing better to do than post negative comments on internet forums (we've all come across them). I don't accept the Poll results as proof one way or another, still it might show what interest there is in this topic, since if people didn't care they'd probably just ignore it without a poll, far quicker/easier to select a poll option than write an actual post (60+ views and only 8 replies at time of this post), unfortunately that can be both good and bad as I've just stated. Also, don't know if support/devs themselves are voting, they'll most likely vote no as not wanting any other additional work.

I have the same problem, any help ?

You can't change it.

I don't think there's no solution for this, where are Mikrotik's Experts?

This /might/ work: However, that's retarded. Who gives a damn in what direction it assigns IP addresses?

This /might/ work:

Code: Select all

/ip pool
add name=dhcp3 ranges=192.168.1.4
add name=dhcp2 ranges=192.168.1.3 next-pool=dhcp3
add name=dhcp1 ranges=192.168.1.2 next-pool=dhcp2
/ip dhcp-server
add interface=LAN address-pool=dhcp1

However, that's retarded. Who gives a damn in what direction it assigns IP addresses?

Probably, but as you said, a very poor workaround, the number of pools you need could be huge.

Given that the default for the RB is to wait 2 seconds, then answer if a client still needs an IP, indicates it's aware of other DHCP servers that could be around and is designed that it can operate as a "backup" dhcp server. If so, then just simple consistency would require it serves out the IPs in the same order as other DHCP servers would.

What if the RB matched firewall rules in reverse order? Starting from the bottom and going up? It would still work wouldn't it? I bet you'd rather it processed them from the top down, like every other firewall in the world does.

I dont see any reason for us cracking our brain over this!

This has been what it is since I started using mikrotik over 7years ago!
I am sure, at a time mikrotik might decide to reverse it or make it optional. but for all I care, let it work.

Use static for those clients you want to monitor or identified, if you dont like what they get from the machine.

This /might/ work:

Code: Select all

/ip pool
add name=dhcp3 ranges=192.168.1.4
add name=dhcp2 ranges=192.168.1.3 next-pool=dhcp3
add name=dhcp1 ranges=192.168.1.2 next-pool=dhcp2
/ip dhcp-server
add interface=LAN address-pool=dhcp1

However, that's retarded. Who gives a damn in what direction it assigns IP addresses?

Actually its not retarded, its something retard with Mikrotik RouterOS ?

Wow, the hostility at wanting a feature to behave more industry standard, yikes.

Yes, it's been this way for a long time, but it appears there was also a time it also reversed the actual IP it gave out too, which obviously was a bit of a problem.

I don't really think correcting the order it assigns IPs (or giving the option of which direction to go in for those who now actually used to it this way and want or need it to be different to other DHCP servers) can be considered "cracking our brain", it's hardly IPv6 in it's complexity as a fix or option to add.

If you are sure that at some point Mikrotik will correct it or give the option, what's wrong with asking for that now? I also heavily doubt that such a change will break anything, granted every modification has the change to cause unexpected behaviour, but as fixes/changes go I don't think you can get anymore basic unless it's purely a cosmetic change you're applying.

Edit: I've added a Poll, see edited first post.

Wow, the hostility at wanting a feature to behave more industry standard, yikes.

I can't find any requirement about IP allocation direction in current http://www.rfc-editor.org/rfc/rfc2131.txt RFC2131-Dynamic Host Configuration Protocol, so i guess MT is standard/industry compliant.

If you are sure that at some point Mikrotik will correct it or give the option, what's wrong with asking for that now? I also heavily doubt that such a change will break anything, granted every modification has the change to cause unexpected behaviour, but as fixes/changes go I don't think you can get anymore basic unless it's purely a cosmetic change you're applying.

This is definately cosmetic change. If there is anything to request, then i would like to see random IP change assigned to client, like many ISPs use to differentiate 'broadband' connections from 'leased line ' type.

Edit: I've added a Poll, see edited first post.

What if I want to start from middle? Obviously I didn't voted - option "direction doesn't matter" is missing.

I don't really see why this is useful? Do you have any reason this is important?

Wow, the hostility at wanting a feature to behave more industry standard, yikes.

I can't find any requirement about IP allocation direction in current http://www.rfc-editor.org/rfc/rfc2131.txt RFC2131-Dynamic Host Configuration Protocol, so i guess MT is standard/industry compliant.

Industry standard, as in the same behaviour as other DHCP servers, I didn't say RFC complient, otherwise I would have given a reference. Can you name any other DHCP servers that offer the last IP in a pool first?

If you are sure that at some point Mikrotik will correct it or give the option, what's wrong with asking for that now? I also heavily doubt that such a change will break anything, granted every modification has the change to cause unexpected behaviour, but as fixes/changes go I don't think you can get anymore basic unless it's purely a cosmetic change you're applying.

This is definately cosmetic change. If there is anything to request, then i would like to see random IP change assigned to client, like many ISPs use to differentiate 'broadband' connections from 'leased line ' type.

You've missed the point here entirely, I'm saying it's highly unlikely to break anything given the kind of change it is, the only thing less likely to break anything is a cosmetic change, such as correcting a spelling mistake on a label in the webconfig screen for example.
Interesting suggestion about a "Random IP assignment", sure, why not give Mikrotik users that option, again I can't see this being a mammoth task.

Edit: I've added a Poll, see edited first post.

What if I want to start from middle? Obviously I didn't voted - option "direction doesn't matter" is missing.

Middle is a little odd isn't it? Which direction should it go in? If it starts from the middle and goes up, what about from start to middle addresses, use them afterwards? In what direction? No offense, but I think you're taking the mickey with that suggestion. It's exactly these comments and views I was afraid of.

"Obviously I didn't voted - option "direction doesn't matter" is missing", well you have to decide, you can either vote "Ok sure, it seems a quick fix/option to add, why not." or "No, their attention should be focussed on fixing/adding popular items only." depending on how you feel about it.


normis, in every other DHCP server I've seen or used, it's always issued IP from the start of the pool not the end, granted it may seem more like a niggle or an OCD thing, I'll see if I can think of a more specific reason, but I had hoped since it's a relatively small thing you might humour me and others like me. petrn, despite some of his post, did have a good suggestion that others might want to do a random IP selection from the pool as well.

Oh, I had an idea, but not sure how I can explain it, but it comes down to compatibility with some other systems, like monitoring systems, they're noting IPs on the network and reporting back on increases, it's expecting to see IPs increase as they're handed out and warn when it's getting low. For it to function with a DHCP leasing IPs in reverse it'll need to be rewritten to understand IPs while the usage is increasing the IP number being given out is decreasing.

True, that program could probably do with rewritting itself, but when every other DHCP server gives out IPs from the start of the pool and up, you can see how they might use simplistic code, not expecting to come across this scenario.

I'm hoping it can be squeezed in on 5.6 or whatever the next one is on the changelog, since it's not a massively complicated feature like a lot of others are.

You've missed the point here entirely, I'm saying it's highly unlikely to break anything given the kind of change it is, the only thing less likely to break anything is a cosmetic change, such as correcting a spelling mistake on a label in the webconfig screen for example.

Correcting spelling mistake is not going to increase size and compexity of ROS, unlike adding new option to DHCP (not only OS image will grow, CPU utilization (even if it's just few cycles, still there is definately impact), then you have to update winbox, webfig, manual/wiki, then finaly dozens of post in this forum to be answered daily ...

Interesting suggestion about a "Random IP assignment", sure, why not give Mikrotik users that option, again I can't see this being a mammoth task.

Actually i didn't ask for "Random IP assignment", but for forced IP change after certain ammount of time, by refusing to renew lease of current IP for that client

Middle is a little odd isn't it? Which direction should it go in? If it starts from the middle and goes up, what about from start to middle addresses, use them afterwards? In what direction? No offense, but I think you're taking the mickey with that suggestion. It's exactly these comments and views I was afraid of.

Well, I tried to lighten up, i'll try to avoid next time ...

"Obviously I didn't voted - option "direction doesn't matter" is missing", well you have to decide, you can either vote "Ok sure, it seems a quick fix/option to add, why not." or "No, their attention should be focussed on fixing/adding popular items only." depending on how you feel about it.

Replace popular with important, then i can vote for it.

Oh, I had an idea, but not sure how I can explain it, but it comes down to compatibility with some other systems, like monitoring systems, they're noting IPs on the network and reporting back on increases, it's expecting to see IPs increase as they're handed out and warn when it's getting low. For it to function with a DHCP leasing IPs in reverse it'll need to be rewritten to understand IPs while the usage is increasing the IP number being given out is decreasing.

Put it in feature request wiki, and let see how many users are bothered by that.

AJStevens,
BTW unrelated to this issue: i just installed/configured dhcpd in RHEL v5.6, dhcp is http://isc.org/products/DHCP/ version 3.0.5, so pretty huge install base. And guess what: first allocated IP was from END. I never paid attention to this, as again - it doesn't matter. And i suggest to read RFC - client my request IP and if DHCP server has no problem with that, it will get assigned. And clients do that, based on previous assignments . So linearity of allocation from begining would not work.

I don't really see why this is useful? Do you have any reason this is important?

You know it's something psychological, Why its not begin from lower IP to higher IP range, It's like a page numbering, I think everybody feeling that way.

You've missed the point here entirely, I'm saying it's highly unlikely to break anything given the kind of change it is, the only thing less likely to break anything is a cosmetic change, such as correcting a spelling mistake on a label in the webconfig screen for example.

Correcting spelling mistake is not going to increase size and compexity of ROS, unlike adding new option to DHCP (not only OS image will grow, CPU utilization (even if it's just few cycles, still there is definately impact), then you have to update winbox, webfig, manual/wiki, then finaly dozens of post in this forum to be answered daily ...

Well, when it was originally just "switch it around", then it wouldn't have incurred any of those increases. If you look at the links I provided in the first post, this wasn't the only "reversed" issue with DHCP, which is why I think it's this way.

Obviously, with these other modifications we're coming up with, it will require a bit more, still as adding features goes, it's pretty lightweight compared to others.

Interesting suggestion about a "Random IP assignment", sure, why not give Mikrotik users that option, again I can't see this being a mammoth task.

Actually i didn't ask for "Random IP assignment", but for forced IP change after certain ammount of time, by refusing to renew lease of current IP for that client

Presumably if you wanted a forced IP change, you'd also want to try to pick a random ip, rather than a consecutive one, but I understand the purpose, though I have no use for it right now, I can see many others would and would be a good feature.

Middle is a little odd isn't it? Which direction should it go in? If it starts from the middle and goes up, what about from start to middle addresses, use them afterwards? In what direction? No offense, but I think you're taking the mickey with that suggestion. It's exactly these comments and views I was afraid of.

Well, I tried to lighten up, i'll try to avoid next time ...

There's lighten up, and there's belittling..

"Obviously I didn't voted - option "direction doesn't matter" is missing", well you have to decide, you can either vote "Ok sure, it seems a quick fix/option to add, why not." or "No, their attention should be focussed on fixing/adding popular items only." depending on how you feel about it.

Replace popular with important, then i can vote for it.

That's subjective, so no. Also, "popular" was the word used by Mikrotik support.

Oh, I had an idea, but not sure how I can explain it, but it comes down to compatibility with some other systems, like monitoring systems, they're noting IPs on the network and reporting back on increases, it's expecting to see IPs increase as they're handed out and warn when it's getting low. For it to function with a DHCP leasing IPs in reverse it'll need to be rewritten to understand IPs while the usage is increasing the IP number being given out is decreasing.

Put it in feature request wiki, and let see how many users are bothered by that.

? Will check the wiki for this.

AJStevens,
BTW unrelated to this issue: i just installed/configured dhcpd in RHEL v5.6, dhcp is http://isc.org/products/DHCP/ version 3.0.5, so pretty huge install base. And guess what: first allocated IP was from END. I never paid attention to this, as again - it doesn't matter. And i suggest to read RFC - client my request IP and if DHCP server has no problem with that, it will get assigned. And clients do that, based on previous assignments . So linearity of allocation from begining would not work.

Interesting, so someone else does DHCP Pool leasing from the END, but is it intentional?
*sigh*, obviously with re-requesting IPs or even static assignments those will override, I'm talking about after that it should assign from begining of IP Pool to end, so that generally speaking the lower end of the pool is used than the higher end.

I remind you to read my original post again which was simply, when the ROS DHCP server decides to pick an IP from the IP Pool, it does so from the begining, not the end. Everything else to remain unchanged.
Of course, over the length of this thread, we've come up with a few other good feature requests for the DHCP Server which should or may need to be implemented at the same time to attempt to please as many as possible.

Sorry, but i will be direct.

When you are with MikroTik, you do as MikroTik users do it. If you don't like it, nobody is holding you here.
Currently this topic is waste of time.

FYI: trolls are not staying long in this forum, and this is typical case of trolling

June 26, 2010, I wrote to support@:

Let's make IP Pool distribution more even =)

For now, IP Pool begins address assignment from the last (highest) address
of the pool down to the first (lowest) address (see attached graph). But on
reaching that address, it assigns lowest free addresses (rounded in red on
the picture).

That makes pointless using large pools for decreasing address density -
after using all addresses, address is reused again as soon as possible.


It would be wise to begin assignment of addresses from the highest address
again after reaching lowest address...

The answer was:

Can't promise anything, but there might be IP Pool algorithm upgrade in one of
the upcoming betas.

Regards,
Janis Megis

can anybody check current (v5) implementation against such behaviour?..

June 26, 2010, I wrote to support@:

Let's make IP Pool distribution more even =)

For now, IP Pool begins address assignment from the last (highest) address
of the pool down to the first (lowest) address (see attached graph). But on
reaching that address, it assigns lowest free addresses (rounded in red on
the picture).

That makes pointless using large pools for decreasing address density -
after using all addresses, address is reused again as soon as possible.


It would be wise to begin assignment of addresses from the highest address
again after reaching lowest address...

graph.gif

The answer was:

Can't promise anything, but there might be IP Pool algorithm upgrade in one of
the upcoming betas.

Regards,
Janis Megis

can anybody check current (v5) implementation against such behaviour?..

Yes I am currently using v5.5 and the reversing is still there !

Yes I am currently using v5.5 and the reversing is still there !

Chupaka ask about behavior after reaching lowest IP from pool. Not about first allocation.

Same reverse IP assignment in IOS 6.1

Although it is not possible right?

I might have a solution which worked for me. Change your IP pool to 1 IP only for example 192.168.88.2
Reboot your router, your pc should now receive that IP. Login again and change the IP pool back to the range that you had for example 192.168.88.2-192.168.88.250. Reboot router again, now connect multiple devices and check if the IP's lease from the beginning of the pool. Please let me know if this works for you.

I feel a fear of the local network being hacked there. I have been linked on this topic via google because same feeling here. Hacked local network device can cause similar behavior / sniffing etc. It would be nice if we know the pool numbering is always from low to high or vice versa. In my case I'm using VLANs on same device and each network is different / one is from low to high , another is reversed from high to low. Could this be some local network security issue? I should log the DHCP server and analyze it perhaps if no reasonable answer found.