EVPN-VPWS on Juniper MX480: Virtualizing Cross-Connects and Carrier P2P Circuits

Introduction

Service providers and large enterprises have relied on point-to-point (P2P) circuits for decades — TDM leased lines, ATM/Frame Relay PVCs, and later Ethernet cross-connects delivered over MPLS with technologies like l2circuit and legacy pseudowires. These services are simple in concept: connect port A on PE-1 to port B on PE-2 and make it look like a single wire.

EVPN-VPWS (Ethernet VPN – Virtual Private Wire Service) is the modern, standards-based way to deliver that same experience, but built on top of BGP EVPN signaling instead of LDP or static pseudowire configuration. On a platform like the Juniper MX480, EVPN-VPWS lets you virtualize carrier-grade P2P circuits and cross-connects while inheriting all the operational benefits of an EVPN/MPLS control plane: fast convergence, native multihoming, and a single signaling framework shared with EVPN-VPLS and EVPN-VXLAN.

This post covers what EVPN-VPWS is, the problems it solves, how to configure it between two PEs on Junos, how to verify the service, and RD/RT best practices to keep your deployment scalable and easy to troubleshoot.

What Is EVPN-VPWS?

EVPN-VPWS is a P2P Layer 2 VPN service defined in RFC 8214. It uses the EVPN BGP control plane (originally built for RFC 7432 multipoint EVPN) to signal single, point-to-point Ethernet circuits between two PEs.

Key characteristics:

• Point-to-point only — unlike EVPN-VPLS or EVPN-ELAN services, VPWS connects exactly two attachment circuits (ACs). There’s no MAC learning, no flooding, and no broadcast domain to manage.
• BGP-signaled — instead of a dedicated pseudowire signaling protocol (like LDP for classic L2 circuits), EVPN-VPWS reuses BGP EVPN NLRI (specifically the EVPN Ethernet A-D route, type 1) carrying a VPWS Service Instance Identifier rather than a MAC/IP.
• MPLS-based transport — the actual data plane still rides over an MPLS LSP (RSVP-TE, SR-MPLS, or LDP) between the PE loopbacks, exactly like a traditional pseudowire.
• Local and remote Service IDs — each PE advertises a local VPWS Service ID and imports the peer’s remote Service ID to build the cross-connect. This replaces the manual VC-ID matching used in classic l2circuit configuration.

In short: EVPN-VPWS is “pseudowire signaling done the EVPN way” — same forwarding plane, more modern and extensible control plane.

What Problem Does It Solve?

Traditional L2VPN/pseudowire technologies (Martini-style l2circuit, VPLS with LDP signaling) have real operational limitations that EVPN-VPWS directly addresses:

Where it’s used in practice:

• Carrier Ethernet / cross-connect virtualization — replacing physical cross-connects or legacy TDM circuits with virtual, MPLS-transported P2P Ethernet services.
• Cell site backhaul — point-to-point EVPN-VPWS circuits from cell sites back to aggregation/core PEs.
• Enterprise/carrier P2P E-Line services — MEF E-Line equivalents delivered over an MPLS/SR core.
• Multihomed access — connecting a CE device to two PEs (dual-homed) with active/active forwarding for resiliency, without STP.

Core Building Blocks

Before configuring, it helps to understand the pieces involved:

• Routing instance type evpn-vpws — a dedicated instance type on Junos purpose-built for this service (distinct from evpn used for VPLS-style bridging).
• Route Distinguisher (RD) — makes the route unique in the BGP table (per PE, per instance).
• Route Target (RT) / vrf-target — controls import/export so the correct PEs exchange routes for this specific service.
• Local / Remote VPWS Service ID — the equivalent of the old VC-ID; the local ID on PE-1 must match the remote ID configured on PE-2, and vice versa.
• Attachment Circuit (AC) — the customer-facing interface/subinterface bound into the routing instance.
• Underlay MPLS LSP — RSVP-TE, LDP, or SR-MPLS between PE loopbacks; EVPN-VPWS rides on top of this, it doesn’t replace it.

