What EVPN Adds to a VXLAN Fabric

Start with the two destination questions

A tenant sends an Ethernet frame toward a destination MAC address. If that destination is behind another tunnel endpoint, the ingress needs an association between the tenant destination and the endpoint that can reach it. A VXLAN tunnel endpoint is commonly called a VTEP.

RFC 7365 separates this destination lookup from transport: the ingress identifies the egress endpoint, adds the tunnel information, and intermediate underlay nodes forward using the tunnel destination. The overlay's tenant reachability and the underlay's endpoint reachability answer different questions.

For a buyer, that means a working IP path between two switches cannot by itself establish that either switch knows where a particular tenant destination belongs. Equally, a tenant reachability announcement does not supply the physical path or make that path operational.

References: [EV4][EV1]

VXLAN defines the wrapper and segment context

RFC 7348, published in August 2014, describes a tenant Ethernet frame carried inside VXLAN, UDP and outer IP headers, with an outer Ethernet header on the link. The VXLAN Network Identifier, or VNI, supplies the segment context for the inner frame. Inner tenant MAC addresses serve a different purpose from outer tunnel endpoint IP addresses.

The RFC describes learning the association between an inner source MAC and an outer source IP from received traffic. That learning-based scheme uses multicast for broadcast, unknown-destination and multicast frames. The RFC also recognizes directory-based and other mapping schemes. VXLAN therefore does not require EVPN.

The extra headers enlarge the transported packet; use the linked MTU article for byte-boundary analysis. A VNI identifies a segment, but supplies no complete security guarantee.

References: [EV1]

EVPN supplies remote reachability through BGP

EVPN separates local endpoint learning from remote reachability distribution. A VTEP can learn a tenant MAC from locally received Ethernet traffic, then advertise it through BGP using a MAC/IP Advertisement route. Other participating VTEPs learn remote reachability from that control-plane information. A remote VTEP can learn a destination's location from its advertisement without first receiving a tenant frame sourced by that MAC across the tunnel. Local data-plane learning can therefore coexist with remote learning through BGP.

The route's name does not mean a tenant IP address must always accompany the MAC. RFC 7432 makes that IP field optional. A tenant IP carried there and the BGP next hop have different meanings: the next hop identifies the advertising endpoint, rather than the tenant itself.

RFC 8365 applies EVPN procedures to VXLAN overlays. EVPN also has applications with other tunnel encapsulations, as the introduction to March 2025's RFC 9746 illustrates. An EVPN claim alone does not specify the packet wrapper.

References: [EV2][EV3][EV5]

Follow one fictional frame between A and B

Stipulate two VTEPs, A and B, with symbolic underlay addresses IP-A and IP-B. One tenant segment uses the invented VNI 50100. Tenant MAC M-A is attached locally to A; tenant MAC M-B is attached locally to B. This is a fictional bridged example within one segment, with no tenant routing.

After local learning, B advertises M-B in the appropriate EVPN context with B as the next hop. If A imports the relevant route and installs its forwarding entry, A can associate destination M-B in this segment with VTEP B. A's corresponding advertisement lets B associate remote M-A with A. The association includes the segment context; a bare MAC string is insufficient.

For a frame from M-A to M-B, the inner Ethernet source remains M-A and the inner destination remains M-B. A adds VXLAN with VNI 50100 and outer IP source IP-A and destination IP-B, together with the UDP and link headers. On a routed underlay hop, the outer Ethernet destination identifies the next hop, which need not be B itself. At B, decapsulation and the segment's local forwarding information allow the inner frame to reach M-B. The frame is not carried inside its BGP advertisement.

Now stipulate that B withdraws the M-B advertisement while both VTEPs and every underlay link remain in place. Tenant reachability information has changed without a cable change between A and B. Underlay reachability to IP-B alone cannot restore the missing tenant association. Treatment of subsequent traffic depends on the fabric's supported behavior and policy.

References: [EV1][EV2][EV3][EV4][EV5]

Known unicast is only one traffic case

A MAC/IP Advertisement route concerns endpoint reachability. RFC 8365 separately describes Inclusive Multicast Ethernet Tag, or IMET, routes for discovering participating endpoints and constructing multicast tunnels. Those routes serve a different purpose from announcing that M-B is reachable behind B.

A proposal still needs to explain its handling of broadcast, unknown unicast and multicast traffic, often grouped as BUM. Distributing known MAC reachability does not establish universal elimination of these traffic classes.

References: [EV2]

A learned route is one step before delivery

RFC 7432 explicitly leaves the creation of forwarding state for a remotely learned MAC to the local implementation. Receiving or importing the route is therefore a different state from having a usable forwarding entry.

In the fictional example, seeing B's announcement at A would establish what A learned, not that A delivered M-A's frame. Delivery additionally depends on usable forwarding, endpoint transport and the destination-side disposition. This is why a supplier's statement that routes are present cannot substitute for evidence covering the required traffic path.

The distinction also keeps troubleshooting questions precise: tenant location information can be wrong while the endpoint IP path remains reachable, and the endpoint IP path can fail while previously learned tenant information remains visible.

References: [EV3][EV4]

Ask what combination the proposal actually supports

A switch quote listing EVPN and VXLAN leaves the connection between those capabilities unexplained. RFC 8365 requires compatible encapsulation support between the communicating endpoints. For the intended purchase, ask the network supplier to identify the exact hardware and software releases, applicable vendor support evidence, EVPN functions, VXLAN forwarding behavior and underlay transport assumptions covered by its offer.

Read that response against the desired communication. Who supplies the tenant-to-endpoint association? Which encapsulation carries the frame? What connects the tunnel endpoints? What behavior is proposed when the tenant association changes or the destination is unknown? These questions expose the mechanism behind the two feature names.

The answer should explain the offered implementation and its limitations. Protocol definitions alone cannot approve a hardware/software combination, establish a convergence time or demonstrate an application outcome.

References: [EV2]

Connect the network decision to the physical work

Where the project includes physical connection changes, Leviathan's structured cabling service can discuss routing, dressing, labeling and connection records for the approved endpoints and assemblies. EVPN and underlay design, configuration and operational qualification remain with the appointed network owner.

Use the linked leaf-spine article for translating topology into physical links, and the cable-labeling article for endpoint identities and separation records. The service and project-inquiry links below provide a route to discuss the approved connection plan, materials responsibilities, site constraints and required physical handoff.

References: [L1]