The setup from the r/Juniper thread is textbook: two spines, two leafs, hosts multihomed to both leafs with EVPN-VXLAN — and host-to-host ping fails while the fabric itself looks configured. Overlay problems feel opaque because failure can hide at any of four layers. The fix is to test them in order and never skip ahead.

Layer 1: The Underlay Must Work First

VXLAN rides on the underlay routing (OSPF, IS-IS or BGP in the fabric). Prove loopback-to-loopback reachability between all VTEPs:

ping 10.255.0.12 source 10.255.0.11
show ospf neighbor
show interfaces ge-0/0/0 extensive

Any underlay gap makes the overlay fail in ways that look mysterious. While you are here, glance at interface counters — our CRC and input-errors guide explains why a corrupt uplink produces intermittent, "sometimes it pings" behavior.

Layer 2: Is the MAC Actually Learned?

show ethernet-switching table
show evpn database
show vxlan tunnel

For host A on leaf1 and host B on leaf2: leaf1 must list host B's MAC as remote, learned via EVPN, and vice versa. If the MAC appears on one leaf but never the other:

  • Verify the VLAN-to-VNI mapping is identical on every leaf — a single digit difference in vni silently splits broadcast domains.
  • Confirm vxlan is enabled with the same source vtep-source-interface lo0 everywhere.
  • Check show vxlan tunnel — every remote VTEP should appear as an active tunnel from the correct source and destination loopbacks.

Layer 2.5: ESI Multihoming Black Holes

Multihomed hosts are where EVPN deployments actually bleed. Each dual-homed link needs a matching ESI on both leafs, all-active mode, and healthy LACP:

show lacp interfaces ae0
show evpn es
show evpn es detail

The classic failure: the ESI is configured on one leaf but typo'd (or missing) on the other. The host's MAC then gets learned only toward one leaf, traffic from the other is black-holed, and the symptom is exactly "some flows ping, some do not." If LACP shows the bundle as standby on one side, check lacp active, system-ID and ESI parity first.

Layer 3: The IRB Gateway Question

The Juniper community thread about "end hosts cannot ping L3 gateways on spine switches" is its own genre. When routed gateways (IRBs) live on the spines:

  • Every VTEP must map the same VLAN and VNI, and the IRB must sit inside that VLAN or bridge domain.
  • ARP suppression must be enabled consistently — a leaf without it floods ARPs; a mismatch can leave the gateway's ARP entry pointing at a dead path.
  • Verify the host learned the gateway MAC (arp -a on the host) and that the IRB's MAC is identical (anycast) on redundant gateways.
  • From the spine, ping the host's IP and confirm the ARP entry — the community-cited first checks are exactly "MAC learned on the leaf, ARP present on the gateway."

Putting It Together: A Worked Path

  1. Host A pings its own gateway — isolates the local VLAN and IRB.
  2. Host A pings host B — if gateway works but B fails, the problem is east-west overlay.
  3. On leaf1, show evpn database — is B's MAC present via EVPN? If no, the learning path (ESI, VNI, tunnel) is broken.
  4. On leaf2, the mirror check for A's MAC.
  5. show vxlan tunnel between the leaf loopbacks — underlay proof.

Each step eliminates a layer; the first failing step is your fault domain. For building this fabric from scratch, our EX3400 and EX4300 leaf configuration guide gives a complete working baseline, and the multi-vendor EVPN interop guide covers the all-active multihoming details that most often cause the failures above. If the fabric's routing protocol itself is flapping, start with the OSPF ExStart method — underlay stability is overlay stability.