document relayVPC option for DHCP

[edipascale]

No description provided.

[github-actions]

🚀 Deployed on https://preview-283--hedgehog-docs.netlify.app

[Copilot]

Pull request overview

Adds user-guide documentation for the relayVPC DHCP option, describing how to relay DHCP requests to a server living in a different VPC (on the same leaf).

Changes:

• Extends the VPC YAML example to include dhcp.relayVPC.
• Adds a new section documenting “DHCP Relay to another VPC on the same leaf” with a full end-to-end example and sample DHCP server logs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[edipascale]

converting to draft until we finalize the fixes - we might enable cross-leaf dhcp relay to other VPCs after all. also we commented with Sergei to remove the existing third-party DHCP example

[Frostman]

Just marking it as we've decided to revert it and think more about it in the next release

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 5 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mrbojangles3]

To me, this line seems to indicate peering isn't needed if the VPCs share the same leaf? Will traffic flow unintentionally between two adjacent VPCs?

[edipascale]

that is indeed what I observed, but only for DHCP packets - it's not like I can ping between VPCs. It only happens when server and client are attached to the same leaf. Back when I was testing this I asked Claude and it gave me a rather long answer to justify it, I'll paste it here:

Claude reasoning for inter-VRF behavior

Cross-VRF DHCP Relay: Why it works on a single switch

The magic in the single-switch case comes down to how Linux VRF handles packets destined to locally owned IP addresses.

What the relay agent actually does

When you configure ip dhcp-relay vrf , SONiC's dhcrelay opens two sockets simultaneously:

• A socket bound to the origin VRF (or the client-facing interface) — listens for client broadcasts
• A socket bound to the target VRF device (via SO_BINDTODEVICE) — used to reach the server

When a DHCP Discover arrives on the client-facing socket, dhcrelay:

• Sets giaddr to its own IP on the origin-VRF interface (as per RFC 2131)
• Forwards the packet out through the target-VRF socket, bypassing the origin VRF routing table entirely

The source IP of the relayed UDP packet is typically the same as giaddr — an address that lives in the origin VRF.

Why the reply comes back (single-switch)

The DHCP server sends its offer/ack to giaddr. That packet enters the switch from the server-side (target VRF). Here's the key: Linux VRF does not enforce strict isolation for packets destined to locally configured IPs, even if they arrive in the "wrong" VRF. The kernel's local delivery path accepts them.

Client (origin VRF)          Switch                          Server (target VRF)
      |                   [dhcrelay process]                         |
      |--- DHCP Discover -->|                                        |
      |                     |--[target-VRF socket, giaddr=10.0.1.1]->|
      |                     |                                        |
      |                     |<--- DHCP Offer (dst=10.0.1.1) ---------|
      |                     |  ^                                      
      |                     |  Accepted: 10.0.1.1 is a local IP on this switch
      |                     |  (Linux delivers it regardless of arriving VRF)
      |<-- DHCP Offer ------|

Because giaddr is owned by the very switch performing the relay, no routing in the target VRF is needed — local delivery short-circuits the routing lookup. The dhcrelay process (sitting above the VRF boundary as a userspace application) picks it up and forwards it to the client.

Why it breaks across EVPN leaves

In the multi-leaf EVPN case, local delivery no longer applies. The flow breaks at step 4:

Client (Leaf-A, VRF-A)    Leaf-A (relay)            Leaf-B          DHCP Server
      |                       |                        |                  |
      |--- DHCP Discover ---->|                        |                  |
      |                       |--[VXLAN encap]-------->|                  |
      |                       |  giaddr = 10.0.1.1     |--[decap]-------->|
      |                       |  (Leaf-A's VRF-A IP)   |                  |
      |                       |                        |    Offer to      |
      |                       |                        |  dst=10.0.1.1 <--|
      |                       |                        |                  |
      |                       |            10.0.1.1 is NOT local here     |
      |                       |            No route to it in target VRF   |
      |                       |            → DROPPED                      |

Leaf-B (or the server itself) needs to route the reply back to giaddr. Since giaddr is an IP on Leaf-A's origin-VRF interface, there is no automatic mechanism to reach it from the target VRF on Leaf-B — hence why adding an explicit route fixes it.