ON THIS PAGE
Overview of EVPN VPWS into EVPN E-LAN via PS interfaces and PWHT
If you terminate EVPN VPWS (E-Line) pseudowires on a provider edge (PE) routing device and need to hand off traffic into EVPN E-LAN, you can use a PS interface as the demarcation point between pseudowire transport and VLAN-based service delivery.
Overview
EVPN VPWS to EVPN E-LAN pseudowire headend termination (PWHT) using PS interfaces allows a single VPWS pseudowire termination to hand off multiple VLAN-separated services into EVPN E-LAN. Rather than requiring a dedicated VPWS attachment per service, this design terminates the pseudowire once on a PS transport unit and uses VLAN classification on PS service units to distribute traffic into the correct E-LAN instance or bridge domain.
The PS interface serves a dual role: the transport unit (psX.0) acts as the VPWS endpoint using ethernet-ccc encapsulation, while service units (psX.<vlan-id>) use vlan-bridge encapsulation to map each VLAN into its corresponding EVPN routing instance or bridge domain. This consolidates multiple VLAN-based services onto a single PS transport interface, reducing interface sprawl and simplifying migration from legacy Layer 2 VPN or VPLS designs.
Redundancy is achieved by applying an ESI at the PS physical interface level, aligning EVPN DF election and multihoming behavior across both the VPWS and E-LAN sides. Both all-active and single-active multihoming topologies are supported, with optional DF preference tuning to control forwarding and failover behavior.
For interoperability with FXC peers, VLAN-unaware mode is used to conserve labels on access routers while VLAN normalization on the provider edge maintains deterministic service separation. Existing EVPN VPWS transport and OAM capabilities — including LDP, RSVP-TE, SR-MPLS, control word, flow labels, and RLT — are fully preserved, requiring no new toolsets or changes to the core EVPN control plane.
Benefits
-
Migration and Service Integration
-
Integrates EVPN VPWS E-Line services into multipoint EVPN E-LAN domains without modifying the core EVPN control plane. This simplifies migration from legacy Layer 2 VPN or VPLS designs by terminating the VPWS attachment once and reusing it for service delivery across multiple VLAN-separated E-LAN instances.
-
-
Interface and VLAN Simplification
-
Consolidates multiple VLAN-based services onto a single PS transport interface, reducing interface sprawl and simplifying service mapping.
-
A single PS interface handles both VPWS termination and service attachment, using VLAN classification to direct traffic into the correct EVPN E-LAN instance or bridge domain.
-
Both single-tag and Q-in-Q VLAN configurations are supported on the same termination point, preserving existing customer VLAN structures while maintaining consistent service identification.
-
-
Redundancy and Multihoming
-
Supports multihomed designs by applying an Ethernet Segment Identifier (ESI) on the PS interface and using EVPN Designated Forwarder (DF) election to control forwarding.
-
DF election and multihoming behavior are aligned across both the VPWS and E-LAN sides, ensuring consistent, predictable forwarding and failover in both single-homed and multihomed topologies.
-
-
Operational Efficiency
-
Reuses existing EVPN VPWS transport and OAM capabilities in the PWHT path — including LDP, RSVP-TE, SR-MPLS, control word, flow labels, and RLT — preserving current monitoring and protection practices without introducing new toolsets.
-
FXC VLAN-unaware operation is supported to conserve labels on access routers, while the provider edge maintains deterministic service separation and reliable traffic delivery into EVPN E-LAN.
-
Configuration Basics
PS Interface Structure
EVPN VPWS to EVPN E-LAN pseudowire headend termination (PWHT) using PS interfaces separates the pseudowire-facing attachment from the service-facing handoff. Terminate the EVPN VPWS attachment on the PS transport unit (psX.0), configured with flexible-ethernet-services encapsulation and ethernet-ccc, and reference that unit under the EVPN VPWS routing instance as the attachment circuit. This causes the routing device to treat psX.0 as the VPWS endpoint.
On the service side, configure each PS service unit (psX.<vlan-id>) with vlan-bridge encapsulation and an explicit per-VLAN ID, then bind those units to either an instance-type evpn routing instance (VLAN-based E-LAN) or a virtual-switch routing instance with bridge domains. The VLAN tag acts as the service selector: incoming frames are classified to a PS service unit by VLAN, and the service unit determines the target E-LAN instance or bridge domain. This structure allows a single VPWS pseudowire to feed multiple E-LAN services without requiring a separate VPWS attachment per VLAN.
Multihoming and Redundancy
To build redundancy, configure the ESI at the PS physical interface level so EVPN multihoming procedures and DF election govern forwarding for all traffic entering and leaving through the PS interface. EVPN VPWS continues to use per-EVI auto-discovery signaling and standard RFC 7432 DF procedures; only the attachment circuit type changes to a PS transport logical interface.
In all-active mode, all DFs for a given Ethernet segment forward on their associated PS service logical interfaces. You can optionally tune df-election-type preference to bias which provider edge becomes DF for a given ESI, controlling forwarding for BUM traffic and influencing convergence behavior during failures. In single-active mode, only the DF establishes and maintains the pseudowire; the non-DF holds a circuit cross-connect (CCC) route in discard until a failure promotes it to DF. This provides EVPN-driven control over which provider edge terminates the pseudowire and injects traffic into the E-LAN.
FXC Interoperability
When interoperating with an EVPN VPWS Flexible Cross Connect (FXC) peer, use VLAN-unaware mode. In this mode, attachment circuits are bundled into FXC groups that share a single per-EVI auto-discovery route and a common service-id. On the provider edge, terminate each bundle on a dedicated PS interface and use its service logical interfaces to demultiplex VLANs into E-LAN instances via VLAN normalization. This allows the remote side to conserve labels per EVI while still mapping each service into the correct E-LAN instance.
VLAN-aware mode is not supported in this design. Because a single logical interface cannot participate in both a VPWS and an E-LAN instance simultaneously, VLAN-aware FXC — which assigns each attachment circuit its own service-id, auto-discovery route, and Ethernet Tag ID — cannot be used when the VPWS pseudowire must terminate into EVPN E-LAN through PS interfaces.