EVPN Explained: A Control Plane for Modern Ethernet VPNs
Ethernet VPN (EVPN) provides a scalable way to distribute Ethernet endpoint reachability through a BGP-based control plane. It allows network devices to learn where remote MAC addresses and, where applicable, associated IP addresses are reachable without relying exclusively on data-plane learning across the entire network.
EVPN is used in service-provider VPNs, data-centre fabrics and data-centre interconnects. It can operate over different transport technologies, including Multiprotocol Label Switching (MPLS) and Virtual Extensible LAN (VXLAN). Understanding EVPN therefore requires separating three related but distinct functions: how endpoint reachability is advertised, how traffic is transported, and how packets are forwarded at the network edge.
MP-BGP EVPN distributes reachability information. MPLS or VXLAN provides the data-plane transport for the service. The underlay provides the connectivity required to reach the relevant provider-edge routers or VXLAN tunnel endpoints. These roles work together, but they are not interchangeable.
Three concepts to understand first
Endpoint reachability
MP-BGP EVPN advertises endpoint information using defined EVPN route types. Remote devices use this information to build the forwarding state needed to reach endpoints across the network.
MPLS or VXLAN
MPLS-based EVPN uses label-based transport, while VXLAN-based EVPN encapsulates Ethernet frames in UDP/IP packets between tunnel endpoints. The choice depends on the network architecture and service.
Multihoming and recovery
EVPN supports defined mechanisms for multihoming, endpoint mobility and efficient forwarding. Correct operation still depends on the topology, configuration, platform support and failure behaviour.
What this guide will help you investigate
This guide moves from the limitations of traditional Layer 2 VPNs to EVPN route distribution, MPLS and VXLAN transport, BGP-based data-centre fabrics, multihoming and operational troubleshooting. Interactive models will help you trace endpoint reachability, compare transport choices and diagnose a missing remote MAC advertisement.
Traditional Layer 2 VPNs: Connecting Ethernet Networks Across a Provider
A Layer 2 VPN allows geographically separated customer networks to communicate as though they share an Ethernet service, even when their traffic crosses a service provider's infrastructure. Before EVPN, providers commonly built these services using technologies such as Virtual Private LAN Service (VPLS), point-to-point pseudowires, and related Ethernet transport mechanisms.
The provider network supplies the connectivity between customer sites. Depending on the service, it may carry traffic between two endpoints or provide multipoint Ethernet connectivity between several locations.
Pseudowires
A pseudowire emulates a Layer 2 connection across a packet network. It is well suited to connecting two endpoints, such as two customer sites, but a service with many sites can require additional service instances and careful provisioning.
VPLS
Virtual Private LAN Service provides multipoint Ethernet connectivity, allowing multiple customer sites to participate in a bridged service. The provider must still handle MAC-address learning, forwarding state, and the distribution of traffic across the service.
Where the traditional model becomes difficult
These technologies can deliver reliable Layer 2 connectivity, but scaling the service introduces operational challenges. The exact limitations depend on the architecture and implementation; they are not identical for every pseudowire or VPLS deployment.
- MAC-address learning: Traditional bridged services often rely on data-plane learning, so the network must learn which customer-facing interface leads to each MAC address.
- Flooding and replication: Unknown unicast, broadcast, and multicast traffic may need to be replicated to multiple service endpoints, increasing the importance of controlling unnecessary traffic.
- Multihoming: Connecting a customer site to multiple provider edges for redundancy can introduce additional requirements for loop prevention, designated forwarding, and consistent forwarding behaviour.
- Service growth: As the number of sites, endpoints, and services increases, provisioning and troubleshooting can become more complex.
- Endpoint mobility: When a device moves between locations, the network must update forwarding information and avoid stale or conflicting reachability state.
A traditional Layer 2 VPN provides the service that carries Ethernet frames. A separate question is how the network learns where MAC addresses are located, distributes that information, and responds when endpoints move or links fail.
Why this led to EVPN
Ethernet VPN (EVPN) introduces a BGP-based control plane for advertising endpoint reachability. Rather than relying solely on data-plane MAC learning to populate forwarding information across the service, EVPN can distribute MAC and associated IP reachability information through Multiprotocol BGP (MP-BGP).
EVPN does not replace every part of the underlying transport. It can operate with MPLS or VXLAN, while the transport carries the encapsulated traffic. This separation between control-plane reachability and data-plane transport is central to understanding the architecture.
Traditional Layer 2 VPNs established the connectivity model. EVPN builds on that model by providing a scalable control plane for endpoint reachability, with support for designs that require mobility, multihoming, and more structured control over forwarding behaviour.
Incident Challenge: The Remote MAC Is Missing
A host behind PE1 cannot reach a host behind PE2. The local MAC is present, but the remote endpoint is missing from the expected forwarding state. Investigate one layer at a time and identify the likely fault.
Remote MAC missing on PE1
Host B is reachable locally from PE2, but PE1 has no expected remote MAC entry for Host B. The cause is not yet confirmed.
Choose your next diagnostic check
Select a check to reveal its result. Start with control-plane evidence before assuming the underlay is broken. This scenario uses a simulated fault; the results are educational, not live device output.
Investigation not started
Choose a diagnostic check above. Each result narrows the fault domain. Use the evidence to distinguish route distribution from transport and forwarding problems.
Root-cause analysis
The simulated fault is an EVPN route-import problem: PE2 learns Host B locally, but the Type 2 MAC/IP Advertisement route is not imported into PE1's relevant EVPN service because the route-target policy does not match the intended service.
Why this fits the evidence: local learning on PE2 is working, while the expected remote MAC route is absent at PE1. A missing route points first toward advertisement, BGP distribution, route-target import policy or route processing—not automatically toward a broken data-plane underlay.
Next actions: verify the advertised Type 2 route, its RD and RT attributes, the receiving PE's import policy, and whether the route is accepted and installed into the correct service.
Illustrative checks — exact syntax varies by vendor 1. Verify EVPN BGP session and received routes 2. Inspect Type 2 MAC/IP route attributes 3. Compare advertised RTs with import RT policy 4. Confirm route acceptance and service installation 5. Re-check remote MAC and end-to-end reachabilityTroubleshooting principle: follow the evidence through local learning → EVPN route distribution and import → overlay/service mapping → underlay reachability → forwarding state. For VXLAN, the underlay must provide VTEP reachability and the network must permit the required encapsulated traffic. For MPLS EVPN, inspect the applicable label-switched transport instead. CLI commands and table names vary by platform.
How Does EVPN Turn Endpoint Learning Into a Scalable Control Plane?
EVPN separates the question of where an endpoint is from the act of forwarding the packet. MP-BGP distributes endpoint reachability information, while an MPLS or VXLAN transport carries the resulting traffic across the network.
Control Plane
EVPN uses BGP as a control plane to distribute endpoint reachability information. The transport beneath it can differ: EVPN can be deployed over MPLS or used with VXLAN in data-center fabrics. The control-plane concept remains distinct from the underlying packet-transport mechanism.
Traditional Layer 2 VPNs: How Does the Service Connect Sites?
Choose a traditional Layer 2 VPN model, then step through a simplified Ethernet forwarding example. Compare a point-to-point pseudowire with a multipoint VPLS service before exploring why EVPN introduced a different control-plane approach.
Point-to-point pseudowire
A Layer 2 service connects Site A directly to Site B through a provider network.
Step 1 — The customer sends an Ethernet frame
Site A sends a frame toward a destination at Site B. The provider edge applies the configured Layer 2 service and determines how to carry the frame across the provider network.
How the EVPN Control Plane Works
EVPN separates endpoint reachability distribution from the transport that carries Ethernet traffic. Using Multiprotocol BGP (MP-BGP), provider edge devices or data-centre VTEPs can advertise information about customer MAC addresses and, where applicable, associated IP addresses. Other participating devices use these advertisements to build the control-plane knowledge needed to make forwarding decisions.
This does not mean all local learning disappears. Devices may still learn endpoints locally, while MP-BGP distributes reachability between participating network nodes. The control plane and the data plane perform related but distinct jobs.
What does an EVPN advertisement tell the network?
EVPN uses specific BGP Network Layer Reachability Information (NLRI) formats called EVPN route types. Each type communicates a different kind of reachability or service information. The receiving device interprets the route in the context of the relevant EVPN instance and its import policies.
MAC/IP Advertisement
Advertises a MAC address and may also include an associated IP address. This is a key route type for communicating endpoint reachability between EVPN nodes.
Inclusive Multicast Ethernet Tag
Identifies participating nodes for a broadcast domain or related EVPN service so that broadcast, unknown-unicast, and multicast traffic can be handled using the applicable replication model.
Ethernet Auto-Discovery
Supports Ethernet-segment and multihoming procedures, including aliasing and mass withdrawal behaviours where applicable to the design.
Ethernet Segment
Advertises Ethernet-segment information used by EVPN multihoming procedures, including discovery of the PEs connected to a shared Ethernet segment.
IP Prefix
Advertises IP prefixes for EVPN integrated routing and bridging designs. It is especially relevant when EVPN is used to distribute Layer 3 reachability.
Type 2 is central to MAC/IP endpoint reachability. Types 1 and 4 support multihoming procedures; Type 3 supports inclusive multicast membership signalling; and Type 5 carries IP-prefix reachability. Type 2 is not a replacement for every other EVPN route type.
Three identifiers and policies to understand
Several BGP attributes and EVPN service fields help keep routes unique and determine where they are imported. They serve different purposes and should not be treated as synonyms.
| Element | Purpose | Engineering question |
|---|---|---|
| Route Distinguisher (RD) | Makes otherwise overlapping VPN route identities distinguishable in BGP. | How can similar prefixes or MAC-related routes remain unique across services? |
| Route Target (RT) | Controls which advertised VPN routes are eligible for import into a service or routing context. | Which EVPN participants should receive this route? |
| Ethernet Tag / service identifiers | Help identify the relevant Ethernet broadcast domain or service context within EVPN NLRI. | Which Ethernet service does this route refer to? |
How does the route become usable for forwarding?
Receiving an EVPN route is not, by itself, the final forwarding action. The device checks route validity and import policy, determines the relevant remote endpoint or service, resolves the required transport reachability, and installs forwarding state as appropriate. The exact processing depends on the EVPN architecture and implementation.
In an EVPN-VXLAN fabric, for example, the remote VTEP must be reachable through the IP underlay before traffic can be encapsulated and sent to it. In an EVPN-MPLS network, the relevant MPLS transport and label forwarding must be available. MP-BGP distributes control-plane information; it does not replace the underlay or transport forwarding system.
EVPN uses MP-BGP to distribute structured endpoint and service reachability. To troubleshoot it effectively, check the advertised route, the RD and RT policy, the EVPN service context, and the transport path separately. A valid BGP advertisement does not guarantee that the data plane can successfully forward the traffic.
How Does EVPN Distribute MAC Reachability?
Follow a host MAC address from local learning to a BGP EVPN advertisement, then see how the remote PE or VTEP uses the imported route to build forwarding state.
Step 1 — Learn the local MAC
The local PE learns a host MAC address from its attached Ethernet segment or bridge domain.
Local learning happens first
PE-A learns the endpoint MAC from the local Ethernet service. EVPN can then advertise that reachability using a Type 2 route. If an IP binding is available and advertised, the route can carry that information too.
A Type 2 route must be accepted by the relevant policy, associated with the correct service, and usable for forwarding. RD values distinguish route identities; route targets govern import and export policy. The example values above are illustrative, not a required configuration.
EVPN over MPLS vs EVPN over VXLAN
Experiment Result
EVPN over MPLS vs EVPN over VXLAN
EVPN is not tied to a single transport technology. The same broad BGP-based control-plane approach can support Ethernet services carried across an MPLS network or across an IP fabric using VXLAN encapsulation. The right choice depends on the network environment, existing infrastructure, operational requirements, and the services being delivered.
MP-BGP EVPN distributes reachability and service information. MPLS or VXLAN carries the encapsulated traffic across the network. The underlay provides the connectivity needed to reach the relevant transport endpoints.
EVPN over MPLS
Commonly used in service-provider and large routed networks where MPLS already provides a transport foundation for VPN services.
- Uses MPLS labels to carry traffic across the provider network.
- Can support multipoint Ethernet services and EVPN integrated routing and bridging designs.
- Fits environments with established MPLS forwarding, traffic-engineering, and operational practices.
- Requires the relevant MPLS transport and label-forwarding state to be working.
EVPN over VXLAN
Widely used in data-centre fabrics where an IP underlay connects Virtual Tunnel Endpoints (VTEPs) and VXLAN carries the Ethernet overlay.
- Encapsulates Ethernet frames in VXLAN over UDP/IP.
- Uses a 24-bit VXLAN Network Identifier (VNI) to identify the overlay segment.
- Supports scalable Layer 2 segments across a routed IP fabric.
- Requires IP reachability between VTEPs and correct overlay configuration.
This is a functional view rather than a strict packet-processing sequence. The control plane and forwarding system interact, but each has distinct responsibilities. A healthy EVPN BGP session alone does not prove that the transport path is usable.
Comparing the design considerations
| Consideration | EVPN over MPLS | EVPN over VXLAN |
|---|---|---|
| Transport | MPLS label-switched transport | VXLAN encapsulation over IP |
| Typical environment | Provider networks and MPLS-based enterprise WANs | Data-centre and campus fabrics built on IP reachability |
| Service identifier | Depends on the EVPN service and MPLS label allocation | VNI identifies the VXLAN overlay segment |
| Key transport dependency | MPLS forwarding and required label reachability | IP reachability between VTEPs and correct VXLAN configuration |
| Operational focus | EVPN routes, labels, provider transport and service configuration | EVPN routes, VTEP reachability, VNI mapping and IP underlay |
How to choose between them
If a provider already operates an MPLS network, EVPN over MPLS can extend established transport capabilities with EVPN's control-plane model. If a data centre is built around a routed IP fabric, EVPN over VXLAN can provide Ethernet overlay services without requiring MPLS in the underlay.
Neither option is universally superior. Consider scale, existing routing and transport infrastructure, multihoming requirements, operations tooling, hardware support, and the team's ability to troubleshoot both the control plane and the forwarding path.
When troubleshooting EVPN, verify the layers independently: confirm that the EVPN route is present and imported, then check the transport and underlay needed to reach the remote endpoint. A control-plane success and a data-plane success are related, but they are not the same test.
EVPN Transport Lab: MPLS or VXLAN?
The EVPN control plane can advertise endpoint reachability over different transport architectures. Switch the transport model and trace how a customer Ethernet frame crosses the network.
Step 1 — EVPN provides endpoint reachability
MP-BGP EVPN distributes the remote MAC reachability needed by the service.
Step 1 — EVPN provides endpoint reachability
MP-BGP EVPN advertises the remote endpoint’s reachability. The receiving edge uses that information to select the service and forwarding next hop. EVPN is the control plane, not the transport itself.
Both designs can use MP-BGP EVPN. MPLS carries traffic using labels; VXLAN encapsulates an inner Ethernet frame in VXLAN over UDP/IP between VTEPs. The underlay must support the selected transport, and the service and forwarding configuration must agree at both ends.
BGP, VXLAN and Modern Data-Centre Fabrics
Modern data-centre networks often combine a routed IP underlay with an Ethernet overlay. In an EVPN-VXLAN fabric, the underlay provides IP connectivity between network devices, VXLAN carries overlay Ethernet frames, and MP-BGP EVPN distributes endpoint and service reachability. Keeping these roles separate makes the architecture easier to design, operate and troubleshoot.
This is a functional model, not a strict sequence in which one layer operates only after another. BGP control-plane information, overlay forwarding state and underlay routing work together, but a fault in one layer can produce symptoms in another.
1. The underlay: a routed IP foundation
The underlay is the network of physical links and routed interfaces that connects the fabric devices. It is commonly built using Layer 3 links and an interior gateway protocol such as OSPF or IS-IS, or using BGP in designs that use BGP for underlay routing. The protocol choice depends on the architecture.
Route between VTEPs
The underlay must provide a working IP path to the remote VTEP address. If that destination is unreachable, correctly advertised EVPN information may still fail to deliver user traffic.
ECMP and alternate paths
Equal-Cost Multipath (ECMP) can allow traffic to use multiple eligible paths through the routed fabric. Its operation depends on the routing design, topology, hashing and device capabilities.
2. The overlay: VTEPs and VXLAN
A Virtual Tunnel Endpoint (VTEP) performs VXLAN encapsulation and decapsulation. When a host sends an Ethernet frame to a remote endpoint, the ingress VTEP maps the frame to the appropriate overlay service and encapsulates it in VXLAN over UDP/IP. The outer IP header identifies the destination VTEP.
The routed underlay forwards the encapsulated packet to that destination. The receiving VTEP removes the outer encapsulation and forwards the original Ethernet frame within the destination service.
The 24-bit VXLAN Network Identifier distinguishes overlay segments. It is not an IP address, a BGP autonomous system number, or a replacement for an EVPN route. The VNI must be mapped consistently to the intended service at the relevant VTEPs.
3. MP-BGP EVPN: distributing endpoint reachability
EVPN allows participating nodes to advertise endpoint information through BGP. For example, an EVPN Type 2 route can advertise a host's MAC address and may include its IP address. Remote devices process the route according to their EVPN configuration and policy, then build the forwarding state needed for the service.
This provides a control-plane alternative to relying exclusively on data-plane MAC learning across the fabric. It can improve endpoint discovery and mobility handling, but local learning, broadcast traffic and other data-plane behaviours still depend on the design.
Following one packet across the fabric
MP-BGP EVPN helps distribute the reachability used to build forwarding state. The actual packet is transported by VXLAN over the routed underlay; it is not carried inside the BGP update itself.
Endpoint mobility and flooding
When a host moves to another attachment point, the network needs to update its reachability information. EVPN advertisements can help remote nodes learn the new location, while implementation-specific mechanisms and policy determine how competing or stale information is handled.
EVPN can also reduce dependence on flood-and-learn behaviour by distributing endpoint information through the control plane. However, broadcast, unknown-unicast and multicast (BUM) traffic may still require replication according to the service and replication model. EVPN does not eliminate all flooding in every deployment.
What to check when traffic fails
| Layer | Questions to investigate |
|---|---|
| EVPN control plane | Is the BGP EVPN session established? Is the expected route advertised, received and imported into the correct service? |
| Overlay configuration | Does the endpoint have the expected forwarding entry? Are the VNI, bridge-domain or service mappings correct? |
| VTEP reachability | Can the ingress VTEP reach the remote VTEP address using the expected source and routing context? |
| Underlay forwarding | Are the relevant routes, next hops, interfaces and ECMP paths healthy? Are MTU and encapsulation requirements satisfied? |
| Host and gateway | Are the endpoint's VLAN or access-port settings, gateway behaviour, MAC learning and IP configuration correct? |
An EVPN-VXLAN fabric has three distinct concerns: BGP distributes reachability, VXLAN carries overlay Ethernet frames, and the IP underlay transports the encapsulated packets. Troubleshoot each layer independently before concluding that the entire fabric or control plane is faulty.
Inside a VXLAN EVPN Fabric
Inspect the control plane, overlay and underlay separately. Then introduce a fault and identify which layer to investigate first.
Two endpoints, two VTEPs
Dashed purple links represent EVPN control-plane exchange.
Control plane
MP-BGP EVPN distributes endpoint reachability so a VTEP can learn how to reach remote MAC addresses.
Engineering principle
A working BGP session alone does not prove that the required EVPN route has been advertised, imported and installed for forwarding.
2 · Fabric fault challenge
Choose a symptom and identify the most relevant first checks.
Check the MP-BGP EVPN session, confirm the remote Type 2 MAC/IP Advertisement route exists, and verify route-target import policy and forwarding installation.
For a missing remote MAC, begin with EVPN route distribution and import. For an unreachable VTEP, inspect the routed underlay. For a VNI mismatch, compare service mappings at both ends. For large packets that fail, investigate end-to-end MTU and encapsulation overhead. These are starting points, not proof of a single root cause.
EVPN Multihoming and Resilience
Multihoming connects a customer device or Ethernet segment to more than one provider edge (PE) device. The goal is to maintain connectivity if a link or network device fails, and, where the design supports it, to use multiple attachment paths for forwarding. EVPN defines control-plane procedures that help participating PEs coordinate this behaviour without treating every redundant connection as an unrelated Ethernet service.
In EVPN, the shared attachment is represented by an Ethernet Segment (ES), identified by an Ethernet Segment Identifier (ESI). The participating PEs exchange EVPN information to support multihoming functions such as designated-forwarder election, aliasing where applicable, and withdrawal of reachability after failures.
Single-active and all-active multihoming
EVPN supports different multihoming modes. The appropriate mode depends on the service, the customer-facing technology, the platform capabilities and the desired traffic behaviour.
One active forwarder
For a given Ethernet segment and service, one PE forwards traffic toward the multihomed segment at a time under the applicable forwarding procedures. Another PE can take over when the active path fails. This can simplify certain forwarding and loop-prevention requirements, but it does not mean that only one PE is involved in every direction or every aspect of the service.
Multiple active paths
Multiple PEs can forward traffic to and from the multihomed segment, subject to the service and platform design. EVPN procedures help remote devices use eligible paths and reduce unnecessary disruption when an attachment or PE fails.
All-active describes the availability of multiple forwarding paths. Actual traffic distribution depends on forwarding state, hashing, service configuration and platform behaviour. EVPN also uses split-horizon procedures to help prevent traffic from looping back toward the same multihomed Ethernet segment.
The role of the Designated Forwarder
For a given Ethernet segment and Ethernet tag or service context, EVPN elects a Designated Forwarder (DF) among the participating PEs. The DF is responsible for forwarding certain traffic, particularly relevant BUM traffic from the provider network toward the multihomed Ethernet segment, according to the applicable procedures.
DF election is not a universal rule that only one PE may forward all traffic. In all-active designs, multiple PEs may forward eligible known unicast traffic, while the DF role helps coordinate traffic such as broadcast, unknown unicast and multicast toward the segment.
How EVPN responds to failures
| Failure or event | EVPN mechanism or design consideration | What to verify |
|---|---|---|
| Customer-facing link fails | Local detection and Ethernet Segment state can trigger relevant reachability updates. | Link state, ESI membership, local service state and route withdrawal. |
| A PE becomes unavailable | Other participating PEs may continue forwarding; mass-withdrawal procedures can help remote nodes remove affected reachability efficiently. | BGP session state, Ethernet Segment routes and remote forwarding entries. |
| Remote endpoint is reachable through multiple PEs | Aliasing may allow traffic to use eligible PEs advertising reachability for the same multihomed Ethernet segment. | Type 1 routes, ESI consistency, forwarding next hops and platform support. |
| BUM traffic reaches the segment | DF election and split-horizon procedures help coordinate forwarding and prevent loops. | DF state, service context, replication behaviour and duplicate traffic symptoms. |
Why Ethernet Segment routes matter
EVPN route types provide the information needed for multihoming. Type 4 Ethernet Segment routes support discovery of PEs attached to the same Ethernet segment and contribute to DF election. Type 1 Ethernet Auto-Discovery routes support procedures including aliasing and mass withdrawal, depending on the route form and deployment.
These mechanisms work together with the Ethernet Segment Identifier and the service configuration. If the ESI is inconsistent, a route is missing, or the PEs disagree about the segment, expected redundancy behaviour may not occur.
Designing for predictable recovery
Redundancy should be tested rather than assumed. A resilient design considers link failure, PE failure, BGP session loss, forwarding convergence, traffic duplication, and the effect of failures on both unicast and BUM traffic. Recovery times depend on failure detection, routing and EVPN convergence, hardware programming, and the service configuration.
EVPN multihoming combines Ethernet Segment identification, route exchange, DF election and forwarding procedures to coordinate redundant attachments. When investigating a failure, verify the ESI, Type 1 and Type 4 routes, DF state, BGP health and actual forwarding behaviour. The presence of two physical links alone does not guarantee resilient service.
EVPN Multihoming: Explore Resilience
Connect one Ethernet Segment to two Provider Edge routers. Change the multihoming mode, inspect the Designated Forwarder role, and simulate a PE failure to see how forwarding responsibilities can change.
All-active multihoming
Both PE1 and PE2 can forward eligible traffic for the Ethernet Segment. EVPN procedures help coordinate reachability and prevent loops; the exact forwarding behaviour depends on the service and implementation.
Engineering observation
All-active is not the same as sending every frame twice. DF election coordinates relevant BUM forwarding toward the segment, while known-unicast forwarding and load-sharing depend on the EVPN design.
Troubleshooting EVPN: Trace the Failure by Layer
When a remote endpoint becomes unreachable, the cause may sit in the EVPN control plane, the overlay service, the transport underlay or the multihoming design. A structured investigation helps isolate the fault instead of treating every symptom as a BGP problem.
Start with the observed failure, identify which forwarding or control-plane state is missing, and then test the relevant dependency. Avoid changing several layers at once: each check should narrow the fault domain.
First principle: establish the scope. Determine whether the problem affects one endpoint, one bridge domain or VNI, one PE/VTEP, one direction, or the entire EVPN service. The scope is often the first clue to the failing component.
A step-by-step investigation
Follow the path from the local attachment through route distribution to remote forwarding.
Confirm the local endpoint and service mapping
Check the access interface, VLAN, bridge domain and local MAC table. Verify that the endpoint is learned on the expected attachment and that the local service is mapped to the intended EVPN instance or VNI. If local learning is wrong, remote route checks may be premature.
Verify the EVPN control-plane session
Confirm that the relevant BGP session is established and that the EVPN address family is enabled and exchanging routes. A session can be established while the required address family, neighbor policy or route exchange is still incorrect.
Trace the advertised and imported EVPN route
For a missing remote MAC, inspect the Type 2 MAC/IP Advertisement route. Check the advertised MAC and optional IP binding, route next hop, route target import/export policy and relevant route distinguisher. Confirm the route is both received and eligible for installation—not merely present on a peer.
Check the overlay service and forwarding state
Verify that the remote MAC is installed in the expected bridge or forwarding table, and that the correct VNI or service identifier is associated with it. For VXLAN, confirm the remote VTEP and encapsulation parameters. For MPLS, confirm the expected service and transport labels are programmed.
Validate the transport underlay
For VXLAN, test IP reachability between VTEPs, inspect routing and ECMP, and check MTU and any ACL or firewall rules affecting VXLAN traffic (commonly UDP port 4789). For MPLS, verify the label-switched transport path and reachability to the relevant provider edge.
Investigate multihoming when the service uses an Ethernet Segment
Check the Ethernet Segment Identifier (ESI), Ethernet Auto-Discovery routes (Type 1), Ethernet Segment routes (Type 4), Designated Forwarder election where applicable, and the expected aliasing or mass-withdrawal behavior. After a failure, confirm that stale paths have been withdrawn and forwarding has converged.
Separate known-unicast failures from BUM behavior
Test a destination with a known remote MAC separately from broadcast, unknown-unicast and multicast traffic. If known unicast works but BUM traffic fails, focus on replication, multicast or ingress-replication configuration and the relevant Type 3 routes—not only Type 2 endpoint routes.
Symptom-to-check reference
Use the observed behavior to prioritize the next verification step.
| Observed symptom | First checks | Likely fault area |
|---|---|---|
| Remote MAC is missing | Local MAC learning, Type 2 route advertisement and receipt, RT policy, route installation | Endpoint learning or EVPN control plane |
| Remote MAC exists, but traffic fails | Forwarding entry, service/VNI mapping, remote next hop, VTEP or label reachability | Overlay forwarding or transport |
| One direction works only | Reverse route, return-path forwarding, asymmetric policy, MTU and packet drops | Return path or directional configuration |
| Known unicast works; BUM fails | Type 3 routes, replication mode, multicast state and service membership | BUM replication and distribution |
| Traffic fails after a link or PE failure | ESI state, Type 1/Type 4 routes, DF state where applicable, withdrawal and convergence | Multihoming or failure recovery |
| Intermittent loss or unexpected flooding | MAC movement, duplicate endpoint learning, route churn, service mapping and replication | Endpoint mobility or inconsistent state |
Keep the fault domains separate
EVPN troubleshooting becomes clearer when each layer is checked for the state it owns.
BGP session, EVPN address family, route advertisement, route import policy and best-path selection.
Bridge domain, VNI or service identifier, MAC/IP state, replication and forwarding entries.
IP reachability and MTU for VXLAN, or label-switched reachability for MPLS transport.
Ethernet Segment state, DF election, path withdrawal and convergence after failure.
Control-plane reachability is only one dependency. A route may be absent, rejected by policy, not installed in forwarding, mapped to the wrong service, or point to an unreachable transport next hop.
Trace the failure from the endpoint outward: local learning → EVPN route exchange → remote forwarding state → overlay mapping → transport reachability. If multihoming is involved, verify the Ethernet Segment state and recovery behavior as a separate step. Use vendor-specific commands to validate each state, then change only the layer supported by the evidence.