Theoretical foundations and architecture

Data plane security in MPLS L3VPN depends on the absolute logical isolation of VRF forwarding tables. However, human error or loose policy filtering can introduce fatal security vulnerabilities: cross-tenant Route Leaking. Primary failure modes include: 1. Inadvertent Route Target Misconfiguration: an engineer mistakenly configures route-target import 65000:100 inside VRF B, leaking private subnets from Customer A directly into Customer B. 2. Uncontrolled Mutual Redistribution: redistributing between PE-CE protocols (e.g., OSPF into BGP and back into OSPF) without administrative Route Tagging, triggering routing loops and cross-tenant transit. 3. Route Spoofing at CE Boundaries: a multi-homed customer re-advertising external transit routes into the provider. Service providers mitigate this by enforcing strict Route Maps, prefix-list allowlists, and deterministic prefix limits on every customer attachment circuit.

What L3VPN isolation actually guarantees

Per RFC 4364, customer networks are separated by four mechanisms: (1) the forwarding context is selected by the ingress interface, so a packet only reaches the FIB of its own VRF; (2) the Route Distinguisher makes the VPNv4 NLRI unique, so overlapping prefixes do not overwrite each other in BGP; (3) the Route Target decides which routes a VRF exports and imports; (4) in the core the packet carries two labels, and the customer cannot influence either the transport label or the VPN label. The operator may promise a security level comparable to Frame Relay/ATM (RFC 4364, Security Considerations; the threat analysis is RFC 4381), but no more: L3VPN has no data encryption or authentication, and the guarantee holds only as long as the RT/RD policy and the filters at the boundaries are correct.

Where isolation breaks: the list of places

  • Route Target. One extra route-target import (a copied block, a template without the customer substituted) is enough to put foreign routes into a VRF. The RT is the only switch between "isolated" and "visible", so it must be treated as a protected resource: a single RT registry, generation from the customer number, automatic comparison of show output with the registry.
  • Extended communities from the CE. If the PE accepts extended communities on the PE-CE eBGP session, a customer can attach RT:65000:100 to its own prefix; at export the PE adds its own RTs, the foreign one stays, and remote PEs import the prefix into the victim's VRF. That is why extended communities are stripped on ingress from the CE, and policy is built only on RTs assigned by the PE.
  • Shared services (extranet). A shared VRF is a controlled hole in isolation. The rules: each customer exports only published prefixes into the shared VRF and with a dedicated RT (A: 65000:910, B: 65000:920); the shared VRF imports them through an import map/route-policy with a list of permitted prefixes; customers import a single RT 65000:999 from it and only the server prefixes. The shared VRF must not re-export customer routes or act as transit between customers.
  • Overlapping addresses. If A and B both publish 192.168.10.0/24, the shared VRF will choose one path and the server's return traffic goes to the wrong customer. Only unique addresses are published into the shared VRF (a NAT pool, a dedicated /24 from the operator's registry).
  • RD. The RD does not control policy, but the same RD in the VRFs of two different customers turns their prefixes into one NLRI: the RR picks one best path and half of the customers get a foreign next hop. The RD must be unique per (VRF, PE); different RDs for one customer on different PEs also preserve multiple paths on the RR.
  • Limits. A customer with a full Internet table on the PE-CE session exhausts RIB/FIB memory and breaks its neighbours on the PE. The protection is twofold: a route limit per VRF (Cisco: maximum routes, Huawei: routing-table limit, Junos: maximum-prefixes on the table) and max-prefix on the BGP neighbour.

Label spoofing at the CE-PE boundary

A VPN label only has meaning inside the operator's domain. If the PE accepted packets with an MPLS header from the CE, the customer could guess a foreign VPN label (labels come from a small predictable range starting at 16) and send a packet straight into another VRF on the egress PE. The protection: the CE-facing interface does not take part in MPLS forwarding (Cisco: no mpls ip, the interface is absent from show mpls interfaces; Junos: no family mpls and no entry in protocols mpls interface; Huawei: no mpls on the interface), and a labelled packet that arrives on such an interface is dropped. The exceptions are boundaries where labels are accepted on purpose (Inter-AS Option B/C, CSC): there the trust moves to the control plane.

Inter-AS and the trust boundary

  • Option A (back-to-back VRF): the ASBR behaves like a PE and treats the neighbouring AS as a customer: a separate (sub)interface and eBGP per VRF. Isolation is strict and scale is poor; the security is the same as on a PE-CE link.
  • Option B (MP-eBGP VPNv4 between ASBRs): the VPN routes of all customers travel in one session, and the ASBR trusts the neighbour for RT authorship. What is needed: RT filtering (a Cisco ASBR without VRFs drops VPNv4 routes without a matching local RT by default, and no bgp default route-target filter disables this, so on an ASBR the filter is replaced by an explicit policy), RT rewriting when RT namespaces differ, and a prefix limit per neighbour. Labels accepted on the ASBR must have been allocated by that same ASBR; foreign labels with no LFIB entry are dropped.
  • Option C (multihop MP-eBGP between RRs, PE transport /32s in BGP-LU): the ASBR does not see VPN routes, and the trust is the highest. In eBGP-LU only PE/RR loopback /32s are allowed by a prefix-list and labels are accepted only for them; otherwise the neighbouring operator gains access to any internal address.

Verify by behaviour, not just by configuration

Isolation is checked not only by configuration: from VRF A you look for a route towards a B prefix (show ip route vrf A 10.220.0.0 must find nothing except what was published into the shared VRF), you compare the RT lists on the exporting and importing sides (show bgp vpnv4 unicast all <prefix> must contain only the expected RTs) and you watch the route-limit counters. A VRF does not protect the resources of the PE itself: the PE interface address in a customer VRF is reachable by the customer and control-plane load is shared; CoPP, ACLs and uRPF in the next lessons deal with that. A leak into the global table is created by static routes with the global keyword (Cisco ip route vrf A 0.0.0.0 0.0.0.0 ... global) and by imports from a VRF into global: include searching for them in the audit checklist.