EVPN interop between Cisco and Juniper almost works. That's the polite version. The reality: every vendor implements RFC 7432 and RFC 8365 just differently enough that a fabric that looks fine at the BGP session layer silently misbehaves at the route-import layer. This guide walks through the three interop bugs we see most often in production — with a reproducible cloud lab for each — so you can diagnose yours in an afternoon instead of a week.
The three bugs that break 80% of Cisco-Juniper EVPN fabrics
Over a few years of watching engineers debug cross-vendor EVPN in customer incidents and TAC cases, three patterns dominate:
- Route-target auto-derivation mismatch. The peering is up. BGP EVPN routes are advertised. But the receiving vendor doesn't import them — because its auto-derived RT differs from the sender's. No error, no log line, just silently dropped routes.
- Type-2 (MAC/IP) route non-import with explicit RT. You configured explicit RTs. Sessions are up. Type-3 (Inclusive Multicast) routes exchange fine. Type-2 routes still don't import on one side. The cause is usually a mismatch in how ESI or anchor-peer semantics are interpreted.
- Proxy-ARP and ARP suppression behavior differences. L2 reachability works across vendor boundaries, but ARP resolution times spike, or silent hosts occasionally go unreachable. The two vendors differ in how and when to answer ARP on behalf of EVPN-learned hosts.
None of these show up in the usual show bgp output. All of them look like "networking just randomly broke for this one tenant." All of them are reproducible in about 5 minutes of lab time.
The lab: 2 vendors, 2 prompts
You only need one small multi-vendor lab to reproduce every bug in this guide. Copy this into NetPilot:
Build an EVPN-VXLAN interop lab with 1 Cisco IOL router (as leaf1) and 1 Juniper cRPD router (as leaf2), both connected to a shared underlay. Use eBGP underlay with Cisco in AS 65001 and Juniper in AS 65002. Establish BGP EVPN address family between them. Create VLAN 100 mapped to VNI 10100 on both leaves. Subnet 192.168.100.0/24. Place one host on each leaf. I want to test route-target handling, Type-2 route exchange, and ARP behavior between vendors.
Two minutes later the lab is live and you're SSH'd into both devices.
Bug 1: Route-Target Auto-Derivation Mismatch
The symptom
BGP session is up. You see EVPN routes advertised. The remote side sees them too — in the raw BGP table. But the route doesn't appear in the EVPN table of the receiving vendor.
The cause
Both vendors support auto-derivation of route-targets from the VNI. But they derive them differently:
- Cisco NX-OS auto-derives RT as
AS:VNI(e.g.,65001:10100) - Arista EOS auto-derives RT similarly but with subtle encoding differences for VNIs above 65535
- Juniper Junos requires an explicit RT configuration — no auto-derivation
- Nokia SR Linux uses explicit config with different syntax conventions
When the Juniper side has no matching import RT, the route is received but silently filtered.
Reproduction
On the Cisco side, configure EVPN with auto-RT:
router bgp 65001
address-family l2vpn evpn
advertise-all-vni
vlan 100
vn-segment 10100
rd auto
route-target import auto
route-target export autoOn the Juniper side, configure EVPN without matching RTs:
set routing-instances TENANT1 instance-type virtual-switch
set routing-instances TENANT1 vtep-source-interface lo0.0
set routing-instances TENANT1 route-distinguisher 2.2.2.2:100
# no vrf-target or vrf-import/export configuredVerify with the agent:
"Check EVPN route exchange between Cisco and Juniper — show what Cisco is advertising and whether Juniper is importing those routes into its EVPN instance."
The agent queries both devices and returns the key delta: Cisco is advertising routes (visible in its BGP table), Juniper receives them in the raw BGP table but its EVPN database is empty — the import isn't happening.
Direct CLI if you want to inspect by hand:
show bgp l2vpn evpnshow route table bgp.evpn.0
show evpn databaseThe fix
Always specify explicit route-targets in multi-vendor EVPN deployments. Ask the agent:
"Configure Juniper TENANT1 with explicit import/export VRF target matching Cisco's auto-derived RT of 65001:10100."
Or apply directly via CLI:
set routing-instances TENANT1 vrf-target target:65001:10100Retest by asking the agent to verify EVPN database state again. Type-2 routes should now appear.
Bug 2: Type-2 Route Non-Import with Correct RT
The symptom
RTs match. Type-3 (Inclusive Multicast) routes exchange and establish the VTEP mesh. Type-2 (MAC/IP) routes are advertised from Cisco but never appear in the Juniper EVPN database. Type-5 (IP Prefix) routes may or may not behave similarly.
The cause
Cisco's default behavior is to advertise Type-2 routes with an ESI of 0 when the interface is single-homed. Juniper's default handling of zero-ESI Type-2 routes is to import them — but only if the mac-vrf or virtual-switch instance has the correct BUM replication mode configured. If the Junos side is configured for ingress-replication but expects an ESI of 0 with a specific sequence number handling, it silently drops routes that don't match its expectations.
Reproduction
Trigger this by configuring Juniper with active-active multihoming expectations while Cisco advertises single-homed routes:
set interfaces xe-0/0/0 unit 0 family ethernet-switching vlan members 100
set ethernet-switching-options secure-access-port interface xe-0/0/0 allowed-ethernet-types
set routing-instances TENANT1 protocols evpn extended-vni-list all
set routing-instances TENANT1 protocols evpn multicast-mode ingress-replication
# missing: anchor-peer or multi-homed ESI config for this interfaceVerify with the agent:
"Check whether Juniper is receiving Type-2 routes from Cisco in its BGP table, and whether they're being imported into the EVPN database."
The agent checks both tables and flags the mismatch: routes present in bgp.evpn.0 but absent from the EVPN instance database.
Direct CLI for deeper inspection:
show route receive-protocol bgp <cisco-peer-ip> table bgp.evpn.0
show evpn database
monitor traffic interface fxp0 | match "BGP"The routes are received but not imported because the instance configuration doesn't match what Cisco is advertising.
The fix
Ask the agent:
"Fix the Juniper TENANT1 EVPN instance so Type-2 routes from single-homed Cisco peers are imported correctly."
Or apply directly via CLI:
set routing-instances TENANT1 protocols evpn default-gateway do-not-advertise
set routing-instances TENANT1 protocols evpn remote-ip-host-routesRetest by asking the agent to verify EVPN database state. Type-2 routes should now appear.
Bug 3: Proxy-ARP Behavior Differences
The symptom
Pings work. TCP sessions work. But applications that rely on aggressive ARP caching (load balancers, clustered databases, DHCP servers) occasionally time out. Packet capture shows ARP resolution taking much longer than expected — sometimes 200-500ms, sometimes multiple seconds.
The cause
In EVPN-VXLAN fabrics with ARP suppression enabled, the local VTEP should respond to ARP requests on behalf of remote hosts, using MAC addresses learned from Type-2 EVPN routes. Cisco and Juniper handle this differently:
- Cisco NX-OS: Proxy-ARP behavior is controlled at the L2VNI level —
suppress-arpis typically on by default for VXLAN L2 gateways. - Juniper Junos: Proxy-ARP on EVPN interfaces requires explicit
proxy-macip-advertisementconfiguration and depends on whether the MAC-IP binding came from a local host or was learned via EVPN.
When one side suppresses ARP locally and the other doesn't, some ARP traffic unnecessarily floods the fabric and some is silently dropped — producing the intermittent slowdown.
Reproduction
On the Juniper side, omit proxy-macip config:
set routing-instances TENANT1 protocols evpn extended-vni-list all
# missing: set routing-instances TENANT1 protocols evpn no-arp-suppression
# or proxy-macip-advertisement configOn the Cisco side, aggressive ARP suppression:
evpn
vlan 100
suppress-arpFrom a Linux host behind Juniper:
# Force frequent ARP lookups
while true; do
arping -c 1 192.168.100.10 # host behind Cisco
sleep 1
doneMonitor ARP behavior from both sides. You'll observe sporadic delays as the two VTEPs disagree about who should answer.
The fix
Ask the agent:
"Align ARP suppression between Cisco and Juniper — enable proxy-macip-advertisement on Juniper TENANT1 and confirm Cisco has suppress-arp on VLAN 100."
The agent applies both sides and confirms. Direct CLI if you prefer to apply by hand:
set routing-instances TENANT1 protocols evpn proxy-macip-advertisementevpn
vlan 100
suppress-arpRetest by asking the agent to run the arping test and measure response times. The intermittent delays disappear.
Debugging workflow in a virtual lab
The traditional debugging loop on live production gear is slow: capture traffic, open a TAC case, wait for vendor response, change config, hope a rollback works if it makes things worse. Each iteration takes hours to days.
In a NetPilot lab the loop compresses to minutes:
- Describe the interop issue in plain English — the agent builds the same topology both vendors run in production
- Ask the agent to apply the candidate fix — it generates the correct syntax per vendor and commits
- Ask the agent to verify the result — it checks state across both devices and flags what changed
- Iterate in 2 minutes — if you need a clean state, redeploy from the original prompt
- Use direct CLI for deep inspection — SSH into either device and run
monitor traffic,debug bgp update, or any other diagnostic command - Save the repro as a prompt for your team knowledge base
The full catalog of interop bugs has a long tail, but the three above cover most of what we see in incidents. For the full cross-vendor comparison workflow, see How to Reproduce a Cross-Vendor EVPN Bug in 10 Minutes.
FAQ
Why do Cisco and Juniper EVPN implementations differ if they follow the same RFC?
RFC 7432 and RFC 8365 define EVPN's protocol behavior but leave many defaults and operational choices to the vendor. Route-target derivation, default BUM replication mode, proxy-ARP behavior, ESI handling semantics — each is an implementation decision. Vendors optimize for their own products' typical deployments, which means cross-vendor interop almost always requires explicit configuration rather than relying on defaults.
Can I test this interop without buying Cisco and Juniper gear?
Yes. NetPilot runs Cisco IOL and Juniper cRPD as real container-based vendor NOS instances. Both run the actual vendor CLI and route processing code — not simulation. Describe the topology in plain English and the lab deploys in under 2 minutes with SSH access to each device.
What's the difference between Type-2, Type-3, and Type-5 EVPN routes?
- Type-2 (MAC/IP Advertisement): Carries MAC addresses, optionally with associated IP, for L2 forwarding and ARP resolution.
- Type-3 (Inclusive Multicast Ethernet Tag): Advertises VTEP membership in a BUM replication tree.
- Type-5 (IP Prefix): Carries IP prefixes for L3 routing across EVPN.
Most interop bugs happen at Type-2 because MAC address handling involves the most vendor-specific behavior.
How do I force Juniper to import all Cisco EVPN routes?
Use explicit vrf-target and vrf-import/vrf-export statements matching Cisco's advertised RTs. Never rely on auto-derivation when Cisco is on the other end — Junos does not auto-derive. For Type-2 specifically, also confirm your virtual-switch or mac-vrf instance has BUM replication settings that match the Cisco side.
Can I reproduce Arista or Nokia interop issues the same way?
Yes. Swap the vendor in the prompt. NetPilot supports Cisco IOL, Arista cEOS, Juniper cRPD, Nokia SR Linux, Palo Alto PAN-OS, Fortinet FortiGate, and FRR. For enterprise plans with SONiC or custom NOS images, see Multi-Vendor SONiC Labs.
Copy-paste ready: Use the cross-vendor EVPN bug reproduction prompt as your starting topology. Change the vendor mix or swap cRPD for another vendor image as needed.
Running enterprise EVPN validation at scale? See the Network Research Lab hub — built for this exact workflow across carrier, hyperscaler, and vendor R&D teams.