Conflict of two DHCP Servers on same network over openvpn TAP bridge (AC68U + Mikrotik hex)

[Morris]

This makes no sense but I'm willing to try it.

It cannot be a dnsmasq feature as
a) dnsmasq does not have any functionality that behaves the way you describe, and
b) if there are changes visible in the router's GUI then those changes are coming from the nvram variables. dnsmasq does not have any ability to change the router's nvram variables.

Even if this behaviour is happening it makes no sense to design a system like this. If you define a scope of 3-99 on the router it's usually because you have static assignments outside that range (which the router has no knowledge of). For one of the routers to arbitrarily decide that it's going to start assigning addresses that could already be statically assigned would be madness.

How long was it before you noticed that the router had changed it's own DHCP settings? i.e. how long should I expect to wait?

3 days

The common practices for split scopes on duel DHCP servers:

Configure split scopes on DHCP servers

How to split a DHCP scope to provide load balancing between two DHCP servers and ensure high availability DHCP services for your network.

documentation.solarwinds.com

We used the 50/50 method for years till Microsoft came out with the resilient solution. Both work great

 

[ColinTaylor]

3 days

I'm not sure I'd want to wait that long (with all the extra clutter on my desk) just to confirm nothing's changed. I might set it up and run it for a day though.

The common practices for split scopes on duel DHCP servers:

Configure split scopes on DHCP servers

How to split a DHCP scope to provide load balancing between two DHCP servers and ensure high availability DHCP services for your network.

documentation.solarwinds.com

We used the 50/50 method for years till Microsoft came out with the resilient solution. Both work great

As I said previously, we're all aware of how some DHCP servers can be setup (I did it myself for my day job). But that's not what we're talking about here.

 

[eibgrad]

They were both on the same LAN and active at the same time. My configured scope was 3-99 on the new router and the old router was configured the same. When I looked at the old router it had the scope of 100-253. I was shocked to see this.

I decided to setup this config in the lab. I have two routers running the latest Merlin, 192.168.1.1 and 192.168.1.2, both configured w/ DHCP as 192.168.1.3 thru 192.168.1.99. And connected LAN to LAN over their respective switches. Let's see what happens. I certainly hope it doesn't take three days, since that alone would make it not viable (like changes to ARP, something like this needs to be done quickly). I certainly didn't seem anything in the first 10 mins or so. I rebooted both routers as well. Still no change. But we'll give it some time.

P.S. DHCP provides more than just an assigned IP. It also provides the default gateway, DNS servers, etc. Is all this information "transferred" between routers as well?

 

[coxhaus]

Non-overlapping scopes does not work because you cannot control which scope the client will be in. I can see sharing DHCP servers across multiple networks but not within 1 network. It makes no sense. Most people do not use larger than a class C address space because at some point the network slows down because of the larger user base and the large broadcast domain base. Processors are faster nowadays than back when I worked but there is still a limit you don't want to exceed do to network slowdowns. It's better to use multiple networks for large groups of users.

If you have to run multiple DHCP servers on the same network, then it needs to be setup to where it does not matter which DHCP server a client hits.

If your DHCP server is being overloaded which I can't see nowadays because of the fast processors then just extend the lease to like 7 days or 2 weeks and that will reduce the load on the server so IP addresses will still be recycled.

We ran back in my day a Microsoft DHCP server with 4000+ IP addresses with lots of scopes(networks).

I guess you know DHCP is defined and nothing ASUS does will change the way DHCP works.

 

[Morris]

Non-overlapping scopes does not work because you cannot control which scope the client will be in. I can see sharing DHCP servers across multiple networks but not within 1 network. It makes no sense. Most people do not use larger than a class C address space because at some point the network slows down because of the larger user base and the large broadcast domain base. Processors are faster nowadays than back when I worked but there is still a limit you don't want to exceed do to network slowdowns. It's better to use multiple networks for large groups of users.

If you have to run multiple DHCP servers on the same network, then it needs to be setup to where it does not matter which DHCP server a client hits.

If your DHCP server is being overloaded which I can't see nowadays because of the fast processors then just extend the lease to like 7 days or 2 weeks and that will reduce the load on the server so IP addresses will still be recycled.

We ran back in my day a Microsoft DHCP server with 4000+ IP addresses with lots of scopes(networks).

I guess you know DHCP is defined and nothing ASUS does will change the way DHCP works.

It is an industry standard practice and here are ways to set it up

Configure split scopes on DHCP servers

How to split a DHCP scope to provide load balancing between two DHCP servers and ensure high availability DHCP services for your network.

documentation.solarwinds.com

 

[coxhaus]

It is an industry standard practice and here are ways to set it up

Configure split scopes on DHCP servers

How to split a DHCP scope to provide load balancing between two DHCP servers and ensure high availability DHCP services for your network.

documentation.solarwinds.com

You don't understand DHCP. Read about it. Reducing the latency on a second DHCP server means nothing in terms of control. All it means is you have a slow backup DHCP server. You still cannot control the client DHCP's broadcast which is going to be responded to by the least busy DHCP server. Imposing a busy DHCP server just means you have a primary and secondary DHCP with out control.