Configuring EVPN-VPWS Between Two PEs (Junos)

The topology: PE-1 and PE-2, each with a customer-facing interface, connected across an MPLS core with iBGP already established between their loopbacks.

1. BGP Control Plane (Both PEs)

Enable the EVPN signaling address family on your existing iBGP group:

set protocols bgp group IBGP-CORE family evpn signaling

This assumes RSVP-TE/LDP/SR-MPLS and iBGP peering (typically via a route reflector) are already up between the two PE loopbacks — EVPN-VPWS only adds the signaling family, it doesn’t replace your existing MPLS underlay.

2. PE-1 Configuration

# 1. Configure the customer-facing interface
#    (flexible-vlan-tagging allows untagged, tagged, or QinQ)
set interfaces ge-0/0/1 flexible-vlan-tagging
set interfaces ge-0/0/1 encapsulation flexible-ethernet-services
set interfaces ge-0/0/1 unit 100 encapsulation vlan-vpls
set interfaces ge-0/0/1 unit 100 vlan-id 100

# 2. Create the EVPN-VPWS routing instance
set routing-instances EVPN-P2P-VPWS instance-type evpn-vpws
set routing-instances EVPN-P2P-VPWS route-distinguisher 192.0.2.1:100
set routing-instances EVPN-P2P-VPWS vrf-target target:64512:100

# 3. Bind the interface and configure the VPWS cross-connect IDs
set routing-instances EVPN-P2P-VPWS protocols evpn interface ge-0/0/1.100
set routing-instances EVPN-P2P-VPWS protocols evpn vpws-service-id local-vpws-service-id 101
set routing-instances EVPN-P2P-VPWS protocols evpn vpws-service-id remote-vpws-service-id 102

3. PE-2 Configuration

Mirrors PE-1, with a distinct RD and the local/remote Service IDs swapped:

# 1. Configure the customer-facing interface
set interfaces ge-0/0/1 flexible-vlan-tagging
set interfaces ge-0/0/1 encapsulation flexible-ethernet-services
set interfaces ge-0/0/1 unit 100 encapsulation vlan-vpls
set interfaces ge-0/0/1 unit 100 vlan-id 100

# 2. Create the EVPN-VPWS routing instance (matching RT, distinct RD)
set routing-instances EVPN-P2P-VPWS instance-type evpn-vpws
set routing-instances EVPN-P2P-VPWS route-distinguisher 192.0.2.2:100
set routing-instances EVPN-P2P-VPWS vrf-target target:64512:100

# 3. Bind the interface and swap the Service IDs
set routing-instances EVPN-P2P-VPWS protocols evpn interface ge-0/0/1.100
set routing-instances EVPN-P2P-VPWS protocols evpn vpws-service-id local-vpws-service-id 102
set routing-instances EVPN-P2P-VPWS protocols evpn vpws-service-id remote-vpws-service-id 101

Note: The RD must be unique per PE. The RT must match across both PEs so the routes are imported into each other’s instance. The local Service ID on one PE must equal the remote Service ID on the other — this pairing is what “stitches” the P2P circuit together.

Verification

Run these operational commands on both PEs to confirm control-plane and data-plane state:

Check EVPN-VPWS instance status:

show evpn vpws instance EVPN-P2P-VPWS

Look for the status to show Up.

Check the EVPN database:

show evpn database instance EVPN-P2P-VPWS

Verify BGP EVPN routes are being exchanged:

show route table EVPN-P2P-VPWS.evpn.0

Additional checks worth adding to your runbook:

show route advertising-protocol bgp <peer-loopback> table EVPN-P2P-VPWS.evpn.0
show mpls lsp extensive
show interfaces ge-0/0/1.100 extensive

A healthy service shows the local Ethernet A-D route advertised, the remote route received and imported (matching RT), and the instance/interface both reporting Up.

