10.2 Layer 2 Services: VPWS/VLL and VPLS
Key Takeaways
Epipe is point-to-point Ethernet transport without VPLS-style destination MAC learning.
VPLS bridges multiple attachments using a per-service FDB.
A VC-ID is 32 bits; an MPLS service label value is 20 bits.
Mesh split horizon requires end-to-end logical pseudowires, not direct physical cables between every PE.
A control word and label stack add overhead that must fit actual path and service MTUs.
Point-to-point or multipoint Ethernet?
Virtual Private Wire Service (VPWS) provides point-to-point service. Nokia's Virtual Leased Line terminology includes Epipe for Ethernet transport. Virtual Private LAN Service (VPLS) provides multipoint Ethernet bridging.
The customer determines the choice. Two attachment points needing a virtual Ethernet wire fit Epipe. Several sites needing one bridged Ethernet domain fit VPLS. A customer wanting the provider to route between site IP networks may instead need VPRN.
An Ethernet VPN service is not automatically encrypted. The provider must correctly separate services and apply suitable policies. Its forwarding model also determines whether customer MAC addresses are learned.
Epipe forwarding
A basic Epipe has two active attachment endpoints. It forwards frames between them without selecting among multiple destinations through a learned VPLS-style FDB. A local Epipe connects two local SAPs. A distributed Epipe connects a local SAP to a remote attachment through a pseudowire.
Other VLL names exist for different client technologies, such as Apipe for ATM and Cpipe for circuit emulation, with support depending on platform. Ipipe interworks supported access encapsulations. These names are not interchangeable Ethernet service choices.
For a distributed MPLS Epipe, targeted LDP can exchange pseudowire parameters and service labels between PEs. The VC-ID is a 32-bit identifier, while the MPLS label value is 20 bits inside a 32-bit stack entry. Labels need not have equal numeric values in the two directions.
An Epipe MD-CLI fragment
Use the supporting LabCustomer, access port, and SDP 10 from the preceding lesson:
configure private
/configure service epipe "Epipe-A" service-id 100
/configure service epipe "Epipe-A" customer "LabCustomer"
/configure service epipe "Epipe-A" admin-state enable
/configure service epipe "Epipe-A" sap 1/1/3:100
/configure service epipe "Epipe-A" spoke-sdp 10:100
compare
validate
commit
At the remote PE, create the corresponding customer service, its access SAP, and a local SDP pointing back to the first PE. Bind the pseudowire using the same VC-ID 100 and compatible VC type, MTU, and control-word behavior. The remote local SDP ID and service name need not equal those on the first PE.
This fragment is illustrative and does not prove an operational end-to-end service. Check actual binding state and packet counters after configuring both endpoints.
Label stack and control word
A common distributed Epipe packet carries an outer transport label and an inner service label. The outer label reaches the egress PE; the inner label selects the egress pseudowire/service handling. Core transport termination can pop the outer label while leaving the service label.
An optional pseudowire control word sits between the service-label stack and customer payload when the service negotiates and uses it. It helps avoid mistaking the payload for IP during core hashing and can support sequencing mechanisms. It does not universally prevent all packet reordering.
Count overhead explicitly. Two MPLS entries add eight bytes; a four-byte control word adds another four. Customer Ethernet framing and the outer core link add other bytes. Compare actual service and path MTU definitions rather than copying one universal “required MTU.”
VPLS learning and flooding
VPLS emulates a distributed Ethernet bridge. Each service has its own Forwarding Database (FDB) mapping learned source MAC addresses to SAPs or remote attachments.
Known destination MACs use the relevant forwarding entry. Unknown unicast, broadcast, and applicable multicast traffic can be replicated to eligible attachments. Flooding still obeys ingress exclusion, split-horizon, filtering, and multicast optimizations.
Dynamic MAC entries age according to configured local and remote timers. A remembered MAC is not an ARP entry: the FDB maps MAC to attachment, while ARP maps an on-link IPv4 address to a MAC.
Mesh split horizon
In a conventional VPLS core mesh, a frame received over a mesh-SDP is not forwarded over another mesh-SDP in that service. Consequently, each participating core PE needs a logical pseudowire relationship to every other participating PE.
Four PEs require 4 × 3 / 2 = 6 pairwise pseudowires. This is a count of relationships, not physical core cables. Each LSP can cross multiple routers.
Spoke attachments can extend the service hierarchically, but redundant customer or spoke links can introduce loops. Do not disable all spanning-tree or access protection merely because the core mesh uses split horizon.
A VPLS MD-CLI fragment
Assume a separate provisioned access port 1/1/4 is configured in access mode with dot1q encapsulation. Reuse the customer and transport SDP:
configure private
/configure service vpls "VPLS-A" service-id 200
/configure service vpls "VPLS-A" customer "LabCustomer"
/configure service vpls "VPLS-A" admin-state enable
/configure service vpls "VPLS-A" sap 1/1/4:200
/configure service vpls "VPLS-A" mesh-sdp 10:200
compare
validate
commit
The remote VPLS uses a matching VC-ID 200 for this relationship and its own local access attachment. Additional PEs require the appropriate mesh relationships, not simply another SAP on one existing PE.
Inspect show service id 100 sdp for the Epipe binding and show service id 200 fdb for VPLS learning. If a source MAC appears on an unexpected attachment, check cabling, SAP mapping, and loops. If service labels exist but traffic fails, check transport, MTU, access tags, and filters.
Primary references
Nokia VPLS documentation and pseudowire control protocol, checked October 20, 2026.
Compare the forwarding models
| Property | Epipe | VPLS |
|---|---|---|
| Basic topology | Two active attachment endpoints | Multiple bridged attachments |
| MAC-learning decision | No VPLS-style FDB lookup | Per-service source learning and destination lookup |
| Remote attachment | Spoke pseudowire in this model | Mesh or hierarchical spoke design |
| Key failure evidence | SAP, binding, transport, MTU | Those dependencies plus FDB learning and loop controls |
What does targeted LDP exchange for the illustrated distributed Ethernet pseudowire?
The IGP topology of every core router
A learned customer MAC table
Pseudowire parameters and 20-bit service-label values carried in 32-bit stack entries
Guaranteed end-to-end bandwidth reservations
Why does a conventional VPLS core use a full mesh of logical mesh-SDP pseudowires?
Spoke-SDPs cannot carry tagged customer traffic
Mesh split horizon prevents relaying from one mesh binding to another within the service
Every PE must have one physical cable to every other PE
LDP cannot cross an intermediate router
Which Nokia SR OS VLL service flavor is specifically designed to interconnect two native Ethernet customer networks transparently across an IP/MPLS infrastructure without performing MAC address learning?
Epipe
Ipipe
Apipe
Cpipe
Sections you finish are checked off in the contents.