There is no reason to have a second DHCP server unless your network is very large. You will never bog down 1 DHCP server. Use a good DHCP server like Microsoft on a good APC and you will be fine. We ran on 1 DHCP server for years. It was changed out a couple of times to better hardware.

What I mean by large is that a DHCP server cannot issue IP addresses fast enough. You can also have networks issues with latency which can effect this. Cisco has a portfast setting to speed up clients access through switches to the network which can help. I saw this more in switch closets with hundreds of switch ports.

 

[Morris]

You don't understand DHCP. Read about it. Reducing the latency on a second DHCP server means nothing in terms of control. All it means is you have a slow backup DHCP server. You still cannot control the client DHCP's broadcast which is going to be responded to by the least busy DHCP server. Imposing a busy DHCP server just means you have a primary and secondary DHCP with out control.

There is no reason to have a second DHCP server unless your network is very large. You will never bog down 1 DHCP server. Use a good DHCP server like Microsoft on a good APC and you will be fine. We ran on 1 DHCP server for years. It was changed out a couple of times to better hardware.

What I mean by large is that a DHCP server cannot issue IP addresses fast enough. You can also have networks issues with latency which can effect this. Cisco has a portfast setting to speed up clients access through switches to the network which can help. I saw this more in switch closets with hundreds of switch ports.

LOL,

Latency has noting to do with redundancy

Clients broadcast the initial request and once they get a reply change to unicast. This is what they do because they follow the RFC

The choice of when to use redundancy is a busyness decision and network size should not be the driving factor, safety and economic loss are the most critical.

You ran on one DHCP server as that was your busyness decision and/or you never had the pain of DHCP outage at the wrong time. I am not advocating using 2 DHCP servers for home networks. You are shoving words into peoples mouths

If a network is so overwhelmed that DHCP is not working there are much more serious issues to resolve

Cisco's port fast allows a host to begin communicating almost immediately rather than wait 30 seconds for spanning tree to converge. It is a solution to still provide some protection from a network loop rather than turn off spanning tree which was the way it was done before port fast came along. It is better than off yet loops still happen.

My statements regarding the ability to use multiple DHCP servers are to help the OP who had a reason for doing it.

 

[Morris]

I decided to setup this config in the lab. I have two routers running the latest Merlin, 192.168.1.1 and 192.168.1.2, both configured w/ DHCP as 192.168.1.3 thru 192.168.1.99. And connected LAN to LAN over their respective switches. Let's see what happens. I certainly hope it doesn't take three days, since that alone would make it not viable (like changes to ARP, something like this needs to be done quickly). I certainly didn't seem anything in the first 10 mins or so. I rebooted both routers as well. Still no change. But we'll give it some time.

P.S. DHCP provides more than just an assigned IP. It also provides the default gateway, DNS servers, etc. Is all this information "transferred" between routers as well?

I look forward to what you see. The 3 days was when I discovered hosts outside of the scope I'd set up. It is possible that the scope change on the original router already happened. If you don't see a change, see what happens if you attempt to change the scope. I expect your network will be reliable with no IP conflicts. Your experiment will show the actual behavior. One of the reasons this takes time is the lease time.

Thank you for doing this

 

[eibgrad]

I look forward to what you see. The 3 days was when I discovered hosts outside of the scope I'd set up. It is possible that the scope change on the original router already happened. If you don't see a change, see what happens if you attempt to change the scope. I expect your network will be reliable with no IP conflicts. Your experiment will show the actual behavior. One of the reasons this takes time is the lease time.

Thank you for doing this

I've been at this for a little short of 24 hrs. So far, no change. Both routers report the same DHCP scope of 192.168.1.3 thru 192.168.1.99. I've also been "stirring the pot" by having my laptop (which is connected to the router w/o an active WAN) renew or release/renew its lease from time to time. As expected, with release/renew, it varies as to which DHCP server responds first and does the assignment. But I always get the same IP assigned (192.168.1.20) since the routers are identical (RT-AC68U) and (as I said) the IP is determined by a hash of the MAC address.

I don't understand what you mean by changing the scope (presumably manually). The whole point here (as I understand it) is to have the two routers detect the conflict and have one or the other automatically change its scope to resolve the conflict. If things don't change w/o my intervention (and quickly), what's the point?

 

[Morris]

I've been at this for a little short of 24 hrs. So far, no change. Both routers report the same DHCP scope of 192.168.1.3 thru 192.168.1.99. I've also been "stirring the pot" by having my laptop (which is connected to the router w/o an active WAN) renew or release/renew its lease from time to time. As expected, with release/renew, it varies as to which DHCP server responds first and does the assignment. But I always get the same IP assigned (192.168.1.20) since the routers are identical (RT-AC68U) and (as I said) the IP is determined by a hash of the MAC address.

I don't understand what you mean by changing the scope (presumably manually). The whole point here (as I understand it) is to have the two routers detect the conflict and have one or the other automatically change its scope to resolve the conflict. If things don't change w/o my intervention (and quickly), what's the point?

