VPLS: Layer 2 VPN Over MPLS

L3VPN provides routed connectivity — IP packets forwarded between sites. But sometimes you need Layer 2 — Ethernet frames bridged as if sites were on the same switch. Same broadcast domain, same VLAN, same ARP visibility.

VPLS (Virtual Private LAN Service) provides exactly this. Multiple sites connected via MPLS backbone, appearing as a single Ethernet switch. Frames are encapsulated, labeled, and forwarded. MAC addresses are learned. Broadcast is flooded.

VPLS provides multipoint Layer 2 connectivity over any-to-any MPLS.

VPLS Concepts

What VPLS Does

Without VPLS:
[Site A] ─── separate switches ─── [Site B]
          │                      │
Different Layer 2 domains

With VPLS:
[Site A] ══════ VPLS ══════ [Site B]
          │                │
Same Layer 2 domain (virtual switch)

Components

PE (Provider Edge): Participates in VPLS, bridges customer frames
P (Provider): MPLS core, just label switching
CE (Customer Edge): Regular switch/router, no VPLS awareness
VSI (Virtual Switch Instance): Virtual switch on PE

[CE1] ─ [PE1] ═══════════════════ [PE2] ─ [CE2]
         │        MPLS            │
        VSI ←─ pseudowires ─→ VSI
         │     (label-switched)   │
        [PE3]
         │
        [CE3]

VPLS vs L3VPN

VPLS Signaling

BGP-Based VPLS (RFC 4761)

# Control plane: BGP
# PE routers exchange VPLS membership via BGP
# Auto-discovery of other PEs in same VPLS

LDP-Based VPLS (RFC 4762)

# Control plane: Targeted LDP
# Pseudowires signaled via LDP
# Requires explicit configuration of remote PEs

VPLS on VyOS

VyOS VPLS support depends on version. Basic pseudowire configuration:

Pseudowire Configuration

configure

# Create pseudowire interface
set interfaces pseudo-ethernet peth0 link eth1
set interfaces pseudo-ethernet peth0 mode private

# Note: Full VPLS requires additional configuration
# VyOS may not support complete VPLS feature set

commit

L2TPv3 for L2VPN (Alternative)

VyOS supports L2TPv3 which can provide similar L2 connectivity:

configure

# L2TPv3 tunnel
set interfaces l2tpv3 l2tpeth0 source-address 10.0.0.1
set interfaces l2tpv3 l2tpeth0 remote 10.0.0.2
set interfaces l2tpv3 l2tpeth0 tunnel-id 100
set interfaces l2tpv3 l2tpeth0 peer-tunnel-id 100
set interfaces l2tpv3 l2tpeth0 session-id 100
set interfaces l2tpv3 l2tpeth0 peer-session-id 100
set interfaces l2tpv3 l2tpeth0 encapsulation udp
set interfaces l2tpv3 l2tpeth0 source-port 5000
set interfaces l2tpv3 l2tpeth0 destination-port 5000

# Bridge with local interface
set interfaces bridge br0 member interface l2tpeth0
set interfaces bridge br0 member interface eth1

commit

VPLS Design Considerations

Full Mesh Pseudowires

N PEs requires N×(N-1)/2 pseudowires

3 PEs: 3 pseudowires
5 PEs: 10 pseudowires
10 PEs: 45 pseudowires
20 PEs: 190 pseudowires

Scales poorly!

Hierarchical VPLS (H-VPLS)

Solution: Hub-spoke at access layer

[CE]─[MTU]────[PE-aggregation]═══full-mesh═══[PE-aggregation]────[MTU]─[CE]

MTU = Multi-Tenant Unit (spoke)
PE = Hub, full mesh only between PEs
Reduces pseudowire count

MAC Address Learning

Frame arrives at PE1 from CE1:
- PE1 learns: MAC-A is behind local interface
- PE1 floods to PE2, PE3 (VPLS peers)
- PE2 learns: MAC-A is behind PE1 (pseudowire)

Frame from CE2 to MAC-A:
- PE2 knows MAC-A → pseudowire to PE1
- PE1 knows MAC-A → local interface
- Frame delivered

Unknown Unicast Flooding

Unknown destination MAC:
- PE floods to all pseudowires
- Like a regular switch with unknown MAC
- All PEs receive, only one delivers

Broadcast/Multicast:
- Always flooded to all pseudowires
- Bandwidth consideration!

VPLS Challenges

Split Horizon

Frame received from pseudowire:
- Don't send back to pseudowires
- Only send to local interfaces

Prevents loops in full-mesh VPLS

MAC Table Scaling

Every PE learns MACs from all sites:
- 10 sites × 1000 MACs = 10,000 MACs per PE
- Large deployments can exhaust MAC table

Solution:
- MAC address limits per VPLS
- MAC aging timers
- H-VPLS to contain scope

Spanning Tree

Customer running STP across VPLS:
- VPLS is loop-free (split horizon)
- STP BPDUs still traverse
- Can cause suboptimal paths

Options:
- Disable STP (VPLS handles loops)
- Tunnel STP (let customer manage)

When to Use VPLS

Good Use Cases

• Extending VLANs across WAN
• Data center interconnect (legacy)
• Customers requiring L2 adjacency
• Migration scenarios

Not Ideal For

• New greenfield deployments (use EVPN)
• Very large scale (MAC table limits)
• Multi-homing requirements (EVPN better)

Modern Alternative: EVPN

EVPN provides similar L2 connectivity with:

• Better MAC learning (BGP-based)
• Active-active multi-homing
• Better scalability
• Integrated L2 and L3

VPLS → EVPN migration is common trend
New deployments should consider EVPN first

Troubleshooting VPLS

Pseudowire Not Up

# Check MPLS connectivity
show mpls ldp neighbor
ping <remote-PE-loopback>

# Check pseudowire status
# (command depends on implementation)

MAC Not Learned

# Check MAC table
show bridge fdb

# Verify VLAN tagging matches
show interfaces ethernet eth1

# Capture traffic
sudo tcpdump -i eth1 ether host <mac-address>

Flooding Issues

# Monitor pseudowire traffic
# Excessive flooding = possible MAC learning issue

# Check split horizon
# Packets from pseudowire shouldn't go back to pseudowires

The Lesson

VPLS provides multipoint Layer 2 connectivity over MPLS.

VPLS enables:

• Multiple sites on same Layer 2
• Transparent LAN extension
• Bridge instead of route

Considerations:

• Pseudowire full-mesh scales poorly
• MAC learning at every PE
• Broadcast/unknown flooded everywhere

VyOS VPLS support is limited. For L2 extension:

• Check current VyOS version features
• Consider L2TPv3 as alternative
• Evaluate EVPN for new deployments

VPLS served the industry well, but EVPN is the modern evolution. Understand VPLS concepts — they transfer to EVPN — but default to EVPN for new projects.