MPLS L3VPN is one of the classic Service Provider technologies used to carry multiple customer routing tables across a shared provider backbone. It is still a very useful topic to understand because many modern designs, even when they migrate toward Segment Routing or EVPN, keep the same operational ideas: separation at the edge, transport in the core, and policy-driven route import/export.
This updated article uses ready-made diagrams extracted from a PDF source to test how technical images look on Blogger. More importantly, it walks through the basic building blocks of an MPLS L3VPN service: PE routers, CE routers, VRFs, route distinguishers, route targets, MP-BGP, and label-switched transport.
What MPLS L3VPN Solves
In a traditional routed network, every router that forwards traffic usually needs to understand the destination prefixes. That model does not scale well when a provider must connect many customers, especially when those customers may use overlapping private address ranges. MPLS L3VPN solves this by moving customer routing intelligence to the Provider Edge routers while keeping the Provider core focused on transport.
The customer connects to the provider through a Customer Edge router. The provider terminates that connection on a Provider Edge router. Inside the provider network, P routers switch labeled packets but do not need customer VRF routes. This separation is one of the biggest reasons the design scales.
The Main Roles: CE, PE and P Routers
The diagram shows a typical provider topology with CE routers at the customer side, PE routers at the provider edge, and a provider core between them. The CE router usually runs a routing protocol with the PE router, such as static routing, OSPF, EIGRP, IS-IS, or eBGP. The PE router places the learned customer routes into the correct VRF.
The PE router is the most important device in this architecture. It has two responsibilities at the same time:
- It behaves like a customer-facing router inside each VRF.
- It behaves like a Service Provider backbone router toward other PE routers.
The P router is simpler from the L3VPN point of view. It does not carry customer VRF tables. It only needs enough IGP and label information to forward traffic between PE loopbacks.
Why VRFs Are the Foundation
A VRF, or Virtual Routing and Forwarding instance, is a separate routing table on a PE router. Each customer or service can have its own VRF. This allows two customers to use the same IP prefix without conflict because the prefixes live in different routing contexts.
For example, Customer A and Customer B could both use:
10.10.10.0/24Without VRFs, that would be a routing conflict. With VRFs, each route belongs to a different table, and the PE router knows which interface, route target and VPN label belong to each service.
Route Distinguishers vs Route Targets
Two terms often confuse engineers when learning MPLS L3VPN: Route Distinguisher and Route Target.
A Route Distinguisher makes an IPv4 or IPv6 prefix unique inside MP-BGP. It does not decide where the route should go. It simply turns a normal route into a VPN route by adding uniqueness.
A Route Target controls import and export policy. It decides which VRFs should receive which VPN routes. Route Targets are extended BGP communities and are one of the most important policy mechanisms in MPLS L3VPN.
A simple way to remember it:
- RD makes the route unique.
- RT decides where the route is imported or exported.
How Routes Move Through the Provider Network
When a PE router receives a route from a CE router, it places that route into a VRF. The PE then advertises the route to other PE routers using MP-BGP, usually in the VPNv4 or VPNv6 address family. The route is advertised with additional information such as the Route Distinguisher, Route Target and VPN label.
Another PE router receives the VPN route and checks the Route Target. If the Route Target matches an import policy in one of its VRFs, the route is imported into that VRF. If it does not match, the route is ignored for that VRF.
This is why many MPLS L3VPN troubleshooting cases are really policy cases. The transport may be fine, BGP may be established, and labels may exist, but the route still does not appear in the expected VRF because the import/export policy is wrong.
Transport: LDP, RSVP-TE or Segment Routing
MPLS L3VPN needs a way to transport labeled packets between PE routers. Traditionally this was often done with LDP or RSVP-TE. In newer networks, Segment Routing can provide the transport label stack while the VPN service model remains conceptually similar.
The important operational point is that the PE loopbacks must be reachable through the provider core and must have label reachability. If PE-to-PE transport is broken, VPN routing may look partially correct in the control plane, but traffic forwarding will fail.
Common Troubleshooting Checklist
When an MPLS L3VPN service does not work, I usually think about the problem in layers:
- Underlay reachability: Can PE routers reach each other through the IGP?
- Label transport: Are labels available through LDP, RSVP-TE or Segment Routing?
- MP-BGP: Are VPNv4/VPNv6 sessions established?
- VRF configuration: Is the customer interface in the correct VRF?
- RD/RT policy: Are route targets exported and imported correctly?
- CE-PE routing: Are customer routes learned and advertised as expected?
- Data plane: Do labels and next hops resolve correctly?
This layered approach prevents random troubleshooting. Start with the underlay, then verify labels, then BGP, then VRF policy, and only then focus on the customer edge.
Example Lab Workflow
A good lab can be small. Build two PE routers, one P router and two CE routers. Create a VRF on both PE routers and connect each CE to one PE. Run OSPF or eBGP between CE and PE, enable MP-BGP between PE routers, and provide MPLS transport across the core.
Then test these scenarios:
- Advertise a customer prefix from CE1 and verify that CE2 can reach it.
- Remove the import Route Target on PE2 and observe that the route disappears from the VRF.
- Break LDP or Segment Routing transport and check how the control plane differs from the data plane.
- Use overlapping customer prefixes in two VRFs to confirm route separation.
Design Notes
In production, MPLS L3VPN design should be boring and predictable. Use consistent RD and RT conventions. Document which Route Targets represent which VPNs or services. Keep PE loopback addressing clean. Monitor MP-BGP sessions and label distribution. Most importantly, avoid making the provider core aware of customer routes unless there is a very specific reason.
The best MPLS VPN designs are easy to troubleshoot because the role of every layer is clear: CE-PE routing handles customer adjacency, PE routers handle VRFs and VPN routes, and the core provides stable labeled transport.
Related reading
Summary
MPLS L3VPN is built around a clean separation of responsibilities. The customer routes live in VRFs on PE routers. MP-BGP distributes VPN routes between PE routers. The provider core switches labeled packets and does not need to carry customer routing tables. Once you understand the relationship between VRFs, Route Distinguishers, Route Targets and label transport, the whole architecture becomes much easier to troubleshoot.
Discussion
If you have built MPLS L3VPN labs with LDP, RSVP-TE, or Segment Routing transport, feel free to share which approach was easiest to troubleshoot.
Post a Comment