VXLAN to MPLS IP VPN: A VNI Is Not an MPLS Label

Both technologies put an identifier in front of the packet, so the conclusion feels obvious: map the VNI to an MPLS label and let the two networks join. That mapping does not exist as a supported operation, because the identifiers mean different things and are produced by different control planes. A VNI identifies a VXLAN segment inside an overlay; an MPLS label identifies a forwarding treatment along a label-switched path. Joining the domains is a routing decision, not a translation of numbers.

The myth: both use labels, so map them

The surface similarity is real and misleading. VXLAN carries a 24-bit VNI in its header, and MPLS carries a stack of labels, so it looks as if one value could be rewritten into the other at a border device.

What breaks the idea is everything around the value. The VNI is resolved by the EVPN control plane and the underlay tunnel endpoints. The label is assigned by the MPLS forwarding plane along a path. Neither side has a defined procedure for accepting the other side identifier as its own.

What each side actually forwards

On the fabric side, a border device terminates the VXLAN tunnel, maps the VNI to a tenant VRF, and routes the packet as ordinary IP. On the provider side, the PE accepts the customer route into a VRF, imposes the MPLS label stack, and forwards it across the IP VPN.

That hand-off is the well-understood model in RFC 4364: the customer edge exchanges IP routes with the provider edge, and each domain owns its own encapsulation. The VNI is gone by the time the packet reaches the PE, which is exactly why the model works.

Why the control planes do not merge

EVPN Type 5 carries IP prefix routes with overlay next hops, while VPN-IPv4 advertisements belong to a different address family. Identical-looking route targets on both sides do not translate one family into the other, and they do not resolve next hops across the boundary.

An integrated gateway can do both jobs only when the platform implements the required encapsulations and the route-family interworking. That capability has to be verified for the exact hardware and release, not inferred from a product family name.

Two more assumptions fail at this boundary. An MPLS IP VPN supplies routed reachability, not an Ethernet segment, so stretching broadcasts requires a supported Layer 2 service instead. And both encapsulations consume bytes, so the effective MTU is smaller than either underlay suggests.

Choose routed hand-off or integrated gateway

Choose the routed hand-off when the tenant needs IP reachability and the provider already offers a CE-facing service. It keeps ownership clean: the fabric owns VXLAN and EVPN, the provider owns MPLS and the VPN, and the border owns the VRF-to-interface mapping. Plan the attachment scale, addressing and failover with the provider rather than assuming a single link is enough.

Choose an integrated gateway only when a platform you operate supports both roles and you can test the interworking. The savings in boxes are real, but so is the operational risk of one device becoming the only place where two control planes must agree.

What to record per tenant

Keep a tenant-specific record with the attachment, the accepted and exported prefixes, the next-hop resolution method and the expected behavior after a border or provider-link failure. Include the MTU budget at both encapsulation boundaries and the return path, because a working forward direction proves very little on its own.

That record is what connects two administrative domains without pretending their routing and encapsulation assumptions are the same. When someone later asks whether the VNI can simply become a label, the document answers with the design instead of an argument.