BGP and MPLS in a VPN: Which Part Carries the Packet

Asking whether a VPN runs on BGP or MPLS mixes two layers into one decision. BGP distributes reachability and policy. MPLS forwards packets using installed label state. In a BGP/MPLS VPN the two cooperate, and removing either one leaves no service at all. The checks below walk the same prefix through both layers, so you can see exactly where yours stopped.

Check 1: is the prefix in the right VRF

Start at the ingress provider edge and ask which VRF the customer prefix belongs to. Overlapping customer addressing is normal in this design, so the VRF is the context that keeps two customers both using 10.0.0.0/8 apart.

If the prefix is missing there, nothing later can be correct, and the remaining checks are wasted effort.

Check 2: was the VPN route distributed and imported

The provider distributes customer routes with MP-BGP. Each route carries a route distinguisher, which makes otherwise identical prefixes unique, and route targets, which decide which VRFs import the route. A route that arrives but is not imported leaves the receiving VRF empty for that prefix. Check the import policy before blaming the far end.

Route selection matters too: a preferred path through a different provider edge replaces the one you expected to see.

Check 3: what the ingress edge does with the packet

When a packet arrives, the ingress edge performs an IP lookup in the VRF and then attaches labels for the chosen path. The stack has two logical roles even when a capture shows a different number of labels.

transport label toward the egress edge
VPN service label for the egress forwarding action
customer IP packet

The BGP/MPLS VPN specification describes that arrangement. Penultimate-hop popping can remove the transport label before the last hop, so a two-label capture taken mid-network is not evidence of a fault.

Check 4: does the underlay forward those labels

Transit routers switch on their installed label entries. They do not read BGP updates to decide what happens to your individual packet. That is why a customer route can be present while forwarding still fails: the resolved next hop or the transport label can break independently. Learning a VPN prefix does not repair the underlay beneath it.

Check the label binding toward the egress edge, not merely the presence of the route.

Check 5: the egress action and the return path

At the egress the service label identifies the forwarding action, the packet is decapsulated, and it proceeds toward the customer destination. From there the return path has to work as well, including the customer-side access policy on that interface.

A one-way success is usually a return route or a filter, not the label stack.

Read your symptom into one of those checks

A route absent from the receiving VRF means advertisement, import policy or route selection. A route present with packets failing means the resolved next hop, the label forwarding or the customer-side return path. Packets arriving with the wrong destination usually mean you are inspecting the wrong VRF. None of these is a reason to change the routing protocol.

One more thing worth stating plainly: this design separates customers and forwards their traffic efficiently. It does not encrypt, and treating it as a confidentiality service is a separate mistake.