You have probably proven that the scope remains the same on both routers. Not getting IP conflicts is a good thing. When the router that dose not have a WAN link responds, what router dose the client report getting? If it's the one with the working WAN, then there is some coordination going on between the DHCP servers.

 

[eibgrad]

You have probably proven that the scope remains the same on both routers. Not getting IP conflicts is a good thing. When the router that dose not have a WAN link responds, what router dose the client report getting? If it's the one with the working WAN, then there is some coordination going on between the DHCP servers.

Using Windows on the laptop, I issue the following command from time to time, and by chance it sometimes is configured by 192.168.1.1, other times by 192.168.1.2.

ipconfig /release && timeout 10 && ipconfig /renew

When the router without the active WAN (192.168.1.2) ends up configuring the client, that client ends up w/ that same router as its default gateway, and thus has no internet access. But if it happens to get configured by the other router (192.168.1.1), it works just fine, since it has a WAN connection.

From everything I've seen so far, there's no indication these routers are engaged in any kind of coordination wrt DHCP. If you get configured by the wrong DHCP server, you always end up misconfigured. As I said before, if they were actively coordinating, it would require more than just avoiding IP conflicts. You'd have to make sure all secondary DHCP servers were configured to also pass the primary router's default gateway and DNS servers. The rarity of IP conflicts is just a consequence of how IPs are assigned by default (a hash of the MAC address), esp. given the routers are identical both in make/model/firmware and DHCP scope.

 

[Morris]

Using Windows on the laptop, I issue the following command from time to time, and by chance it sometimes is configured by 192.168.1.1, other times by 192.168.1.2.

ipconfig /release && timeout 10 && ipconfig /renew

When the router without the active WAN (192.168.1.2) ends up configuring the client, that client ends up w/ that same router as its default gateway, and thus has no internet access. But if it happens to get configured by the other router (192.168.1.1), it works just fine, since it has a WAN connection.

From everything I've seen so far, there's no indication these routers are engaged in any kind of coordination wrt DHCP. If you get configured by the wrong DHCP server, you always end up misconfigured. As I said before, if they were actively coordinating, it would require more than just avoiding IP conflicts. You'd have to make sure all secondary DHCP servers were configured to also pass the primary router's default gateway and DNS servers. The rarity of IP conflicts is just a consequence of how IPs are assigned by default (a hash of the MAC address), esp. given the routers are identical both in make/model/firmware and DHCP scope.

It appears what I recall is not happening. There are lots of ways to configure the network to function and your suggestion is one of them yet that's now what the goal of the experiment. Thank you for doing this.

Morris

 

[coxhaus]

There is No control over DHCP within 1 IP network.

 

[coxhaus]

LOL,

Latency has noting to do with redundancy

Clients broadcast the initial request and once they get a reply change to unicast. This is what they do because they follow the RFC

The choice of when to use redundancy is a busyness decision and network size should not be the driving factor, safety and economic loss are the most critical.

You ran on one DHCP server as that was your busyness decision and/or you never had the pain of DHCP outage at the wrong time. I am not advocating using 2 DHCP servers for home networks. You are shoving words into peoples mouths

If a network is so overwhelmed that DHCP is not working there are much more serious issues to resolve

Cisco's port fast allows a host to begin communicating almost immediately rather than wait 30 seconds for spanning tree to converge. It is a solution to still provide some protection from a network loop rather than turn off spanning tree which was the way it was done before port fast came along. It is better than off yet loops still happen.

My statements regarding the ability to use multiple DHCP servers are to help the OP who had a reason for doing it.

Latency has everything to do with what you posted on configuring split scopes.

If the OP wants to run 2 routers then he needs to turn off DHCP on 1 of them and hard code the IP addresses for the router without DHCP. I have posted this for years on this forum.

 

[Morris]

Mikrotik connect to openvpn server over IPv4. But this is not TUN, it's TAP bridge. All devices are on same network 192.168.0.0/24. ASUS receive all Mikrotik's LAN devices MAC and give them IPv6 address

Your best bet is to use fixed IP or manual IP for the devices on the Mikrotik side and include the IP of the Mikrotik's router in the manual assignment or fixed IP DHCP response. Dynamic IP assignment will be problematic.

 

[ColinTaylor]

Your best bet is to use fixed IP or manual IP for the devices on the Mikrotik side and include the IP of the Mikrotik's router in the manual assignment or fixed IP DHCP response. Dynamic IP assignment will be problematic.

The OP hasn't been seen for nearly a year now. I doubt he's reading any of these replies.

 

[Morris]

The OP hasn't been seen for nearly a year now. I doubt he's reading any of these replies.

Ah, @richardwojcik woke the thread stating he is having the same issue. My reply may help him.

 

[ColinTaylor]

Ah, @richardwojcik woke the thread stating he is having the same issue. My reply may help him.

I doubt it. He also hasn't responded to this thread and if you look at his other thread it seems clear that his problem actually has nothing to do with this thread.

 

[Morris]

I doubt it. He also hasn't responded to this thread and if you look at his other thread it seems clear that his problem actually has nothing to do with this thread.