MPLS Layer 3 VPNs let a service-provider network carry multiple customer routing domains across shared infrastructure while keeping each customer\u2019s routes logically separated. The customer edge router exchanges ordinary IP routes with a provider edge router, while the provider uses VRFs, Multiprotocol BGP, route distinguishers, route targets, and MPLS labels to transport those routes and packets across the core. The customer does not need to participate in the provider\u2019s label distribution.<\/p>\n
The current 300-410 ENARSI<\/a> v1.1 blueprint includes MPLS operations and MPLS Layer 3 VPNs as VPN technologies. Engineers who want deeper service-provider implementation context can also connect the topic to 350-501 SPCOR<\/a> and 300-510 SPRI<\/a>. For ENARSI, the useful goal is to understand how customer routes become VPN routes and how a labeled packet finds the correct VRF at the remote PE.<\/p>\n The provider core first needs an MPLS transport that can carry labeled packets between provider edge routers. An IGP supplies reachability to loopbacks and links, while a label distribution mechanism such as LDP can assign labels to transport prefixes. This creates label-switched paths across P routers that do not need to know customer routes.<\/p>\n The MPLS forwarding model<\/a> is therefore one layer below the VPN. A core P router swaps transport labels based on its label forwarding table. It does not need a VRF for every customer and does not inspect the customer prefix to make the core forwarding decision.<\/p>\n When troubleshooting, prove transport first. If the PE loopbacks cannot reach one another through the provider IGP or labels are missing for the remote PE, VPN route exchange can appear healthy while the data plane fails. A working MP-BGP session does not substitute for a working labeled transport.<\/p>\n A VRF gives the PE a separate routing and forwarding context for a customer. The CE-facing interface is associated with that VRF, and routes learned from the customer are installed in the VRF routing table rather than the global table. Two customers can therefore use overlapping private address space without those routes colliding locally.<\/p>\n The VRF is the local separation mechanism; it does not by itself make a route globally unique in MP-BGP. That is the job of the route distinguisher. Keep those concepts distinct because they solve different problems. A route target then controls which VPN routes are imported into or exported from VRFs.<\/p>\n Operationally, always issue verification commands in the correct VRF context. A route can be present and healthy inside Customer-A while the same prefix is absent from the global table. Many apparent reachability problems come from looking at the wrong routing context.<\/p>\n MP-BGP cannot carry two identical IPv4 prefixes as separate routes unless an additional identifier distinguishes them. The route distinguisher is combined with the customer prefix to form a VPNv4 route that is unique in the provider control plane. Two customers can both advertise 10.10.10.0\/24 because their RDs produce different VPNv4 network-layer reachability information.<\/p>\n An RD does not decide who is allowed to learn the route. That authorization function belongs to route targets. This is one of the most important conceptual distinctions in L3VPN troubleshooting: RD provides uniqueness; RT provides import\/export policy.<\/p>\n Choose a consistent RD convention so operations can infer where a route originated. The actual numeric structure is an administrative choice, but a documented pattern makes MP-BGP output easier to interpret during incidents.<\/p>\n Route targets are extended communities attached to VPN routes. A VRF exports routes with one or more RTs, and other VRFs import routes whose RTs match their import policy. A simple customer VPN can use the same RT for export and import at every site. More complex designs can create hub-and-spoke or shared-services relationships through asymmetric import and export policy.<\/p>\n Because RTs express VPN membership, an incorrect RT can cause either isolation or leakage. A missing import target makes a remote route invisible to the VRF. An overly broad import target can expose routes from the wrong customer or security zone. Treat RT changes as security-sensitive routing changes, not merely reachability tweaks.<\/p>\n When shared services are intentionally leaked between VRFs, document directionality and return routing. A DNS or security service reachable from many customer VRFs needs a return path to those prefixes, but it may not be appropriate for the shared-services VRF to import every customer route indiscriminately.<\/p>\n Route-target policy should be reviewed like firewall policy. A new import target can expose an entire set of prefixes to a VRF in one change. Before implementation, list the routes that will match the target, verify return-path requirements, and confirm that the receiving customer or shared service is authorized to see them. After the change, compare the VRF route count against the expected delta.<\/p>\n Provider edge routers exchange VPN routes using Multiprotocol BGP. The VPNv4 address family carries the RD-qualified prefix and its route-target communities. PE routers import the routes that match local VRF policy and then install usable customer prefixes into the appropriate VRF routing table.<\/p>\nSeparate MPLS transport from the VPN service<\/h3>\n
Use VRFs to create independent customer routing tables on the PE<\/h3>\n
Use route distinguishers to make overlapping prefixes unique<\/h3>\n
Use route targets to build VPN membership and controlled route leaking<\/h3>\n
Use MP-BGP to carry VPNv4 reachability between PE routers<\/h3>\n