3

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?

mmb
  • 31

3 Answers3

3

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).

Shane Madden
  • 115,228
1

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.

EDIT

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

EDIT 2

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.

joeqwerty
  • 110,860
  • 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 08 '11 at 02: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 08 '11 at 03:12
  • The IP address that the client gets in option 54 is where it sends the unicast renewal requests. – mmb Sep 08 '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 08 '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 09 '11 at 13:36
  • There has to be a route between the two subnets in order for DHCP (or any other communication) to work at all. The DHCP relay agent takes the DHCP client broadcast message (DHCPDiscover) and transforms that into a unicast message and forwards it to the DHCP server by way of the "route" between the two subnets. The actual broadcast from the DHCP client is not broadcasted across the subnets by way of the DCHP relay agent, it is unicasted from the relay agent to the server. Continued... – joeqwerty Sep 09 '11 at 13:51
  • During the T1 renewal stage the DHCP client unicasts to the server directly, during the T2 renewal stage the client resorts to broadcast and the DHCP relay agent then should come into action and unicast that broadcast message to the server. At the end of the day, the DHCP relay agent needs to be able to send traffic from the client subnet to the server subnet. That is facilitated by way of the router, not the relay agent. The relay agent does nothing more than transform the client broadcast into a unicast. If there's no route between the subnets then this unicast message won't go anywhere. – joeqwerty Sep 09 '11 at 13:52
  • As a test, why don't you remove the route between the two subnets and see what happens? – joeqwerty Sep 09 '11 at 14:09
0

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.

user2773019
  • 1