VPLS and Pseudowire L2VPN Configuration Guide

Before VXLAN and EVPN became the default answers for Layer 2 extension, service providers built L2VPNs on MPLS pseudowires: VPWS for point-to-point circuits and VPLS for multipoint bridged LANs. Those technologies are still running a large share of carrier access and mobile backhaul networks, and they behave very differently from an overlay built on EVPN. This article explains the pseudowire model, the two VPLS signalling families (LDP and BGP), the MTU and VLAN pitfalls that break circuits after they are "up", and the commands that actually prove end-to-end forwarding.

The pseudowire concept

CE --- AC --- PE1 ===== PW (MPLS LSP) ===== PE2 --- AC --- CE
AC  = attachment circuit (an Ethernet port or VLAN)
PW  = pseudowire, an emulated wire carried in an MPLS LSP
PE  = provider edge router doing the encapsulation
Labels stacked: LSP label (transport) + VC label (identifies the PW)

The VC label is the entire point: it is what lets the receiving PE map the frame back to the correct attachment circuit. The two signalling families differ only in how that label and the PW identity are exchanged.

Signalling options

Martini / LDP (RFC 4762)
  point-to-point; targeted LDP session between PEs
  simple, no route learning in the core
  every VPLS mesh member needs a full LDP session mesh

Kompella / BGP (RFC 4761)
  auto-discovery via BGP (route targets, sites, label blocks)
  scales better for large VPLS; uses BGP as the control plane
  closer in spirit to today's EVPN model

Modern designs increasingly skip both and use BGP EVPN with a VXLAN or MPLS data plane, which gives MAC learning over the control plane instead of flooding. If you are choosing today, EVPN is the default; if you are operating VPLS, the rest of this article is what you need.

Configuration: LDP-signalled VPLS on Cisco IOS-XR

l2vpn
 bridge group CUSTOMER-A
  bridge-domain 100
   interface GigabitEthernet0/0/0/1.100
   !
   vfi VFI-100
    autodiscovery bgp signaling ldp
    vpn-id 100
    neighbor 10.10.0.22 pw-id 100
    neighbor 10.10.0.23 pw-id 100
   !

Underlying requirements that are easy to forget:

mpls ldp
 interface Loopback0            ! targeted LDP must reach the peer loopback
!
router bgp 65000
 neighbor 10.10.0.22 remote-as 65000
 neighbor 10.10.0.22 update-source Loopback0
 address-family l2vpn
  neighbor 10.10.0.22 activate   ! needed for BGP AD; LDP-only needs the LDP session

Configuration: VPWS (point-to-point pseudowire)

l2vpn
 xconnect group PW-1
  p2p PW-BRANCH-7
   interface GigabitEthernet0/0/0/2.500
   neighbor 10.10.0.22 pw-id 500
  !

VPWS has no MAC learning: it forwards every frame. That makes it ideal for backhaul (mobile, CCTV, proprietary protocols) and makes a misconfigured MTU much more visible, because there is no flooding to hide behind.

MTU: the number one post-up failure

The PW MTU must be smaller than the LSP MTU by the encapsulation overhead:
  customer frame MTU 1500
+  PW/VPLS overhead (12-18 bytes typical)
= core-facing MTU >= 1522 on the transport path
Larger frames are dropped silently at the ingress PE.

Symptoms: ping works (small packets), TCP sessions establish and then hang during large transfers, backups fail. Check the core interface MTU and the underlying physical path, and remember that a VPLS carrying QinQ frames needs additional headroom.

VLAN handling

transparent (raw) mode   full customer frame carried; tags preserved
tagged mode              service provider tags added; see the qinq article
Rewriting:             encapsulation s-vlan / rewrite ingress tag push

Getting VLAN rewriting wrong produces one of three results: customer tags double up, the customer sees your S-VLAN, or frames are dropped. The mechanism is the same as in the QinQ model used by enterprise switches — see QinQ/Dot1q tunnel configuration for the tag-stacking mechanics.

Verification

show l2vpn bridge-domain                      ! bridge state, AC and PW state
show l2vpn bridge-domain bd-name 100 detail   ! per-PW states and labels
show l2vpn xconnect                           ! VPWS state (Up / Down / Standby)
show l2vpn forwarding interface               ! local label, remote label
show mpls ldp neighbor                        ! targeted session up?
ping mpls pseudowire 10.10.0.22 100          ! PW-level OAM
show l2vpn bridge-domain bd-name 100 mac      ! MAC learning (VPLS only)

The decisive pair is "PW state Up" plus "MAC learning present". A PW can be Up with zero MACs when the attachment circuit is misconfigured (wrong VLAN, shutdown port, wrong encapsulation).

Troubleshooting table

Symptom                          Likely cause
PW Down                          targeted LDP session not established
PW Up, no MACs                   AC VLAN mismatch / port down
Small ping OK, big transfer hangs MTU along the LSP path
Redundant PW both forwarding      VFI multi-homing not configured
MAC flapping between PWs          customer loop / duplicate MAC on two sites
Works to one site only            missing neighbor in the VFI mesh

For the underlay, review IOS-XR MPLS LDP configuration and the L3VPN counterpart L3VPN RD/RT design. Ring-based protection underneath a pseudowire service is covered in ERPS/G.8032.

FAQ

Q: VPLS or EVPN? EVPN. VPLS requires flooding for unknown unicast and MAC learning in the data plane; EVPN distributes MACs in BGP and supports all-active multihoming.
Q: Can I run VPLS over an L3VPN? Yes via a hierarchical model, but the label stack grows and MTU headroom shrinks.
Q: Does VPLS support redundancy? BGP-signalled VPLS does (multi-homing with local preference); LDP-signalled VPLS handles it by blocking one PW.

原文链接：https://www.rfc-editor.org/rfc/rfc4761.html