I have a DHCP server serving a number of subnets over a DHCP relay. When it sends out DHCP offers it sets the server identifier (option 54) to its own IP address.

When the clients need to renew they try to unicast to that IP address, which none of them can route to.

How is unicast to the DHCP server supposed to work when a relay is used? Is the expected behavior for the client to fail to renew by unicast during RENEWING state and then to renew by broadcast during the REBINDING state after time T2?


Yes, absolutely.

It's a little odd for the clients to be unable to route unicast to their DHCP server, but it's not at all a problem; they'll just renew later on in their lease lifetime (which gives you a little less leeway for downtime on the DHCP server).


Lease renewal (in the T1 stage) is facilitated via a unicast message from the DHCP client to the DHCP server. Why would unicast traffic from the client subnet not be routed to the server subnet? How would the original broadcast be relayed to the server subnet if the DHCPDiscover message from the client subnet is not being routed (relayed) to the server subnet? If no traffic is being routed between the subnets then how would the client obtain an ip address in the first place?

At the end of the day, the traffic from the DHCP client subnet is routed via the router (by way of a unicast message from the DHCP relay agent during the original DHCPDiscover stage and later during the T2 stage) and/or via unicast directly from the DHCP client during the T1 renewal stage.

As you stated, if the client reaches the T2 stage then it submits a broadcast renewal request, which the DHCP relay agent should relay (unicast) to the DHCP server.


Is this a theoretical question or are you actually having this problem?


To put another spin on my answer: When the client initiates a lease renewal in the T1 stage the renewal request is a unicast message directly from the client to the server (unicast is direct one-to-one communication), so the DHCP relay agent should not be involved at all. If the client reaches the T2 renewal stage then the renewal request is sent via a broadcast message and should be relayed by the DHCP relay agent (which is actually a unicast message from the DHCP relay agent).

If the T1 stage unicast message is not being routed from the client subnet to the server subnet then this is a routing/network issue, not a DHCP issue.

  • Broadcast traffic on the client subnet gets picked up by the relay and sent to the DHCP server on the other subnet, but the client network cannot route to the DHCP server's IP address (from the server identifier option in the offer). It's actually happening. DHCP works but I noticed a lot of retransmissions of unicast so I started looking into it.
    – mmb
    Sep 8 '11 at 2:58
  • How is option 54 relevant to the lease renewal? How would this prevent the client from sending a unicast renewal message to the server? It sounds like a routing/network issue, not an issue with the mechanics of DHCP. Option 54 allows a DHCP client to specify which lease offer it's accepting during DHCPRequest. I'm not aware that option 54 is relevant to the lease renewal. If unicast traffic is not being routed to the server subnet then that's a routing/network issue, not a DHCP issue. In addition, a renewal in the T1 stage is unicast, not broadcast. Am I misunderstanding what you're saying?
    – joeqwerty
    Sep 8 '11 at 3:12
  • The IP address that the client gets in option 54 is where it sends the unicast renewal requests.
    – mmb
    Sep 8 '11 at 13:57
  • Yes, and what's the problem with that? When the client initiates the renewal process (T1 stage) it should send a unicast message to the server. Why would that unicast message not be routed to the server? If the unicast message is not being routed to the server then that's a routing/network problem, not a DHCP problem. I'm afraid I'm not following you on this one.
    – joeqwerty
    Sep 8 '11 at 14:01
  • So you are saying in a normal DHCP relaying setup all subnets that get their DHCP traffic relayed need to route back to the DHCP server? My original assumption (which might be wrong) was that the point of DHCP relaying was that everything happened through the relay and they didn't need to route there. I'm trying to figure out what a normal DHCP relaying setup is.
    – mmb
    Sep 9 '11 at 13:36

OK It seems I cannot comment on a previous answer but just spam you with an extra answer.

I think that this is not exactly a routing issue. Look at the following very basic example to understand:

  1. I send a DISCOVER in broadcast on both layer 2 and layer 3,
  2. I receive an OFFER in "double" broadcast as well,
  3. I sent a REQUEST in "double" broadcast again (so as to inform potential secondary DHCP servers that I discarded their offer)
  4. the server ACK's in broadcast or unicast.

=> Where did I need to know the MAC of the server? nowhere. I cannot be sure that the source MAC of the packets I received, be they in broadcast or unicast, is the MAC of the server. Anyhow, there is a high chance that T1 exceeds the arp cache timeout...

  1. T1 expires. I want to renew. I should send a L3 unicast message to the DCHP server (siaddr). Say I did not ask option 3. What destination MAC will I select?

Normally I will ARP the siaddr. What if the unicast Server IP is NOT on my link? Well I'll eventually drop the request and any successive retry, until I get in REBINDING state.

There is no real routing error here. It is a topology issue, and I am not even able to implement a solution where I would send the renew to the 'giaddr' IP, as this is against the standard.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.