EVPN-VXLAN separates a data-center fabric into an IP underlay and an overlay that can extend Layer 2 and Layer 3 services across that underlay. VXLAN provides the encapsulation and network identifiers used to carry tenant traffic, while EVPN uses BGP to distribute reachability and multihoming information. The current Juniper JNCIP-ENT JN0-650 objectives explicitly include EVPN route types, VXLAN, multihoming, and configuration or troubleshooting on Junos OS v25.2.
The design is easier to troubleshoot when those layers remain separate in the mental model. An underlay problem can break tunnel reachability even when EVPN routes look correct. An EVPN policy problem can leave the underlay completely healthy while tenant MAC or IP reachability fails. A VLAN/VNI mapping error can make both BGP and IP routing look normal while traffic enters the wrong overlay.
The underlay must provide stable VTEP reachability
The underlay is the routed IP network that connects the fabric nodes. Its job is to provide reliable reachability between the addresses used by VXLAN tunnel endpoints. The specific IGP and design vary, but the requirement is simple: every VTEP must be able to reach the other VTEPs over the expected path with the MTU and forwarding behavior required for encapsulated traffic.
That makes underlay validation the first troubleshooting gate. Check loopback or tunnel-endpoint reachability, routing tables, ECMP behavior, physical interfaces, and MTU. If the VTEP address is unreachable, debugging EVPN Type 2 routes is premature.
Encapsulation adds overhead. A path that supports the original tenant frame but not the larger VXLAN packet can create intermittent or size-dependent failures. MTU should therefore be part of design validation, not an afterthought.
VXLAN creates the overlay data plane
VXLAN encapsulates Ethernet frames inside UDP/IP so that Layer 2 segments can span an IP fabric. Each VXLAN Network Identifier, or VNI, separates one logical overlay from another. A VTEP adds and removes the encapsulation at the edge of the fabric.
The mapping between VLANs, bridge domains, VNIs, and routing instances is a frequent source of faults. Two leaves can both advertise EVPN routes while a mismatched VNI prevents them from placing traffic in the same overlay. Troubleshooting should therefore verify not only the presence of the route but the local service mapping attached to it.
VXLAN itself does not tell every VTEP where a remote MAC lives. EVPN supplies that control-plane information so the fabric does not have to depend only on flooding and data-plane learning.
EVPN uses BGP to advertise overlay reachability
EVPN is a BGP address family that carries structured routes describing Ethernet services. Rather than learning every remote endpoint only by seeing frames, VTEPs can advertise reachability through the control plane. That improves scale, convergence, and multihoming behavior.
Route targets determine which EVPN routes are imported into which routing instances. A route can be present in BGP globally but absent from the tenant instance because the import policy or target is wrong. That distinction is critical during troubleshooting.
BGP next-hop resolution also depends on the underlay. A correctly formed EVPN route is not useful if the VTEP next hop cannot be resolved. Overlay and underlay therefore remain separate layers but are operationally dependent.
Tenant isolation also depends on import and export policy. Two EVPN routes can carry identical MAC information but belong to different routing instances because their route targets differ. If a route is visible in the BGP table but never appears in the expected EVPN or bridge context, compare the route distinguisher, route target, and routing-instance policy before changing the access VLAN.
That distinction becomes important in fabrics with many tenants. A broad import policy can leak reachability into the wrong instance, while an overly narrow policy can make a remote endpoint disappear. Control-plane scale does not remove the need for precise service scoping.
Route types tell you what kind of information is missing
EVPN defines several route types, and the current JN0-650 objective specifically expects familiarity with route types such as Types 1, 2, and 3. Type 2 routes advertise MAC and, where applicable, IP reachability. Type 3 routes support inclusive multicast Ethernet-tag behavior used for BUM traffic. Type 1 routes are important in Ethernet-segment and multihoming procedures.
The troubleshooting value is diagnostic. If a remote host is missing, inspect whether the expected Type 2 route exists and is imported into the correct instance. If BUM handling or VTEP membership looks wrong, Type 3 information becomes relevant. If a multihomed Ethernet segment is not behaving as designed, Type 1 and Ethernet-segment state deserve attention.
For multihoming, distinguish Type 1 Ethernet Auto-Discovery routes from the Ethernet Segment route (Type 4) used in Ethernet-segment discovery and designated-forwarder procedures on applicable implementations. Checking only Type 2 MAC advertisements cannot establish that multihomed peers have agreed on an Ethernet segment or its designated-forwarder role. The exact route visibility and operational commands depend on the Junos platform, EVPN service type, and release.
Do not reduce troubleshooting to memorizing numbers. The route type is useful because it tells you which control-plane function should be supplying the missing behavior.
Anycast gateways keep first-hop routing local
EVPN-VXLAN fabrics commonly use a distributed or anycast gateway so hosts can use the same default-gateway address across multiple leaf switches. The leaf that receives the frame can route it locally instead of sending traffic to a centralized first-hop device.
This improves traffic efficiency but increases the importance of consistent gateway configuration. VLAN/VNI associations, IRB interfaces, virtual gateway parameters, and routing-instance membership must agree across the participating leaves. A mismatch can create failures that appear only when a host moves to another rack.
Host mobility should therefore be tested as part of the design. A fabric is not proven simply because one endpoint can reach its gateway from one leaf.
Multihoming adds Ethernet segments and designated-forwarder logic
EVPN multihoming allows a device or downstream network to connect to more than one provider edge or leaf. An Ethernet Segment Identifier identifies the shared segment, and EVPN procedures coordinate reachability, aliasing, split-horizon behavior, and designated-forwarder responsibilities.
The goal is to provide redundancy without allowing duplicate forwarding or loops for BUM traffic. Designated-forwarder election determines which multihomed device forwards certain traffic toward the segment. Failures can therefore involve more than the physical LAG: EVPN control-plane state, ESI consistency, and DF role all matter.
When a dual-homed endpoint works through one leaf but not the other, verify the local link aggregation, ESI, advertised Ethernet-segment routes, DF status, and the remote import of those routes before assuming the endpoint itself is unstable.
BUM traffic exposes control-plane and replication mistakes
Broadcast, unknown-unicast, and multicast traffic cannot always be sent using a single known remote MAC destination. EVPN-VXLAN designs need a mechanism to identify participating VTEPs and replicate BUM traffic appropriately. Type 3 routes are part of that control-plane signaling.
If ordinary known-unicast traffic works but ARP, neighbor discovery, or unknown-destination behavior fails, BUM handling becomes a strong troubleshooting lead. Verify the expected VTEP membership, flood or replication method, and any platform-specific configuration required for the tenant.
Excessive BUM traffic is also a design concern. EVPN reduces dependence on blind data-plane flooding, but poor endpoint learning or incorrect control-plane state can still create unnecessary replication.
Failure symptoms can be mapped to layers. If every tenant between two leaves fails, suspect the underlay, BGP adjacency, or VTEP reachability before checking one VNI. If only one tenant fails, focus on route targets, VNI mappings, and that tenant’s EVPN routes. If only one host fails, compare local learning, Type 2 advertisement, remote import, and endpoint attachment. If known unicast works but discovery fails, investigate BUM signaling and replication.
MAC mobility is another useful clue. EVPN can update reachability when an endpoint moves, but frequent unexpected moves can indicate loops, duplicate addresses, miswired multihoming, or unstable attachment. Operators should investigate the physical cause rather than treating repeated control-plane updates as harmless.
Anycast-gateway troubleshooting similarly benefits from comparison. Verify the gateway MAC and IP presentation on each participating leaf, confirm the host’s local ARP or neighbor state, and test routed reachability from more than one rack. A host that works only when attached to a particular leaf points toward inconsistent local service configuration rather than a general routing failure.
Use a layered troubleshooting workflow
Start with the underlay: physical health, IP reachability, routing, ECMP, and MTU between VTEPs. Next, verify BGP EVPN sessions and address-family state. Then inspect whether the expected route types exist, whether route targets import them into the right instances, and whether next hops resolve. After that, verify local VLAN, bridge-domain, VNI, and IRB mappings.
For a host-specific failure, compare local MAC/IP state with the remote Type 2 route. For multihoming, inspect ESI and DF state. For broadcast or discovery failures, inspect Type 3 and replication. Packet captures on the access and VXLAN-facing sides can confirm whether the problem occurs before encapsulation, across the fabric, or after decapsulation.
Operational verification should preserve before-and-after evidence during changes. Record BGP EVPN neighbor state, route counts, key Type 2 and Type 3 entries, VTEP reachability, and tenant MAC tables before a maintenance event. After the change, compare the same evidence rather than relying on a single successful ping. This is especially important in multihomed fabrics where one path can mask a degraded peer until a later failure.
On a Junos device, begin with the platform’s supported operational views—for example, show bgp summary, show route table bgp.evpn.0, and show evpn database where those tables and commands exist. For a missing host, match its MAC/IP to the imported Type 2 route, its VNI and route target, and the forwarding or bridge entry on both participating leaves. For a multihomed access segment, examine the configured ESI and advertised Ethernet-segment state as well as the designated-forwarder result. These checks are diagnostics to adapt to the deployed release, not a universal command script.
If BGP EVPN is healthy but a remote VXLAN payload disappears, follow one test flow at a time. Confirm the local VLAN/VNI mapping, underlay route to the far VTEP, path MTU sufficient for VXLAN overhead, and remote decapsulation/bridge lookup. Compare small and large packets to uncover encapsulation-related loss; a successful VTEP ping alone does not prove that tenant traffic can cross the complete overlay.
Juniper certifications cover many routing and switching technologies, but EVPN-VXLAN rewards disciplined layering more than command memorization. Prove the underlay first, then the EVPN control plane, then the tenant mapping, and finally the data-plane behavior. That sequence turns a large fabric into a manageable chain of dependencies.