EVPN/VXLAN DHCP Relay Troubleshooting: Find Missing Leases Fast

EVPN/VXLAN DHCP relay troubleshooting is one of those operational tasks where the first packet capture often tells only half of the story. You may see the client broadcast leave the access VLAN, the relay agent forward it toward a central DHCP service, and still the host never receives an address.

The most useful way to debug it is to treat DHCP as a routed workflow across two planes: the local anycast gateway and relay behavior on the leaf, plus the EVPN control-plane state that lets the DHCP reply find its way back to the correct tenant subnet.

X Follow @ipexptobe

This guide gives a practical checklist for data center fabrics, private cloud networks and AI infrastructure management or provisioning VLANs. It fits naturally with the Data Center Networking and AI Infrastructure & Automation hubs, and it is a good follow-up topic for readers starting from the Start Here networking topics page.

Source: generic derived diagram created for Network freak / IPexpToBe; no customer names, real hostnames or production IP addresses.

The problem: DHCP works in one VLAN but fails in another VNI

A common symptom is selective failure. Some tenant networks receive leases immediately, while one new VLAN/VNI pair times out. The server is reachable. The relay address looks correct. The fabric appears healthy. Yet the endpoint remains in a discovering state.

In EVPN/VXLAN environments, DHCP relay depends on more than the helper address. You need all of these to line up:

• the access VLAN maps to the intended L2 VNI;
• the SVI belongs to the correct tenant VRF and has the relay/helper configuration;
• the relay forwards the packet using the expected source or gateway address, often the SVI address used as giaddr;
• the DHCP server has a scope or policy that matches that relay address;
• the return path from the DHCP server VRF back to the tenant gateway is present and imported by the right route targets;
• security filters allow UDP 67/68 in the required direction.

Design baseline: know where the DHCP reply should go

Before touching configuration, write down the intended path in one line:

client VLAN/VNI → local anycast SVI relay → DHCP server/service VRF → route back to relay giaddr → leaf SVI → client

That line is more valuable than it looks. Many troubleshooting sessions only check the forward path toward the server. DHCP also needs the server reply to route back to the relay agent. In an EVPN fabric, that return route may be a tenant prefix advertised as an EVPN Type-5 route, a route leaking policy between a service VRF and tenant VRF, or a static route on a firewall/service appliance.

Pay attention to giaddr and VRF context

The giaddr value tells the DHCP server which scope to use and where to send the reply. In a simple design it is the SVI address for the client subnet. In a more complex design with relay source-interface options or centralized gateways, it may be different. Either way, the DHCP server must have a route back to that address.

If the helper address is configured under the wrong VRF, the relay may send packets from an unexpected routing table. The capture then looks confusing: the discover reaches the server, but replies follow a different path or die at a route-leaking boundary.

Implementation and configuration checklist

The exact syntax varies by vendor, but the required intent is consistent. Use this as a pre-change and troubleshooting checklist.

1. Validate VLAN, VNI and SVI binding

show vlan id 120
show nve vni 10120
show interface vlan 120
show vrf interface vlan 120
show bgp l2vpn evpn vni 10120

Look for mismatches such as VLAN 120 mapped to the wrong VNI, an SVI placed in the wrong VRF, or an SVI that is administratively up but not operationally forwarding because no local member port is active.

2. Confirm relay configuration on every active gateway leaf

With anycast gateway designs, more than one leaf may be able to relay for the same subnet. Confirm that the helper configuration is consistent on all active gateway nodes, not only on the leaf where you happened to test first.

show running-config interface vlan 120
show ip dhcp relay interface vlan 120
show ip dhcp relay statistics
show logging | include DHCP|relay|helper

If one leaf has a missing helper address and another leaf is correct, the issue can appear intermittent depending on where the host is connected or where an active/active bond hashes traffic.

3. Check the DHCP server route back to the relay address

On the service side, verify the route to the SVI or relay source address. In EVPN fabrics, also verify the route target policy that imports the tenant route into the service VRF.

show ip route vrf SERVICES <relay-giaddr>
show bgp l2vpn evpn route-type 5 | include <tenant-prefix>
show bgp vrf SERVICES <tenant-prefix>
show route-map | include TENANT|SERVICES

If the design uses a firewall between tenants and shared services, check both the route table and the policy. A firewall may allow DNS and NTP but silently drop DHCP relay replies because UDP 67/68 was not included in the service object.

4. Verify DHCP scope and Option 82 behavior

The server must understand the relay address and any relay agent information inserted by the fabric. If Option 82 is enabled, verify whether the server accepts, ignores or requires specific circuit-id/remote-id values.

scope/network includes relay giaddr
policy permits relay agent information
no conflicting exclusion range
lease pool has free addresses
server logs show DHCPOFFER or policy deny

When the server logs show a discover but no offer, suspect scope selection, exhausted pools, Option 82 policy, or duplicate address detection delays. When the server sends an offer but the relay never sees it, focus on routing, route targets, ACLs and service-chain policy.

Verification workflow: follow one transaction end to end

Use a single test client and follow one DHCP transaction through the fabric. Avoid changing multiple variables at once.

1. Clear stale client leases or force a DHCP renew on the endpoint.
2. On the access leaf, watch relay counters before and after the request.
3. Capture or mirror on the SVI/relay point if the platform supports it.
4. Check whether the DHCP server receives the discover and what giaddr it sees.
5. Confirm whether the server sends an offer.
6. Trace the route from the server or service VRF back to the relay address.
7. Check EVPN Type-5, route target import/export and any firewall/service policy on that return path.

Fast fault isolation matrix

Observation	Most likely area	Next check
No relay counter increase	VLAN/VNI/SVI/local access	VLAN membership, SVI state, local endpoint placement
Server never sees discover	Forward path or relay VRF	Helper address, service route, ACL, firewall
Server sees discover but sends no offer	DHCP policy	Scope, pool exhaustion, Option 82 policy
Server sends offer but client never receives it	Return route	Type-5 route, RT import/export, service-chain state

Automation idea: turn DHCP relay checks into a pre-flight test

This is a useful place for simple network automation or AI-assisted change review. Before adding a new tenant VLAN, have the workflow collect and compare:

• intended VLAN, VNI, VRF and SVI address from the source of truth;
• live SVI and relay configuration from every relevant leaf;
• EVPN Type-2/Type-5 visibility for the tenant and service VRFs;
• route target import/export policy;
• DHCP scope existence and available lease count, if the DHCP platform exposes an API.

The automation does not need to make changes automatically. Even a read-only report can stop a failed maintenance window by flagging: “VNI exists, but service VRF does not import the tenant prefix” or “DHCP scope missing for relay address.” For more automation-focused reading, see the AI Infrastructure & Automation page and the Useful Networking, BGP and AI Resources list.

Practical takeaways

• Do not troubleshoot EVPN/VXLAN DHCP relay as only a Layer 2 problem. The return route is often the failure.
• Always record the expected giaddr and VRF before checking logs or captures.
• In anycast gateway fabrics, compare relay configuration across all gateway leaves.
• If the server sees the discover but sends no offer, focus on DHCP scope and Option 82 policy.
• If the server sends an offer but the client never receives it, focus on Type-5 routes, route targets, route leaking and service firewall policy.

DHCP is basic, but in an EVPN fabric it crosses several design boundaries. A small checklist that follows one transaction end to end is usually faster than staring at one switch and hoping the missing lease explains itself.

Follow Network freak for more networking notes, diagrams and troubleshooting tips.

X @ipexptobe on X