DHCP Relaying Details

Chinar Trivedi asked an interesting question about DHCP relaying in VXLAN/EVPN world on Twitter and my first thought was “that shouldn’t be hard” but when I read the first answer that turned into “wait a minute, how exactly does DHCP relaying works?”

I’m positive there’s a tutorial out there somewhere, but I decided to go back to the sources of wisdom: the RFCs. It turned out to be a long walk down the IETF history lane.

Simple DHCP Relaying

Interestingly, RFC 2131 (DHCP) does not define relaying at all but refers to Clarifications and Extensions for the BOOTP (RFC 1542)1. Here’s how it works:

  • The DHCP client2 sends a DHCPDISCOVER message as a layer-2 broadcast. It SHOULD set the chaddr field3 in the request message to its MAC address.
  • A relaying agent receives that broadcast, turns it into an IP unicast4 and sends that toward the DHCP server.
  • The relaying agent sets the giaddr (gateway IP address) field in the forwarded DHCP message if it hasn’t been set already. When you’re using a series of DHCP relays5, only the first relay sets the giaddr6.
  • DHCP server COULD use the giaddr IP address to select the IP subnet to use for client address allocation if the relaying agent hasn’t added the IPv4 Subnet Selection Option to the forwarded message.
  • DHCP server creates a reply message, copies chaddr field from the request into it, and sends the reply message straight to giaddr – the first relay.
  • A relaying agent receiving a response from a DHCP server selects the outbound interface based on the giaddr, and sends the response to the client as a unicast (assuming the chaddr field is set) or a local broadcast (if the chaddr field is not set, or if the broadcast flag was set by the client).

Relay Options

So far so good, but life is never as easy as that. RFC 3046 (DHCP Relay Agent Information Option) defines the famous Option 82 that initially contained Circuit ID (incoming interface) and Remote ID (end user). DHCP server COULD use that information to:

  • “Authenticate” the end-user (has the user connected to port X paid last month’s bill?)
  • Assign a fixed IP address to an end-user based on the access interface to which the end-user is attached.

It’s also worth noting that the DHCP server copies option 82 into DHCP reply messages7. A DHCP relay could use option 82 from the reply message instead of giaddr to select the outgoing interface for the forwarded reply.

With the generic relay information option infrastructure in place, vendor creativity soared. Cisco SDA uses remote ID sub-option to encode VNI and RLOC, and DMVPN uses it to store the transport IP address of the DMVPN spoke.

But wait, that’s not all. IANA DHCP registry defines over 20 sub-options of option 82, including DOCSIS device class, Subscriber ID8, RADIUS attributes9, Authentication10…

Inter-VRF DHCP Relaying

Let’s add another layer of complexity: we want to have DHCP client and DHCP server in different VRFs11. One could solve this requirement with inter-VRF route leaking (effectively implementing common services VRF), but then you couldn’t have overlapping IP address space in the client VRFs. Time for more DHCP Relay Agent sub-options.

Ignoring the endless creativity IETF always demonstrates when it comes to exploring every corner case in the solution space, here are the sub-options we need to implement inter-VRF DHCP relaying:

  • Link selection (RFC 3527) replaces the giaddr-based subnet selection functionality when the DHCP relay decides it makes sense to use a different IP address to communicate with the DHCP server.
  • Server Identifier (RFC 5107) allows the relaying agent to tell the DHCP server to masquerade as something else.
  • Virtual Subnet Selection (RFC 6607) specifies the VRF/VPN from which the DHCP request came from.

In a typical inter-VRF DHCP relaying setup, the DHCP relay would:

  • Copy IP address configured on its incoming interface (in customer VRF) into link selection and server identifier sub-options
  • Add VPN identifier (VRF name or ID) as virtual subnet selection sub-option
  • Set giaddr to the IP address of the outgoing interface (in global IP routing table or management VRF).

DHCP server would do its work and send the reply to giaddr, which is reachable from the DHCP server. DHCP relay would figure out which VRF and outgoing interface to use from the sub-options received in the DHCP reply (note that it inserted those same options into the DHCP request when relaying it12) and forward the reply to the client.

