L2VPN & VPLS · Chapter 02 of 02

VPLS: The Provider Network as One Big Switch

VPLS extends pseudowires from point-to-point to multipoint: each PE in a VPLS instance holds a virtual switching instance that MAC-learns like a bridge, connected to every other PE by a full mesh of pseudowires, with split horizon over the mesh preventing loops. The provider network behaves as one LAN for the customer — and inherits a LAN's problems at provider scale, which is what EVPN was created to fix.

Updated 31 August 2026 · RST Forum faculty

In this guideShow

The pseudowire connects two sites at layer 2; the obvious customer request is 'now do five sites'. Virtual Private LAN Service is the answer built from the parts already on the bench: give each PE a virtual switching instance (VFI) per customer — a genuine MAC-learning bridge — and join every pair of participating PEs with a pseudowire, forming a full mesh. The customer sees one giant switch; every site is a port on it.

Bridging semantics over the mesh

Each VFI behaves exactly as the switching chapter on the Routing shelf describes: learn source MACs (against attachment circuits or against pseudowires), forward known unicast to the learned port, flood unknown unicast and broadcast — to all local attachment circuits and all pseudowires in the instance. Loop prevention over the mesh does not use spanning tree; it uses the split-horizon rule: a frame received from any pseudowire in the mesh is never forwarded to another pseudowire. In a full mesh this is sufficient — the ingress PE floods to every other PE directly, and no PE relays — so the core runs loop-free with STP kept entirely out of the provider's domain. Hierarchical VPLS (H-VPLS) relaxes the full mesh for scale, with hub-and-spoke pseudowires whose spokes are exempt from split horizon; it saves sessions and creates its own careful failure analysis.

PE1(config)# l2vpn vfi context CUST-A
PE1(config-vfi)# vpn id 100
PE1(config-vfi)# member 10.255.1.4 encapsulation mpls
PE1(config-vfi)# member 10.255.1.5 encapsulation mpls
PE1(config)# bridge-domain 100
PE1(config-bdomain)# member gi0/2 service-instance 100
PE1(config-bdomain)# member vfi CUST-A

Where VPLS hurts

  • MAC scale — every PE learns every host MAC in the customer's network, in the data plane, with flooding as the learning mechanism; a large customer's address churn is the provider's problem now.
  • BUM traffic — broadcast, unknown-unicast and multicast replicate to every PE in the instance over head-end replication: n−1 copies at the ingress, per frame.
  • No all-active multihoming — a site attached to two PEs must block one path or loop; the workarounds are ugly.
  • Signalling — two incompatible camps (targeted-LDP per RFC 4762 versus BGP-signalled per RFC 4761) split vendor support.
  • Convergence — a site move relies on MAC re-learning and flooding to repair the path, not on a control-plane announcement.

EVPN: the successor

Every listed weakness traces to one design choice: MAC learning in the data plane. EVPN (RFC 7432) moves it to the control plane — PEs advertise MAC (and MAC+IP) reachability in a BGP address family, exactly as L3VPN advertises prefixes, with RDs, RTs and route reflectors doing what they already do. The wins fall out naturally: all-active multihoming with ESI-based load-balancing and aliasing, mass-withdraw on failure instead of re-flood-and-relearn, ARP suppression from MAC+IP routes, and one control plane spanning MPLS cores and VXLAN data centres. New multipoint L2 deployments are EVPN by default; VPLS is what you inherit, operate and migrate — so both remain on the syllabus, and on this shelf.

Study VPLS as applied switching: every fault is a bridging fault (where did this MAC get learned? who flooded this?) wrapped in MPLS transport (is the pseudowire mesh complete?). show l2vpn vfi and show bridge-domain answer the first; the previous book's LSP drills answer the second.

Free chapters, real racks, CCIE faculty — that's the whole model.

Browse coursesEnroll