DHCP active<->active setup. RRS feed

  • Question

  • Hi,

    I would like to know if this scenario will work. It's quite a long text, and just fire off questions if there is anything unclear, I have tried my best to explain. Maybe the answer is simple (Text is below the picture)

    I have 2X2016 servers on the same network serving PC's on other networks, including the wifi network below.
    They are both in an active<->active setup.

    Now, there is a WLC serving a wifi network that utilizes the two DHCP servers. It is configured using a global relay towards the servers. One of the relays is the primary, the other secondary. When the WLC receives a request on it's wifi network it will first send the request to the primary relay, wait 5 sec. on an answer from the DHCP and then send it to the secondary relay. So the request will never hit the two server simultainuasly

    Both servers shares scopes 50% 50%. 50% of the scope can not hold all clients, so I have to utilize 100% shared between the two servers.

    So what will happen on the client and server side.

    The client calculates its hash value to a value between 1-128 or 129-256. Depending on the which groups of value it the client end up in it will either be served by one or the other server.

    a bit og theory can be found here:

    So lets say the WLC receives a request meant for the server that handles DHCP leases on the secondary relay (Lets call it the secondary DHCP server, and the primary relay points to the primary DHCP server, just to make the next text a bit easier to grasp.)

    At first the request will be sent to the primary server, but what happens next? I presume one of these things.

    1. The primary server sees that the secondary is alive, and hence does not provide a lease. After 5 sec. the secondary receives the request, the hash value is okay, and it will provide a lease?

    2. Does the primary server "know" that the secondary does not receive the request at the same time, and therefore provide a lease, even though it can see that the secondary is alive?

    3. Will the primary forward the request to the secondary that will in turn provide a lease, and either send it directly to the client or answer the primary which will then send the lease to the client?

    4. Does the client receive an IP at all?

    5. Will the client get impatient and fire one more request to the WLC.?

    6. Something else happens?

    7. Will I end up in a confusing mess of different scenarios?

    The reason for this setup is actually to have the possibility to failover.  know that this is a strange setup, but there are some tings on the network and network equipment that can not be changed. We have a very complex setup, layers of firewalls, and the conditions concerning the relays can not be helped. Alle possibilities has been exhausted by our network specialists. So even though you may have good suggestions on that front, it can not be done, I have to look at it from a Microsoft perspective.

    The reason that we want this setup is to be able to make a failover. Since I have to utilize the hole scope I can not do the old standard 80/20 solution or even 50/50. I am not able to change the size of the scope either, it is a no-go.

    So lets set network trouble shooting aside, we only have these rules.
    1. The WLC routes request to the primary server first. If there is no answer it will route to the secondary server after 5 sec.
    2. We have to, at all times utilize 100% of the DHCP scope.
    3. The 2 DHCP servers is placed on the same network, but the clients are placed on other networks.
        It will not be possible to place a DHCP server on another network, they will be at the same network.
    4. One of the DHCP servers can be down

    I hope that someone can help me out.

    Best Regards


    Thursday, June 14, 2018 12:24 PM

All replies

  • Hi,

    Based on the complexity and the specific situation, we need do more researches. If we have any updates or any thoughts about this issue, we will keep you posted as soon as possible. Your kind understanding is appreciated. If you have further information during this period, you could post it on the forum, which help us understand and analyze this issue comprehensively.
    Sorry for the inconvenience and thank you for your understanding and patience.

    Best regards,


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Friday, June 15, 2018 10:05 AM
  • Hi,

    Thanks for your question.

    In my opinion:

    1. If the hash of the MAC address falls between 1 and 128 then the first server will respond to the client request else if the hash is any value between 129 and 256, the other server responds to the client. In your case, the secondary server will provide services only if the hash value meets the criteria.
    2. If the client does not get a reply, it will resend the request.
    3. Even while in Normal state, the server responds to the client if the client has been retransmitting the same request for a while. The server determines that a client has been retransmitting based on the secs field in DHCP client request. If secs field in client request is greater than 6 seconds, DHCP server will respond to the client even if the hash of the client MAC address does not fall within the hash buckets of the server.
    4. The servers will forward the request to the clients directly. But both DHCP servers in a failover relationship must maintain a persistent TCP connection with each other. DHCP failover partners establish and maintain this connection on port 647 and use it to exchange operational state information and lease information.
    5. Based on your complex environment, there may be unpredictable problems.

    Refer to the following link:

    Hope you have a nice day!

    Best regards,


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Monday, June 18, 2018 10:22 AM
  • Thanks Travis.

    That was what I feared.
    I'll run your info by my team.

    Best Regards

    Monday, June 18, 2018 7:43 PM