While BGP EVPN provides the control-plane intelligence, the VXLAN (Virtual Extensible LAN, RFC 7348) data plane is what actually transports frames across the IP underlay. A deep understanding of the encapsulation mechanics — from the inner Ethernet frame to the outer UDP/IP header — is essential for MTU planning, hardware offload verification, and troubleshooting silent drops.

The VTEP Encapsulation Pipeline

When a VTEP (VXLAN Tunnel Endpoint) receives a frame from a local server belonging to VNI 100, the hardware ASIC follows a strict pipeline:

1. Ingress Classification: The frame is received on a switchport belonging to VLAN 100. The ASIC tags the frame with the internal VLAN ID and performs a MAC lookup in the VNI 100's MAC table.
2. VNI Mapping: The ASIC maps VLAN 100 to VNI 100 via the VLAN-to-VNI binding table (provisioned by the EVPN control plane via Type-3 routes).
3. Remote MAC Lookup: The destination MAC is looked up in the EVPN MAC table (populated by Type-2 routes). The lookup returns the Remote VTEP IP — the underlay IP of the VTEP owning the destination MAC.
4. Encapsulation: The ASIC prepends the following headers to the original Ethernet frame: outer MAC (underlay next-hop MAC), outer IP (with source = local VTEP IP, destination = remote VTEP IP), outer UDP (port = 4789, source port = hash of inner packet for ECMP entropy), and the VXLAN header (VNI = 100).
5. Underlay Forwarding: The resulting packet — up to 1,550 bytes for a 1,500-byte inner frame — is forwarded through the IP underlay using standard routing.

The sum means a standard 1,514-byte inner Ethernet frame (14-byte header + 1,500-byte payload) becomes a 1,554-byte outer packet on the wire. If the underlay MTU is 1,500 bytes, this packet will be fragmented or dropped. This is why underlay MTU must be set to at least 1,554 bytes (or ideally 1,600 bytes for headroom) on all infrastructure links carrying VXLAN traffic — a fact that is the single most common cause of "black-hole" traffic in new EVPN deployments.

Hardware VTEP Offload: SmartNIC and DPU Integration

In hypervisor environments, the VTEP function can run in software (Open vSwitch kernel module) or be offloaded to a SmartNIC or DPU (Data Processing Unit). NVIDIA's BlueField-3 DPU implements the full VXLAN encapsulation pipeline in hardware, achieving line-rate 200 GbE VTEP performance while consuming zero host CPU cycles. The DPU maintains its own EVPN MAC table (up to 256,000 entries), received from the control-plane agent running on the DPU's embedded Arm core. The host OS is unaware of the VXLAN encapsulation — it sees a standard Ethernet interface with MTU 1,500, while the DPU transparently handles the 50-byte overhead by fragmenting at the hardware level or negotiating a larger MTU with the hypervisor's virtual switch.

In a multi-tenant EVPN fabric, a single BGP session carries routes for potentially hundreds of tenants, each with their own VNI. Without filtering, a tenant in VNI 100 would receive the MAC/IP advertisements of VNI 200, causing the VTEP to install irrelevant MAC entries and waste TCAM space. Route Target (RT) filtering is the EVPN mechanism for scoping route propagation to only the VNIs that a given VTEP participates in.

The Route Target Constraint Mechanism

Each VNI in EVPN is associated with a Route Target (RT) — an extended community attribute (8 bytes: 2-byte Type + 6-byte Value, typically encoded as $\\text{AS}:\\text{ID}$ or $\\text{IP}:\\text{ID}$). The RT is attached to every Type-2, Type-3, and Type-5 route belonging to that VNI. On the receiving VTEP, the BGP process checks each received route's RT against the import RT list configured for each VNI on the local VTEP. If the RT does not match any local VNI, the route is not installed in the Adj-RIB-In — it is discarded before consuming MAC table memory.

This filtering occurs in the BGP control plane, not the data plane. The BGP RT Constraint (RFC 4684) optimization goes a step further: instead of receiving all routes and filtering locally, the VTEP advertises a Route Target Membership NLRI (RTM-NLRI) to its Route Reflector, indicating which RTs it is interested in. The RR then sends only matching routes, reducing the BGP UPDATE rate on each VTEP by 60–90% in a multi-tenant fabric:

The RT Constraint with Multiple Route Reflectors

In a fabric with multiple Route Reflectors for redundancy, each RR independently receives RTM-NLRIs from each VTEP. If an RR does not receive an RTM-NLRI for RT 65000:100 from any client, it drops all routes carrying that RT from its outbound UPDATEs to all clients. This is called RT Pruning and is the mechanism that prevents a VNI configured on only 5 out of 500 leaf switches from wasting BGP processing on the other 495 leaves. Cumulus Networks reported that RT Constraint reduced BGP memory usage by 55% in a 1,000-leaf fabric with 200 distinct VNIs.