In this scenario, the client is connected to an access switch that is dual‑homed to a pair of Leafs in an ERB topology with Anycast Gateways acting as DHCP relays. The DHCP server resides in another data center that uses a CRB topology. The client successfully obtains an IP address when the DHCP Discovery is forwarded through Leaf 1. However, when both Leafs are active or traffic is sent through Leaf 2, the DHCP Offer from the remote site’s DHCP server is not received.

Symptoms

• Leafs acting as DHCP relays on the ERB toplogy.
• The DHCP client successfully obtains an IP address when DHCP Discovery is hashed through Leaf 1, however, when is hashed through Leaf 2, the DHCP Offer is not received.
• Both leaf switches have the same configuration.
• The DHCP Offer is not observed on the DCI links between the data centers.
• After reconfiguring the Leaf switches connected to the access layer to use "VGA" rather than Anycast Gateways, DHCP Offers are received correctly when both Leafs are active.

Topology

The DHCP client is connected to an access switch that is dual‑homed to a pair of Leaf switches in an ERB topology on VLAN 10. The DHCP server resides in another data center, where it is dual‑homed to a pair of leaf switches in a CRB topology on VLAN 20. Communication between the DHCP client and the DHCP server therefore traverses the DCI links between the two sites.

Issue Descriptor 

The client successfully obtains an IP address when the DHCP Discovery is forwarded through Leaf1‑B—the DHCP Offer is received from the remote DHCP server via the DCI link, and the full transaction completes. However, when both Leafs are active, or when traffic is forced through Leaf 2 by disabling the link to Leaf 1 on the access switch, the DHCP Offer is not received.

Resolution

IPs from the Leafs on site B:

Leaf1-B

• 
  irb.10: 10.10.10.1/24
  lo0.2: 192.168.10.11/32

Leaf2-B 

• irb.10: 10.10.10.1/24
• lo0.2: 192.168.20.12/32

Configuration for the VRF on both Leafs:

set routing-instances TENANT_CLIENT_VRF1 description "VRF for DHCP Clients in VRF1”
set routing-instances TENANT_CLIENT_VRF1 instance-type vrf
set routing-instances TENANT_CLIENT_VRF1 interface irb.10
set routing-instances TENANT_CLIENT_VRF1 interface lo0.2
set routing-instances TENANT_CLIENT_VRF1 route-distinguisher 1.1.5.2:1100
set routing-instances TENANT_CLIENT_VRF1 vrf-target target:10:65001
set routing-instances TENANT_CLIENT_VRF1 vrf-table-label
set routing-instances TENANT_CLIENT_VRF1 routing-options auto-export
set routing-instances TENANT_CLIENT_VRF1 forwarding-options dhcp-relay forward-only
routing-instance TENANT_SERVICE_VRF
set routing-instances TENANT_CLIENT_VRF1 forwarding-options dhcp-relay server-group
DHCP_SERVER_GROUP_1 10.10.20.10
set routing-instances TENANT_CLIENT_VRF1 forwarding-options dhcp-relay group Relay_Group1
active-server-group DHCP_SERVER_GROUP_1
set routing-instances TENANT_CLIENT_VRF1 forwarding-options dhcp-relay group Relay_Group1
overrides relay-source lo0.2
set routing-instances TENANT_CLIENT_VRF1 forwarding-options dhcp-relay group Relay_Group1
relay-option-82 server-id-override
set routing-instances TENANT_CLIENT_VRF1 forwarding-options dhcp-relay group Relay_Group1
interface irb.10

• We verified that the configuration aligns with the documented recommendations. The setup includes "forward‑only", "relay‑option 82", and overrides the relay source using an individual IP, in this case "lo0.2" to avoid relying on the Anycast Gateways as the DHCP relay source. Reference documentation: https://www.juniper.net/documentation/us/en/software/nce/nce-216-evpn-dhcp-relay/nce-216-evpn-dhcp-relay.pdf
• When both links are active—or when traffic is forced through Leaf 2—we observe the DHCP Discovery but not the DHCP Offer from the server. A packet capture on the DHCP server side confirms that the Discovery arrives and the server replies with an Offer, but the Offer does not reach Leaf 2.
• When checking a PCAP on the server side, the DHCP Offer itself appeared correct: the relay source was set to "lo0.2", and "Option 82" included irb.10 for the subnet identification.
• We tested using VGA instead of Anycast Gateways, and in that scenario the DHCP client successfully obtained an address while both Leafs were active. However, this is not a viable long‑term solution since the VNI may be distributed across multiple leafs.
• The only configuration difference between the two Leafs was the DHCP relay source, which in both cases was "lo0.2" with a diferent IP. Further analysis on the DHCP flow confirmed that the Offer was not received by the Border Leaf.
• Troubleshooting revealed that within the CRB site, the Spines had no connectivity to "lo0.2" of Leaf 2 within that VRF, although connectivity existed to "lo0.2" of Leaf 1. On the Spines, we confirmed that no Type 5 route was received for "lo0.2" from Leaf 2, preventing proper communication when this agent address was use on the DHCP Discovery sent by Leaf 2 source.

The issue was resolved after adding the required statement on the Spines of the CRB enviroment to accept the route from "lo0.2" of Leaf2-B.

set policy-options policy-statement VRF_T5 term BGP_ERB from route-filter 192.168.20.0/24 exact