dhcp relay and dhcp offer packet

[ipcruiser81]

Hi!

A L3 interface is configured as a dhcp relay interface. After the DHCPDISCOVER message from a client is forwarded by this interface to the DHCP server (as defined with the ip helper address command), the DHCPOFFER response from the server is usually forwarded as a L2 broadcast by the L3 interface (destination mac: FFFF.FFFF.FFFF).

Question 1:

The clients within the same broadcast domain identifies the DHCPOFFER as the one directed at them by inspecting the client identifier (which is the client mac address) within the bootp protocol, correct?

Question 2:

I have seen instances (non Cisco) where the L3 dhcp relay interface forwards the DHCPOFFER with a unicast address (which is going to be the assigned IP for the requesting client) as opposed to a L2 broadcast. How is the L3 interface able to forward DHCPOFFER to the client, without sending out an ARP request to determine the destination MAC? Does the L3 switch look at the bootp packet (which sounds a bit unsual for a L3 switch to do ..)?

Thank you.

[Peter Paluch]

Hello,

The clients within the same broadcast domain identifies the DHCPOFFER as  the one directed at them by inspecting the client identifier (which is  the client mac address) within the bootp protocol, correct?

There are multiple fields in the DHCPOFFER message that allow a client to properly associate this OFFER with its own DISCOVER message:

• The Transaction ID must be the same as the one set by the client
• The chaddr field (client hardware address) must match the client's MAC address

The Client ID you originally referred to is in fact DHCP Option 61 present only in DHCPDISCOVER message sent by a client, and is not put back into DHCPOFFER by the server, therefore, it can not be used to associate the OFFER back with the DISCOVER message.

I have seen instances (non Cisco) where the L3 dhcp relay interface  forwards the DHCPOFFER with a unicast address (which is going to be the  assigned IP for the requesting client) as opposed to a L2 broadcast. How  is the L3 interface able to forward DHCPOFFER to the client, without  sending out an ARP request to determine the destination MAC? Does the L3  switch look at the bootp packet (which sounds a bit unsual for a L3  switch to do ..)?

The L3 switch performing the role of DHCP Relay Agent looks at the message contents indeed, and uses the chaddr field to learn about the MAC address of the client. It may then use it to encapsulate and address the forwarded OFFER. This may appear as unusual for an L3 switch but the role of DHCP Relay Agent requires the switch to perform more involved operations. In fact, when the DHCP server sends a reply back, it addresses it to the switch itself (by the destination IP address), so it processes it in its operating system, invoking the DHCP Relay Agent process to handle the reply.

Please feel welcome to ask further.

Best regards,

Peter

[ipcruiser81]

"

The L3 switch performing the role of DHCP Relay Agent looks at the message contents indeed, and uses the chaddr field to learn about the MAC address of the client. It may then use it  to encapsulate and address the forwarded OFFER. This may appear as  unusual for an L3 switch but the role of DHCP Relay Agent requires the  switch to perform more involved operations. In fact, when the DHCP  server sends a reply back, it addresses it to the switch itself (by the  destination IP address), so it processes it in its operating system,  invoking the DHCP Relay Agent process to handle the reply.

"

Thanks for that Peter, this would be the only explanation I could think off too. Is there any supporting literature for this behavior? Packet caps doesnt really say what the switch is doing with the DHCPOFFER or DHCPACK, other than change the destination MAC (to that of the client).