DHCP Relay in EVPN-VXLAN

In the previous posts, I have discussed the construction of an EVPN VXLAN fabric using Cisco NDFC. A critical aspect often overlooked, which I'll cover here, involves the transition from a conventional 3-Tier DC architecture to an EVPN-VXLAN setup. One notable challenge in this transition is the configuration of the DHCP relay.

Traditionally, DHCP relays are configured to identify the default gateway, a process known as link-selection (specifically, Option 82 sub-option 5), to assign IP addresses from the correct pool. However, in an EVPN-VXLAN environment, the first hop gateway model is replaced with distributed anycast gateways. This change means all leaf switches have identical gateway IP and MAC addresses, disrupting the DHCP relay's functionality due to non-unique gateway addresses.

To resolve this, Cisco's documentation suggests creating a per-leaf per-VRF loopback address and adding specific DHCP Option 82 fields, such as Sub-option 151 for VRF name/VPN ID, Sub-option 11 for Server ID Override, and Sub-option 5 for Link Selection. These modifications are evident in packet captures.

Here's an example configuration for a Nexus 9000, applicable both globally and at the interface level:

feature dhcp
service dhcp

ip dhcp relay information option
ip dhcp relay information option vpn

interface loopback2
  vrf member v1
  ip address 10.33.33.33/32

interface VLAN20
  no shutdown
  vrf member v1
  ip address 192.168.20.254/24 tag 12345
  fabric forwarding mode anycast gateway
  ip dhcp relay address 192.168.10.9
  ip dhcp relay source-interface loopback2

A key element to focus on is Sub-option 5, which specifies the client's allocation subnet. Typically, this subnet matches the DHCP relay agent's IP address subnet. However, post-migration to EVPN-VXLAN, the per-VRF loopback address introduced may not fall within any DHCP server scope. Packet captures show the relay agent IP as 10.33.33.33 in such scenarios.

For Linux environments using isc-dhcp-server, the following configuration should suffice:

subnet 192.168.20.0 netmask 255.255.255.0 {
  option agent-selection 192.168.20.0;
  option routers 192.168.20.254;
  option subnet-mask 255.255.255.0;

  range 192.168.20.101 192.168.20.149;
}

With the introduction of Windows Server 2016, support for DHCP Option 82 and the link-selection sub-option became available. However, the Windows DHCP server may flag DHCP relay agents as rogue if they don't match any defined scope.

The workaround involves creating a special scope encompassing all GiAddr addresses, which represent the DHCP relay agents. This scope is activated by setting exclusions, preventing the DHCP server from allocating these addresses. In this case, simply add all loopback addresses in this GiAddr scope.

Finally, with the GiAddr scope defined, DHCP relay functionality is restored in Windows Server DHCP environments.

There is a nice technote in Cisco community detailing the issue, even it is for ACI but the behavior and resolution are pretty much similar.

Gary Wong@Australia, Dec 2023.

Update (Aug 2024):

NDFC provides an option to configure DHCP relay.

Under the network to be configured, choose Edit in the Action menu, then the DHCP relay config can be found at the Edit Network Advanced tab, shown below.