MPLS branch routing: what the CE learns, and from whom

A host at one branch opens a connection to a server at another, and both sites sit behind the same managed MPLS Layer 3 VPN. The host knows its own default gateway and nothing else, which is correct. What matters is that the local customer edge hands the packet toward its provider edge, and the provider's VPN routing state delivers it to the branch that owns the destination prefix.

Walking one packet through the path is the fastest way to see which part is a customer responsibility and which part belongs to the service.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Where each hop's job ends

CE-A needs a route for the remote LAN pointing at its local provider attachment, not at the far branch's WAN address. The provider then carries the packet across its own core using VPN routing state, and CE-B delivers it onto the destination LAN. At no point does a host need to understand labels, VRFs, or the far side's internet circuit.

The mistake that keeps appearing in tickets is configuring Branch B's WAN address as the next hop at Branch A. Both branches bought the same service, so it feels as though they should be neighbours. They are not: a next hop has to be reachable through the routing design you actually have, and the far CE is usually many hops away behind equipment you do not administer. A static route built on that assumption shows up as active and resolves to nothing, which is worse than a missing route because it looks correct in the table.

RFC 4364 separates the exchange between customer and provider edge from the provider's distribution of VPN routes, which is exactly the boundary this runbook is about. The customer's job is to tell its edge what it can deliver and to accept the reachability the service offers back.

What the handoff has to agree on

Pick the mechanism with the provider rather than around them. Static routes, BGP, or a routing protocol arrangement between CE and PE are all legitimate, and OSPF has a defined MPLS VPN model for that handoff. None of those is a reason to build an OSPF adjacency between two remote customer edges across an unspecified provider core, which is a design the provider has not agreed to and cannot support.

Before a new LAN goes live, write down four things: the prefix, the local onward route at the CE, the advertisement the provider will accept, and the routes the provider will return. Add any filtering, prefix limits, or site-to-site restrictions the contract imposes. A healthy adjacency is a channel for exchanging information, and it is not evidence that a particular prefix was accepted; the session can be up while your new subnet sits in a filter.

Then follow the reply. Branch B needs a route back to the source LAN, and the host on the receiving side needs its own gateway and its own service permissions. A route that appears at CE-A establishes half a round trip, and half a round trip is why one direction of a ping test looks healthy while the application still fails.

Verify both handoffs before sign-off

Collect the routing state at both customer edges, confirm with the provider that the intended LAN prefixes were accepted into the VPN, and then test one permitted application in each direction. Route tables alone do not prove the application works, and an application test alone does not tell you which control plane failed when it does not.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Read the three outputs together. The first says what the edge believes, the second says what it learned and from which peer, and the third says what it will actually forward. Disagreement between them is usually a policy or recursion problem rather than a missing advertisement, and it is worth resolving before the provider is asked to investigate. Bring those three outputs to the carrier call, because they answer most of the questions a support engineer would otherwise ask you.

Know what the service does not provide

This is routed Layer 3 access. It is not a Layer 2 circuit extending broadcasts between offices, so discovery protocols, broadcast-dependent applications and shared-segment assumptions do not travel with it. Printing, name browsing and anything that depends on a local segment need their own design.

VPN separation is also not encryption. Label switching keeps customers apart inside the provider's network, and it does not make the payload confidential if the contract requires confidentiality. Where that matters, the application or an overlay has to supply it.

Finally, keep the service model written down next to the site's routing configuration. The next engineer to add a subnet should be able to read which prefixes are advertised, who accepts them, and what the expected return path is: the BGP/MPLS IP VPN specification is the reference for the model behind all of it.