MPLS L3VPN and L2VPN
In one line
Multi-tenant VPNs over a shared MPLS core - L3VPN (routed, per-VRF) and L2VPN (Ethernet / pseudowire).
L3VPN
- VRFs on each PE isolate customer routing tables.
- RD (route distinguisher) makes overlapping prefixes unique; RT (route target) is the import/export policy that controls which VRFs see which routes - RT design is your segmentation and extranet/leaking policy.
- MP-BGP VPNv4/VPNv6 carries the VPN routes; PE-CE runs BGP/OSPF/static.
L2VPN
- VPWS (point-to-point pseudowire), VPLS (multipoint L2), and EVPN (BGP control plane for L2/L3 - see Overlays and BGP EVPN).
- L2TPv3 - the same point-to-point pseudowires over a plain IP core (no MPLS required); the AToM-vs-L2TPv3 fork is decided by what the transport runs, not by the service you need.
Why it matters for design
This is how SPs and large enterprises deliver segmented any-to-any connectivity. The core skill is RD/RT design (uniqueness vs policy) and hub-and-spoke / extranet patterns via RT rewrite.
L3VPN topologies and PE-CE design
Topology models are realised through RT import/export policy: full-mesh (any-to-any - every site imports a common RT), hub-and-spoke (spokes export to a hub RT and import only a hub RT, so there is no direct spoke-to-spoke), multilevel hub-and-spoke, and extranet / shared services (selective RT import to leak a shared-services VRF into customer VRFs). PE-CE routing can be static, BGP, OSPF, EIGRP, or IS-IS. Guard against loops when a site is dual-homed: BGP uses SoO (Site-of-Origin), AS-override, and allowas-in; OSPF uses the domain-ID, down-bit, and sham-links to stop VPN-learned routes from looping or being preferred incorrectly.
VPLS design models
VPLS model selection is driven by scale: the number of VLANs/customers, the number of pseudowires (PWs) between PEs, MAC-table scale, where PWs terminate (N-PE vs U-PE), multihoming (active/active vs active/standby), and the resiliency mechanism (MPLS-TE FRR, redundant PWs).
- Flat VPLS - the classic model: a full mesh of PWs per VPLS instance among all PEs. Simplest, but the full mesh limits scale.
- Hierarchical VPLS (H-VPLS) - a U-PE/N-PE hierarchy so the core mesh is among fewer N-PEs, improving PW scale.
- PBB with H-VPLS - Provider Backbone Bridging adds MAC-in-MAC to hide customer MACs from the core, scaling to very large MAC counts.
This is SP / large-scale L2VPN territory; EVPN (Overlays and BGP EVPN) is the modern replacement.
RD strategy and RR placement
Two quiet choices decide how well a multihomed L3VPN behaves. RD strategy: if a dual-homed site's two PEs use the same RD, both advertisements are the same VPNv4 prefix - a route reflector then picks one best path, and remote PEs never learn the second exit (the VPN flavour of RR path hiding, BGP in enterprise design). Giving each VRF a unique RD per PE makes the two exits distinct VPNv4 prefixes that both survive reflection - restoring ingress-PE load-sharing (ECMP) and immediate failover onto a pre-known second path, with no need for add-paths or shadow RRs. The cost is memory: each prefix is carried once per advertising PE. Distinct prefixes also mean the VRF import policy can rewrite attributes as each path is copied from the remote RD into the local one - a per-VRF policy lever the shared-RD design forfeits. RR placement: keep VPNv4 route reflectors out of the forwarding path - a control-plane-only pair scales BGP without dragging RR CPU/memory into data-plane risk, and placement can then follow the logical topology instead of the traffic. As edge hygiene on a shared PE, cap the blast radius of a misbehaving customer with per-VRF / per-neighbor max-prefix limits (Securing routing protocols), and manage the CE fleet through a dedicated management VPN rather than from inside customer VRFs - one audited reach-everything path instead of per-customer backdoors.
RT-constrained route distribution
Default reflection floods every VPNv4/VPNv6 route to every PE, and each PE discards what no local VRF imports - at scale that is most of the table, paid for in RR replication work and PE churn. RTC (RT-constrained route distribution) turns import policy into signalling: each PE advertises its RT membership as NLRI in a dedicated address family (rt-filter), and the RR converts that membership into a per-PE outbound filter - update volume now scales with what each PE actually imports, not with the table. It is the standard companion to a VPNv4 RR design once route counts reach the millions, and it composes with the max-prefix edge hygiene above rather than replacing it.
VPN label allocation: scale vs convergence vs load-sharing
The egress PE chooses what the service label means, and the choice is a three-way trade. Per-VRF (one aggregate label per VRF): smallest label table, but the label only identifies the VRF, so the PE must run an IP lookup on every packet - and an aggregate label gives PIC no backup rewrite to pre-install, making it the weakest convergence choice. Per-CE (a label per attached next hop): stays label-switched end to end, keeps the table modest, and the backup path is pre-installable - the middle path when BGP PIC matters (Fast convergence techniques). Per-prefix (a label per VPN route): finest load-balancing granularity and PIC-friendly, but the platform's ~1M label space bounds it - it cannot back a full-table VRF. Pick per platform and per VRF by which pressure dominates: label scale, convergence, or load distribution.
Inter-AS L3VPN and Carrier's Carrier
When a VPN spans two ASes (two providers, or two ASes of one), VPNv4 must cross the boundary by one of three inter-AS options. Option A (back-to-back VRF): the two ASBRs face each other with a per-VPN sub-interface and exchange plain IPv4 in each VRF - simplest and most secure (no label trust) but it does not scale (a logical link per VPN). Option B (VPNv4 eBGP): ASBRs exchange labelled VPNv4 over MP-eBGP and swap labels at the border - scales far better, but the ASBRs hold all VPNv4 state and must trust each other's labels. Option C (RR-to-RR with labelled BGP): the ASBRs carry only labelled IPv4 (BGP-LU) for the PE loopbacks while VPNv4 is exchanged multihop between route reflectors - the ASBRs hold no VPN state, so it scales best, but it is the most complex and most trusting. No VRF context at the ASBR also dissolves the per-VPN enforcement point - border QoS, policing, filtering, and accounting per VPN become impossible, one more reason Option C presumes strong inter-AS trust. Carrier's Carrier (CsC) is the related hierarchy: a backbone carrier gives a customer carrier only the labels for its internal/PE routes (labelled BGP or LDP on the PE-CE link), so the customer carrier runs its own VPNs on top without the backbone holding their customer routes - MPLS stacked on MPLS. The border choice also gates customer multicast: Option A needs nothing special (each AS runs its own mVPN, any model, independently), while Options B/C and CsC must make the mVPN tree root reachable across the border - the PIM Vector or mLDP's recursive FEC - Multicast routing design - PIM, RP, MSDP.
Comparison
IPv6 / dual-stack note
6VPE carries VPNv6 over the same MPLS core; design v4 and v6 VRFs together.
Related
Spaced repetition
In MPLS L3VPN, distinguish the jobs of the RD and the RT.
RD makes overlapping prefixes unique (uniqueness); RT is the import/export policy controlling which VRFs receive which routes (segmentation/leaking).
The address family MP-BGP uses to carry IPv4 MPLS-VPN routes is [...] (IPv6 uses [...]).
The address family MP-BGP uses to carry IPv4 MPLS-VPN routes is VPNv4 (IPv6 uses VPNv6 / 6VPE).
VPLS design models from simplest to most scalable?
Flat VPLS (full PW mesh per instance), Hierarchical VPLS/H-VPLS (U-PE/N-PE hierarchy reduces the core mesh), and PBB+H-VPLS (MAC-in-MAC hides customer MACs for huge MAC scale) - EVPN is the modern replacement.
L3VPN topology models, and how they are built?
Full-mesh, hub-and-spoke, multilevel hub-and-spoke, and extranet/shared-services - all realised via route-target import/export policy (RT design is the topology).
PE-CE loop-prevention mechanisms?
BGP - SoO, AS-override, allowas-in; OSPF - domain-ID, down-bit, sham-link (to stop VPN-learned routes looping or being mis-preferred at dual-homed sites).
MPLS L3VPN inter-AS Options A/B/C - the distinction?
A = back-to-back VRF (plain IPv4 per-VPN sub-interface; simplest/most secure, doesn't scale); B = labelled VPNv4 eBGP between ASBRs (scales, ASBRs hold VPNv4 and trust labels); C = VPNv4 multihop RR-to-RR with only labelled IPv4 (BGP-LU) at the ASBRs (scales best, ASBRs hold no VPN state, most complex).
What is Carrier's Carrier (CsC)?
A backbone carrier gives a customer-carrier only the labels for its internal/PE routes (labelled BGP or LDP on the PE-CE link), so the customer-carrier runs its own VPNs on top without the backbone holding their customer routes - MPLS stacked on MPLS.
Why give a dual-homed L3VPN site a unique RD per PE?
With a shared RD the RR reflects only one best VPNv4 path and hides the second exit; unique RDs keep both PE routes distinct so both survive reflection - restoring ingress ECMP and fast failover, at the cost of carrying each prefix once per PE.
What does RT-constrained route distribution (RTC) change in a VPNv4 RR design?
Each PE advertises its RT membership as NLRI (rt-filter AF) and the RR builds a per-PE outbound filter - update volume scales with what each PE imports rather than the whole table; the standard companion to RRs at millions of VPN routes.
Per-VRF vs per-CE vs per-prefix VPN label allocation - the trade?
Per-VRF: one aggregate label, smallest table, but forces an IP lookup and gives PIC no pre-installable backup (weakest convergence). Per-CE: a label per next hop - label-switched, PIC-usable, modest table (the middle path). Per-prefix: finest load-balancing and PIC-usable, but bounded by the ~1M label space.
Sources
- Cisco Live BRKIPM-3017 (CLUS 2019): the inter-AS multicast dimension of Options A/B/C and CsC.
- Cisco Live BRKMPL-2103 (2026): RTC, VPN label-allocation modes, Option-C enforcement gap, unique-RD attribute rewrite, dedicated management VPN.
- Cisco Press, MPLS Fundamentals; Layer 2 VPN Architectures.