RD and RT Best Practices

Getting Route Distinguisher and Route Target design right early prevents scaling pain and troubleshooting headaches later — this applies to EVPN-VPWS just as much as to L3VPN or EVPN-VPLS.

Route Distinguisher (RD)

The RD’s only job is to make a route unique in the BGP table. It has no bearing on routing policy.

• Format: [Loopback-IP]:[Unique-ID] (Type 1 RD)
• Example: PE-1 loopback 192.0.2.1, service/VLAN 100 → 192.0.2.1:100

Why this format:

• Guaranteed uniqueness — every PE loopback is already unique in the AS, so the RD is automatically unique network-wide.
• Faster troubleshooting — looking at show route table bgp.evpn.0, the RD alone tells you which PE originated the route.
• Route reflector friendliness — unique RDs prevent RRs from discarding alternate paths to the same service, which matters for multipathing and fast convergence.

Route Target (RT)

The RT is an extended community that controls import/export policy — which PEs accept which routes.

• Format: [AS-Number]:[Service-ID/VNI] (Type 0 or Type 2 RT)
• 2-byte AS example: AS 64512, service ID 100 → target:64512:100
• 4-byte AS example: AS 4200000100, service ID 5000 → target:4200000100:5000

Why this format:

• Simple import/export — for a P2P VPWS instance (or a full-mesh EVPN environment), matching RTs across PEs let you use the vrf-target shortcut in Junos instead of separate import/export policies.
• Self-documenting network — tying the trailing number to your internal Service ID/VLAN/VNI makes configs and BGP tables readable at a glance, which pays off enormously during incident response.

RD vs. RT — Quick Reference

Deployment Checklist

• ✅ Never reuse the exact same RD on two different PEs for the same routing instance.
• ✅ Do match the RT exactly across all PEs that need to communicate within a given EVPN-VPWS instance.
• ✅ Maintain an allocation pool for Service IDs — e.g., 1000–1999 for EVPN-VPWS, 2000–2999 for EVPN-VPLS/L2VPN — to avoid collisions as the network grows.
• ✅ Document the RT-to-service mapping somewhere durable (IPAM, wiki, or automation source of truth) — this is what makes the “self-documenting” property actually useful.

Design Questions Worth Answering Before Rollout

Before standardizing EVPN-VPWS across a production core, it’s worth nailing down:

• Underlay transport: SR-MPLS, RSVP-TE, or LDP? This affects LSP provisioning and traffic engineering options but not the EVPN-VPWS signaling itself.
• Multihoming requirements: Do customer edges need dual-homing to two PEs? If so, will it be All-Active or Single-Active redundancy — this determines whether you also need to configure Ethernet Segment Identifiers (ESIs) on the ACs.
• AS numbering: 2-byte vs. 4-byte AS affects RT formatting and, at scale, how much room you have in the Service ID space.
• Topology intent: Purely point-to-point circuits, or will some services need to evolve into hub-and-spoke or any-to-any (which would push you toward EVPN-VPLS/ELAN instead of VPWS)?

Answering these up front keeps the RD/RT and Service ID allocation scheme consistent as the deployment scales beyond a single PE pair.

Summary

EVPN-VPWS brings carrier-grade P2P Ethernet circuits into the same BGP EVPN control plane already used for modern L3VPN and EVPN-VPLS/VXLAN services. On a Juniper MX480, this means:

• One signaling framework (BGP EVPN) instead of juggling LDP-signaled pseudowires alongside BGP VPNs.
• Native multihoming and fast convergence inherited from the EVPN Ethernet Segment model.
• A structured, scalable RD/RT design that keeps large deployments troubleshootable.
• A clean migration path from legacy l2circuit/pseudowire cross-connects toward a unified, automatable EVPN fabric.

For a lab or production pilot, start with a single P2P pair as shown above, validate convergence behavior under PE and link failure, and only then expand into multihomed CE scenarios.