L2VPN & VPLS · Chapter 01 of 02

Pseudowires and EoMPLS: Point-to-Point L2VPN

A pseudowire emulates a point-to-point layer-2 circuit over MPLS: the ingress PE takes entire Ethernet frames from an attachment circuit, pushes a pseudowire label (negotiated by targeted LDP between the PE loopbacks) plus a transport label, and the egress PE replays the frames onto the far attachment circuit. The provider moves frames without ever routing the customer's traffic — the customer keeps layer 2 end to end.

Updated 31 August 2026 · RST Forum faculty

In this guideShow
  1. 01Pseudowires and EoMPLS: Point-to-Point L2VPN
  2. 02VPLS: The Provider Network as One Big Switch

L3VPN hands the provider your routing; sometimes that is exactly what you do not want. Two data centres that must share one VLAN for clustering, a customer running their own routing who wants the WAN to be invisible, a non-IP protocol that must cross the country — these need the provider to move frames, not routes. The pseudowire (RFC 4448 for Ethernet) is the unit of that service: a point-to-point emulated circuit over the packet core. The commercial names — EoMPLS, VLL, Virtual Private Wire Service — all describe the same construct.

The mechanism

Each end binds an attachment circuit — a physical port or a specific VLAN — to a pseudowire identified by (peer PE loopback, VC ID). The two PEs open a targeted LDP session (unicast hellos between loopbacks, since they are not adjacent) and exchange VC labels for the circuit, checking that VC ID, pseudowire type and MTU match — an MTU mismatch vetoes the circuit outright. Forwarding then reads exactly like L3VPN with the service swapped: ingress PE receives a customer frame, pushes the VC label, pushes the LDP transport label toward the peer loopback, and the core swaps the top label in blissful ignorance. The egress PE pops, reads the VC label — 'circuit 100, port gi0/2' — and transmits the original frame. No MAC learning, no routing decision, no interpretation: what enters one end exits the other.

PE1(config)# interface gi0/2
PE1(config-if)# xconnect 10.255.1.4 100 encapsulation mpls
PE1# show mpls l2transport vc 100
Local intf Local circuit Dest address VC ID Status
Gi0/2 Ethernet 10.255.1.4 100 UP
PE1# ping mpls pseudowire 10.255.1.4 100

Port mode vs VLAN mode

  • Port mode (type 5) — the whole interface is the circuit; every frame, every VLAN, tagged or not, is transported. The customer can trunk hundreds of VLANs through one pseudowire.
  • VLAN mode (type 4) — one 802.1Q subinterface is the circuit; the provider can sell each VLAN to a different destination from the same physical port, optionally rewriting the tag at the far end.
  • Interworking modes exist for mismatched ends (Ethernet one side, legacy transport the other), but Ethernet–Ethernet is the overwhelming case.

The operational realities

  • MTU is the first fault, always: the core must carry customer frame + 2 labels + any control word; pseudowire MTUs are signalled and must match exactly, and a core link 8 bytes short kills large frames only — the classic 'works until someone transfers a file'.
  • The circuit is transparent to STP, CDP, LACP — which is the point, and the danger: bridge two sites and their spanning trees merge; loop protection becomes a two-site design conversation.
  • Status of the far attachment circuit propagates via LDP status TLVs, so a dead far-end port can (and should) bring the local circuit down rather than blackhole.
  • Redundancy is deliberate, not automatic: backup pseudowires and multi-chassis arrangements exist, but a vanilla xconnect is one circuit with the resilience of its two endpoints.

The pseudowire is the atom of layer-2 services: understand its label negotiation, its MTU discipline and its transparency contract, and VPLS — the next chapter — is revealed as pseudowires assembled into a switch.

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

Browse coursesEnroll