EVPN Route-Target Mismatch Across Two PODs
Two PODs in the same data center use separate underlay ASNs: POD-A leaf AS 65101, POD-B leaf AS 65201, with shared spines using AS 65000. Each POD has its own EVPN overlay; VLAN 110 maps to VNI 5010 in both PODs. Server A in POD-A and Server B in POD-B are in the same subnet 10.10.110.0/24. Server A can ping Server B only intermittently; local POD communication works. On the POD-A leaf, show evpn database shows the local MAC and an EVPN Type-2 route for Server B MAC and IP, but the route is not installed in the forwarding table. show route table bgp.evpn.0 shows the remote route with route-target 65101:5010, while local VNI 5010 is configured with vrf-target 65201:5010. ARP suppression is enabled on both PODs. The operations team wants to know why the route is present but not usable and whether ARP suppression is hiding the problem.
1. Diagnose why the Type-2 route is not installed. Include the commands and configuration comparisons you would use.
Read the worked answer
The route is in the BGP EVPN table but not installed because the route-target extended community does not match the local import target. The remote POD exports VLAN 110/VNI 5010 with target 65101:5010, derived from its leaf ASN; the local VNI imports only 65201:5010. BGP still receives the route, so show route table bgp.evpn.0 lists it, but the EVPN instance rejects it and it never reaches the forwarding table.
ARP suppression can make this look intermittent: the local leaf may answer ARP from a stale or local cache, but the Type-2 IP route is not usable, so traffic fails when it depends on proxy ARP. Confirm with show evpn database extensive for the remote MAC and IP and the route-target mismatch, and compare show configuration routing-instances TENANT-A vrf-target on both PODs. The immediate fix is a consistent explicit target, for example target:65000:5010, imported and exported on both PODs; do not rely on ASN-derived targets when POD ASNs differ.
2. Provide a configuration approach to make route targets consistent and preserve tenant separation.
Read the worked answer
Use explicit route targets under the tenant routing instance and, if needed, per VNI. On each POD, set the same route-distinguisher format but a unique RD per leaf, and the same vrf-target for import and export. Example on both PODs: set routing-instances TENANT-A vrf-target target:65000:5010. If the platform requires per-VNI control, apply the same target under the VLAN/VNI stanza.
Keep tenant separation by giving each tenant a different target, for example 65000:5010 for tenant A and 65000:5020 for tenant B. Verify with show route table bgp.evpn.0 detail that the extended community is present, then show evpn database that the remote MAC and IP are installed. Use a route-filter or VRF import policy only if you need to constrain which prefixes are accepted; the route target itself is the primary isolation mechanism.
3. What role does ARP suppression play, and what test proves the fix?
Read the worked answer
ARP suppression proxies ARP and ND replies using EVPN Type-2 MAC/IP routes. If the Type-2 route is rejected by route-target mismatch, suppression cannot reliably answer for the remote host; it may fall back to flooding or answer from a stale entry, producing intermittent success.
To prove the fix, first clear the ARP cache on Server A and check show evpn arp-cache and show evpn database for Server B IP and MAC. As a control, disable ARP suppression on VLAN 110 temporarily; if ping works but is slower, the data plane and Type-3 BUM path are intact and the issue is route installation or proxy behavior. After applying consistent route targets, re-enable suppression, clear ARP, and verify that show evpn database shows the remote MAC and IP installed and show ethernet-switching table has the MAC. A successful ping plus a populated proxy ARP entry is the proof; a ping alone is not, because flooding can mask a broken suppression design.