What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

tymchyshyn90

Occasional Visitor
Hello!
I have OpenVPN TAP server on AC68U Merlin
And Mikrotik - client
Network bridged as i want

Asus IP - 192.168.0.1, DHCP pool - 192.168.0.3-99
Mikrotik IP - 192.168.0.101, DHCP-pool 192.168.0.102-200
Exept this, ASUS have IPv6

When I made this bridge - at first everything worked well. Devices from Asus LAN receive IP from ASUS DHCP. Devices from Mikrotik LAN received IPv4 from Mikrotik DHCP and IPv6 from ASUS. I reallly liked it)
But after few days I saw that some Mikrotik LAN devices receive IP from ASUS, and gateway too. It's problem, because OpenVPN speed is not very fast and ASUS CPU load well...

How can I restrict this?
 
I found some solution - block 67 and 68 ports (DHCP ports) in firewall. This should work. But then devices from Mikrotik's LAN will not receive IPv6 address
 
Merlin's OpenVPN server and client doesn't support IPv6.
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
 
There should only be one DHCP server in a subnet unless they are specifically designed to work together.

Morris
 
Hello!
I have OpenVPN TAP server on AC68U Merlin
And Mikrotik - client
Network bridged as i want

Asus IP - 192.168.0.1, DHCP pool - 192.168.0.3-99
Mikrotik IP - 192.168.0.101, DHCP-pool 192.168.0.102-200
Exept this, ASUS have IPv6

When I made this bridge - at first everything worked well. Devices from Asus LAN receive IP from ASUS DHCP. Devices from Mikrotik LAN received IPv4 from Mikrotik DHCP and IPv6 from ASUS. I reallly liked it)
But after few days I saw that some Mikrotik LAN devices receive IP from ASUS, and gateway too. It's problem, because OpenVPN speed is not very fast and ASUS CPU load well...

How can I restrict this?
Did you ever find a solution to this, I am having the same issue. If so can you give a little detail of what you did to solve the issues? Thanks in advance.
 
DHCP is broadcast traffic not directed traffic so you can only have one. If you hard code IPs on one router and turn off DHCP on that router, then it will work and there will not be a migration of IP addresses to another router.
 
DHCP is broadcast traffic not directed traffic so you can only have one. If you hard code IPs on one router and turn off DHCP on that router, then it will work and there will not be a migration of IP addresses to another router.

Two DHCP servers can live on the same subnet. They must either coordinate allocations or allocate non overlapping ranges of IPs. If you place two Asus DHCP servers on the same subnet they will do the latter automatically. With different brands, you must control the ranges.
 
Two DHCP servers can live on the same subnet. They must either coordinate allocations or allocate non overlapping ranges of IPs. If you place two Asus DHCP servers on the same subnet they will do the latter automatically.
I'm not aware of any Asus routers that can detect another Asus router running DHCP on the same network and for them to automatically allocate non overlapping IP ranges.

I must be missing something. Can you give a specific example?
 
Last edited:
I'm not aware of any Asus routers that can detect another Asus router running DHCP on the same network and for them to automatically allocate non overlapping IP ranges.

I must be missing something. Can you give a specific example?
I discovered they cooperate and was pleasantly surprised. Try it
 
I discovered they cooperate and was pleasantly surprised. Try it
I don't have a way to test that unless you can explain how this cooperation works so that I can check it.

I've never heard of anyone saying this cooperation existed. In fact IIRC there have been a couple of posts in the forum from people that accidentally setup two Asus DHCP servers on their network (by plugging the wrong cable into a LAN port). This resulted in the expected conflicts in IP address allocation.
 
I discovered they cooperate and was pleasantly surprised. Try it

I've never heard of this either. For that to work, there would have to be some sort of formal protocol (of which I'm unaware), esp. if the number of participating DHCP servers could be more than two, since such cooperation isn't a trivial exercise. What is possible is to define additional DHCP servers as relays, but that's generally for use in the enterprise, for centralizing control of DHCP among many different broadcast domains.
 

4 Solutions for DHCP Failure​


There are other implementations besides Microsoft which is mentioned in the above article.

What I discovered was an accident. I was upgrading from a RT-AC86U to a RT-AX86U. I first connected to the RT-AX86U with my laptop and no other connections. I disabled the DHCP server. Assigned an IP to the LAN port so it could operate on my functioning LAN and then connected it. I then manually went page by page through the config matching them. Moved the WAN port from the old to new and everything worked. I enabled the DHCP server on the new router and assigned the IP range. I had planed to unplug power from the old yet forgot to. A few days later I got an IP out of the scope I'd set and was surprised. I did an ipconfig on the windows box and there was the answer, the IP came from the old router. I Webed in and It had configured it's scope to the IP's I had not assigned to the new router. I laughed, checked the new router and then pulled the power plug on the old one.
 

4 Solutions for DHCP Failure​


There are other implementations besides Microsoft which is mentioned in the above article.
I think we're all familiar with the methods above.