Now for the magic bit: because the DHCP relay asked the server to lie to the client about its real IP address (using server identifier sub-option), all subsequent unicast packets are sent from the client to the DHCP relay which then forwards (relays) them into the DHCP server VRF – there’s no need for inter-VRF route leaking if you have properly-implemented VRF-aware DHCP relay.

Now that we know the relevant DHCP relaying details, it’s easy(er) to figure out how to make it work in EVPN/VXLAN environment (or you’ll have to wait for the follow-up blog post).

Next: DHCP Relaying Lab Continue

Revision History

2023-03-10
Added option-82 examples

  1. I hope you realized that the only reason your phone gets an IP address when it’s turned on is an ancient bit of technology developed in early 1980s. ↩︎

  2. OK, technically it’s a BOOTP client, but who’s counting ;) ↩︎

  3. There’s another RFC describing how to deal with brain-dead clients that can’t figure out what their MAC address is. No, I’m not going there ;) ↩︎

  4. Or another (subnet-level) broadcast or a batch of packets with different destinations, but let’s try to keep things simple. ↩︎

  5. Hopefully to increase your job security, I see no other good reason ;) ↩︎

  6. There’s also a “forwarded hop count”, but as I said, let’s try not to explore every crazy rabbit trail there is. ↩︎

  7. Apart from one of the Virtual Subnet Selection sub-options. Read RFC 6607 if you crave those details. ↩︎

  8. Because Circuit ID and Remote ID are obviously not good enough ;) ↩︎

  9. What could be better than using RADIUS and DHCP and passing information between the two in a DHCP option? ↩︎

  10. Let’s reinvent CHAP or 802.1X ↩︎

  11. Or have one of them in a VRF and the other one in the global routing table. ↩︎

  12. Ignoring yet another detour: the client VPN/VRF membership could be determined by the DHCP server ;) ↩︎

Blog posts in DHCP Relaying series

Recent posts in the same categories

2 comments:

  1. Pere Camps 09 March 2023 11:36

    DHCP in EVPN/VXLAN (with anycast) is so evil that we're thinking of running standalone DHCP Relay servers in vrfs outside EVPN/VXLAN.

    Why do I mean by evil (or maybe just badly implemented in our kit):

    • DHCP requests going to old servers that are no longer configured
    • DHCP requests being mangled for IRBs that are not configured for it
    • DHCP requests going nowhere: debug traces say "DHCP packet being forwarded" but if you capture all the traffic from all interfaces... it's nowhere to be seen.

    I'd strongly recommend anybody that has to use this to get a complete understanding of how it's supposed to work, it's not a simple "configure ip helper address on the respective IRBs and you're done"

    Replies
    1. Jason Alert 10 March 2023 07:00

      Just out of curiosity, what kind of kit? I haven’t seen any issues with VRF-aware DHCP relay and EVPN asymmetrical IRB on Arista Trident3 or Tomahawk kit, so wondering if it’s a vendor or chipset implementation issue, or something specific to the setup.

    2. Ivan Pepelnjak 10 March 2023 07:35

      DHCP relaying is a control-plane activity (it would be really hard to rewrite the packet and add option-82 in hardware), so it's most probably a vendor software implementation issue.

    3. Jason Alert 10 March 2023 04:34

      Agreed on the control plane activity. I only mention chipset since (speculation on my part based on other bugs I have seen) differences in hardware pipeline may result in alternate code paths involved when punting to CPU, so I wouldn’t completely rule out seeing bugs affecting a subset of platforms from the same vendor.

  2. chris marget 09 March 2023 02:38

    Daisy-chaining DHCP relays? Goodness.

    A related and fun rabbit trail is when you're using DHCP for DMVPN spokes.

    There's some unicast levers which need to be pulled, but more interesting is how the relay (the DMVPN hub) delivers the Offer and Ack to the DMVPN spoke. Neither giaddr nor broadcast mode will get it there. We need the tunnel's NBMA address.

    The hub/relay packs the sender/client NBMA address into option 82 when relaying messages from the client, and then relies on that same field to target the server replies back toward the client.

Add comment
Home
Sidebar