How does a router relay DHCP packets when it is configured as a relay agent?

Question

I know a router acting as a relay agent sends the DHCP messages from client to the DHCP server. When server replies back to the relay agent with the DHCPOFFER message how will this message be sent to client, broadcast or unicast?

Answer 1

Great question. The answer can be labbed in GNS3 like so -

Topology:

R1:

ip dhcp excluded-address 192.168.10.0 192.168.10.99
!
ip dhcp pool Users
   network 192.168.10.0 255.255.255.0
   default-router 192.168.10.1
!
ip route 192.168.10.0 255.255.255.0 10.1.2.2

R2:

interface FastEthernet0/1
 ip address 192.168.10.1 255.255.255.0
 ip helper-address 10.1.2.1

PC (which is actually just another router):

interface FastEthernet0/1
 ip address dhcp

Now let's take a look at some packet captures -

Traffic between R1 & R2:

Traffic between R2 & PC:

So you see, the traffic between R1 and R2 is unicast (as you'd expect) and the traffic between R2 and PC is broadcast, the same way as it would be if R2 were the DHCP server.

Note though that the DHCP request comes from R2's Fa0/1 interface. This therefore means that R1 needs a route to this network even though it is directly connected to R2. That explains why I've got the static route on R1.

Answer 2

The relay agent will send the DHCPOFFER as a broadcast if the broadcast flag is set, in the same manner as the DHCP server would. As far as the client is concerned, it is dealing with a DHCP server, not a relay agent.

RFC 2131, Dynamic Host Configuration Protocol:

Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client's IP address cannot be delivered until the client has been configured with an IP address).

A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit [21].

A server or relay agent sending or relaying a DHCP message directly to a DHCP client (i.e., not to a relay agent specified in the 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' field. If this bit is set to 1, the DHCP message SHOULD be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP unicast to the IP address specified in the 'yiaddr' field and the link-layer address specified in the 'chaddr' field. If unicasting is not possible, the message MAY be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link- layer broadcast address as the link-layer destination address.