What I discovered was an accident. I was upgrading from a RT-AC86U to a RT-AX86U. I first connected to the RT-AX86U with my laptop and no other connections. I disabled the DHCP server. Assigned an IP to the LAN port so it could operate on my functioning LAN and then connected it. I then manually went page by page through the config matching them. Moved the WAN port from the old to new and everything worked. I enabled the DHCP server on the new router and assigned the IP range. I had planed to unplug power from the old yet forgot to. A few days later I got an IP out of the scope I'd set and was surprised. I did an ipconfig on the windows box and there was the answer, the IP came from the old router. I Webed in and It had configured it's scope to the IP's I had not assigned to the new router. I laughed, checked the new router and then pulled the power plug on the old one.
Sorry, I can't follow what you're saying here. According to what you wrote when you moved the WAN connection from the old router to the new there wasn't any connection between the two routers. So you seem to be implying that the DHCP settings moved by magic between two unconnected devices. I think your memory is playing tricks on you.
 
They were both connected by a set of switches and on the same LAN.
 

4 Solutions for DHCP Failure​


There are other implementations besides Microsoft which is mentioned in the above article.

What I discovered was an accident. I was upgrading from a RT-AC86U to a RT-AX86U. I first connected to the RT-AX86U with my laptop and no other connections. I disabled the DHCP server. Assigned an IP to the LAN port so it could operate on my functioning LAN and then connected it. I then manually went page by page through the config matching them. Moved the WAN port from the old to new and everything worked. I enabled the DHCP server on the new router and assigned the IP range. I had planed to unplug power from the old yet forgot to. A few days later I got an IP out of the scope I'd set and was surprised. I did an ipconfig on the windows box and there was the answer, the IP came from the old router. I Webed in and It had configured it's scope to the IP's I had not assigned to the new router. I laughed, checked the new router and then pulled the power plug on the old one.

I'm not sure what the MS DHCP documentation has to do with this. Most of it is about failover conditions, where you never have multiple DHCP servers at the same time, w/ one notable exception being where you purposely configure multiple DHCP servers w/ non-overlapping scopes. But that's NOT what we're talking about here.

As far as your description, I found it confusing. I couldn't tell if you had multiple DHCP servers active on the same ethernet segment at the same time, or if they were configured w/ the same local IP network (e.g., 192.168.1.x). Or how you knew which DHCP server did the configuration if they were the same.

Just beware, the router uses DNSMasq to support DHCP, and by default, will use a hash of the MAC address to generate the device's assigned IP. For this reason, it's highly likely any given device will receive the same IP assignment regardless which DHCP server responds. For the same reason, conflicts are not as common as you might expect. But they can happen, esp. when you have a combination of high DHCP usage and small IP range for the pool (because the chance of a collision increases dramatically). But under normal conditions, I can see where someone might erroneously come to believe the DHCP servers were cooperating to avoid conflicts.

BTW, beautiful pictures on your website!
 
Last edited:
I discovered they cooperate and was pleasantly surprised. Try it
It is not possible. If there are multiple DHCP servers, then when a client broadcasts a DHCP request the first available DHCP server will respond. There is no way within a 1 network to control DHCP requests. The DHCP broadcast is sent to every device on the network. The client's broadcast is sent out and will be responded to by the first non-busy DHCP server. So, when you add a device to a network you do not know which DHCP server will respond first.

Once the client receives a reply from the DHCP server the client will respond with directed traffic to that specific DHCP server.
 
Last edited:
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.

Coxhaus is correct about how DCHP works. Client broadcasts, first or last DHCP server (depends on OS) wins on the client and then the client unicasts to the DHCP server when it accepts the IP. At 60% of lease, the client requests renewal with a unicast to the DHCP server and will continue to unicast unless no answer in which case it multicasts. Non overlapping scopes it the traditional way to do redundant DHCP yet there are a few DHCP servers that cooperate in assignment. I have no idea what code Asus has implemented yet there are modes to DNSMasq that allow for primary/failover similar to the Microsoft implementation.

I'm going to ignore all it's not possible comments as there not real world, just opinion of experienced people. Try it and see what you experience and report the results. My experience was about a year ago and code may have been changed. Others doing this experiment could result in learning for many and I'm open hear that it did not work for them. Clearly, if the configuration change dose not happen as I observed, setting up non overlapping scopes will work just fine. If you require fixed assignment, that must be done on both DHCP servers.
 
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.

Coxhaus is correct about how DCHP works. Client broadcasts, first or last DHCP server (depends on OS) wins on the client and then the client unicasts to the DHCP server when it accepts the IP. At 60% of lease, the client requests renewal with a unicast to the DHCP server and will continue to unicast unless no answer in which case it multicasts. Non overlapping scopes it the traditional way to do redundant DHCP yet there are a few DHCP servers that cooperate in assignment. I have no idea what code Asus has implemented yet there are modes to DNSMasq that allow for primary/failover similar to the Microsoft implementation.

I'm going to ignore all it's not possible comments as there not real world, just opinion of experienced people. Try it and see what you experience and report the results. My experience was about a year ago and code may have been changed. Others doing this experiment could result in learning for many and I'm open hear that it did not work for them. Clearly, if the configuration change dose not happen as I observed, setting up non overlapping scopes will work just fine. If you require fixed assignment, that must be done on both DHCP servers.
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?
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top