Nokia VPLS cheat sheet
Nokia VPLS · Keep the key ideas within reach.
VPLS Fundamentals and Architecture
VPLS is a Layer 2 multipoint service: it emulates an Ethernet bridge across an MPLS network, forwarding frames by MAC learning rather than by IP lookup.
Core components: VPLS service (a virtual switch instance), SAPs (attachment to customer ports), SDPs (tunnels to remote PEs), and pseudowires (one per remote PE per service).
VSI MAC table behaves like a bridge: source MAC learned against a SAP or pseudowire; unknown, broadcast, and multicast frames are flooded to all other SAPs and pseudowires.
Split-horizon rule: a frame received from a pseudowire is never forwarded back out another pseudowire, preventing loops in the full-mesh of PWs.
Nokia SR OS VPLS is a mesh service; the classic model requires a full mesh of pseudowires between all participating PEs for a given service ID.
VPLS operates over MPLS transport (LDP or RSVP-TE signaled LSPs), so the underlay must have reachable loopback addresses and working label distribution.
VPLS is a customer-agnostic transparent LAN service: customer VLAN tags can be preserved (dot1q) or manipulated (qinq, null encapsulation) at the SAP.
Scaling factors: number of PEs in the mesh, number of MAC addresses per VSI, and pseudowire count per SDP; these drive hardware and design limits.
VPLS Service Configuration and Provisioning
Create the service first: configure service vpls customer with a unique service ID; the same ID must exist on every PE in the mesh.
Add SAPs with sap :; choose encapsulation matching the customer handoff (null, dot1q, qinq, or default).
Bind transport with spoke-sdp : create; vc-id must match the far-end PE's local vc-id for that service.
Set the mesh: every PE needs a spoke-sdp to every other PE in the full mesh; a missing spoke breaks multipoint reachability.
MAC learning and aging are configurable per VSI; default aging is 300 seconds in SR OS and can be tuned for large Layer 2 domains.
Verify provisioning with show service id base, show service id sap, and show service id sdp to confirm admin/oper state.
Service MTU must be consistent end to end; a mismatch causes large frames to drop silently while small frames pass.
Use descriptive service names and customer IDs for operations; consistent naming simplifies troubleshooting across the mesh.
VPLS Pseudowires
A VPLS pseudowire is an MPLS VC-LSP signaled by targeted LDP between two PEs, identified by a VC ID and VC type (VPLS = 19).
PW signaling uses LDP label mapping; the local label is advertised to the peer and the peer's label is used for egress encapsulation.
PW state machine: initially down, moves to up when both local SAP/SDP binding and remote label mapping succeed; check with show service id sdp.
Control word is optional and used for sequencing and to preserve payload ordering over MPLS; enable only when both ends agree.
PW MTU signaling: the negotiated MTU is the minimum of local and remote; mismatches are a common cause of silent drops for large frames.
PW status signaling (LDP status TLV) propagates remote failures so the local PE can react without waiting for MAC aging.
A spoke-sdp can carry one VC per service; the vc-id must be unique per SDP and match the remote configuration.
PW redundancy uses primary/secondary spoke-SDPs with pre-configured failover; only one is active at a time for a given service.
VPLS SAPs and SDPs
SAP = Service Access Point: the local customer-facing attachment, defined as port:encapsulation (e.g., 1/1/1:100).
SDP = Service Distribution Point: the tunnel toward a remote PE, defined by sdp-id and far-end IP address; it carries one or more pseudowires.
SDP types: GRE, MPLS (LDP), MPLS (RSVP-TE), and LDP; VPLS typically uses MPLS SDPs signaled by LDP or RSVP-TE.
SAP encapsulation options: null (untagged), dot1q (single tag), qinq (double tag), and default; the choice must match the customer's CPE.
Ingress/egress QoS and filter policies are applied at the SAP; SAP-level policers protect the VSI from customer bursts.
SDP keepalives (hello) monitor tunnel liveness; without them, a dead tunnel may not be detected until traffic fails.
SAP admin state (up/down) and SDP admin state are independent; both must be up for the service to forward.
Binding a SAP to a VPLS places the port in the VSI; a port can host SAPs for multiple services using distinct encapsulations.
VPLS Resiliency and Redundancy
Full mesh is the baseline; any missing spoke-SDP reduces the VSI to a partial mesh and can blackhole flooded traffic.
PW redundancy: configure primary and secondary spoke-SDPs to the same far-end PE; failover is triggered by PW status or SDP keepalive failure.
Multi-chassis redundancy (MC-LAG / MC-SAP) lets two PEs share a customer attachment; only one is active per SAP at a time.
Spanning tree (STP/RSTP/MSTP) can run inside the VPLS to break customer Layer 2 loops; BPDUs are tunneled transparently.
Split-horizon prevents PW-to-PW loops but does not prevent SAP-to-SAP loops; customer-side loops still require STP or design controls.
SDP failover and PW redundancy should be combined with fast IGP convergence (e.g., BFD on IGP) to minimize traffic loss.
MAC flush on topology change: when a PW or SAP goes down, flush stale MAC entries to avoid blackholing to a dead path.
Test failover by shutting a spoke-SDP or SAP and confirming the VSI reconverges and MAC entries relearn on the alternate path.
VPLS Operations, Verification and Troubleshooting
show service id base: confirms service admin/oper state, customer, and VSI parameters.
show service id fdb: displays the MAC forwarding database, including MAC, SAP/SDP, and aging state.
show service id sdp and show service id sap: verify pseudowire and SAP operational state, flags, and VC labels.
show service sdp detail: confirms SDP far-end reachability, signaling state, and keepalive status.
Common fault: service up but no traffic - check MTU mismatch, SAP encapsulation mismatch, and missing spoke-SDP in the mesh.
Common fault: MAC flapping - usually a Layer 2 loop or duplicate MAC; inspect FDB entries and STP state.
Common fault: PW down - verify LDP session to the far-end PE, label mapping, and vc-id match on both ends.
Use tools like traceroute (MPLS) and oam to validate the underlay LSP path before blaming the VPLS layer.
Capture and compare ingress/egress counters at SAP and SDP to localize where frames are dropped.
VPLS Service Verification Workflow
Step 1: verify underlay - IGP adjacency, LDP/RSVP session to each PE, and loopback reachability.
Step 2: verify SDP - show service sdp detail; confirm far-end IP, signaling, and keepalive up.
Step 3: verify PW - show service id sdp; confirm VC label, state up, and MTU negotiated.
Step 4: verify SAP - show service id sap; confirm port up, encapsulation, and admin state.
Step 5: verify FDB - show service id fdb; confirm customer MACs learned on the expected SAP/PW.
Step 6: verify flooding - unknown unicast and broadcast should reach all other SAPs and PWs; check split-horizon behavior.
Step 7: verify MTU end to end with large pings or frames; a mismatch shows as small-frame success and large-frame loss.
Document baseline states and counters so future faults can be compared against a known-good snapshot.
VPLS Design and Scaling Considerations
Mesh size grows as N*(N-1)/2 pseudowires; for large sites consider hierarchical VPLS (H-VPLS) with spoke PEs.
H-VPLS: edge PEs connect to a core PE via a single spoke-SDP, reducing full-mesh requirements at the edge.
MAC scaling: each VSI holds a MAC table; size limits depend on the platform and the number of services per PE.
Flooding optimization: IGMP snooping and multicast pruning reduce unnecessary broadcast/multicast replication.
QoS at SAP: shape and police customer ingress to protect the VSI and core from oversubscription.
Service MTU should be set to the maximum supported by all access links to avoid silent drops for jumbo frames.
Consider control-plane load: LDP sessions and PW signaling scale with mesh size; monitor CPU and session counts.
Plan for growth: reserve service IDs, vc-ids, and SDP IDs in a structured range to simplify provisioning.
VPLS Interworking and Encapsulation
Null encapsulation: untagged customer frames; used when the CPE sends untagged traffic.
Dot1q: single VLAN tag; the SAP encapsulation matches the customer VLAN ID; frames are forwarded with the tag preserved or stripped per config.
QinQ: double-tagged frames; used for service provider aggregation where the outer tag identifies the service.
Default encapsulation: matches any tagged or untagged frame on the port; used sparingly because it consumes the whole port.
VLAN translation and SAP-level tag manipulation allow flexible mapping between customer and provider VLAN spaces.
BPDU transparency: STP BPDUs from the customer are tunneled across the VPLS; the provider does not participate unless configured.
L2PT (Layer 2 Protocol Tunneling) can carry customer control protocols transparently across the VPLS.
Encapsulation mismatch between SAP and CPE is a top cause of 'link up but no connectivity' tickets.
VPLS Operations and Monitoring
Log and trap on PW state changes and SDP keepalive failures to catch faults before customers report them.
Use service-level OAM (e.g., Ethernet CFM / Y.1731) where supported to monitor end-to-end connectivity and latency.
Baseline MAC counts per VSI; a sudden drop indicates a path failure, a sudden spike indicates a loop or MAC flood.
Monitor SAP and SDP ingress/egress counters for drops, discards, and errors to localize faults.
Schedule periodic show service id fdb and sdp checks to detect silent PW flaps.
Alarm on MTU mismatch by testing large frames during commissioning, not after go-live.
Keep a per-service record of vc-id, SDP IDs, and SAP encapsulations for fast cross-team troubleshooting.
Use SNMP or telemetry to collect VSI and PW state into the NMS for trend analysis.
VPLS Troubleshooting Decision Rules
If the service is down: check SAP and SDP admin state first, then PW signaling, then underlay reachability.
If the service is up but no traffic: check encapsulation match, MTU, and FDB learning on the expected interfaces.
If only some sites are reachable: a missing spoke-SDP in the full mesh is the likely cause.
If large frames drop but small frames pass: service MTU mismatch between PEs or at the SAP.
If MACs flap between SAP and PW: suspect a Layer 2 loop or duplicate MAC; check STP and split-horizon.
If PW is down but the LDP session is up: verify vc-id match and label mapping on both ends.
If failover does not occur: check PW redundancy configuration and SDP keepalive timers.
If counters show egress drops at the SDP: check core MTU and MPLS label stack size.
VPLS Service Provisioning Checklist
Confirm customer handoff: port, encapsulation (null/dot1q/qinq), and VLAN IDs.
Define service ID, customer ID, and vc-id per PE; keep them consistent across the mesh.
Create SDPs to every remote PE with the correct far-end loopback IP and signaling type.
Bind spoke-SDPs with matching vc-ids on both ends; verify PW comes up before adding SAPs.
Add SAPs with the correct encapsulation and apply QoS/filter policies as needed.
Set service MTU to match the access and core; test with large frames.
Verify FDB learning and flooding behavior with a test host at each site.
Record the configuration and verification output for the service handover package.
VPLS and MPLS Underlay Interaction
VPLS relies on MPLS LSPs between PEs; LDP or RSVP-TE must be operational before PWs can signal.
Targeted LDP is used for PW signaling; the LDP session is between PE loopbacks, not directly connected interfaces.
Label stack: transport label (outer) plus VC label (inner); the VC label identifies the VPLS instance at the egress PE.
PHP (penultimate hop popping) may remove the transport label; the VC label remains for the egress PE to identify the service.
IGP convergence and BFD speed up underlay failover, which in turn speeds VPLS reconvergence.
MTU on the core must accommodate the customer frame plus MPLS labels; account for label stack depth.
RSVP-TE can provide traffic engineering and fast reroute for VPLS transport; LDP is simpler but less resilient.
Verify underlay with LSP ping and traceroute before troubleshooting the VPLS layer.
VPLS Security and Policy
Apply SAP ingress policers to limit customer broadcast and unknown unicast floods.
Use MAC limits per SAP/VSI to prevent MAC flooding attacks from exhausting the FDB.
Storm control on SAPs protects the VSI from broadcast storms originating at customer sites.
Filter policies can drop unwanted Ethertypes or protocols at the SAP.
Isolate customers with separate service IDs and VSIs; never share a VSI across customers.
Control-plane protection: rate-limit LDP and PW signaling to prevent CPU exhaustion.
Log and alarm on MAC limit violations and storm control events.
Regularly audit SAP and SDP configurations for unauthorized changes.
VPLS Service Models and Terminology
VPLS service ID is locally significant but must be consistent across PEs for a given customer service.
VC ID identifies the pseudowire within an SDP; it must match between the two PEs terminating the PW.
SDP ID is locally significant and maps to a far-end PE address; it is not carried in the data plane.
VSI (Virtual Switch Instance) is the forwarding entity inside the VPLS service; it holds the MAC table.
SAP is the local attachment; SDP is the tunnel to a remote PE; together they form the service topology.
Full mesh means every PE has a spoke-SDP to every other PE in the same VPLS.
Split-horizon prevents forwarding between PWs; it does not apply between SAPs.
H-VPLS uses spoke PEs connected to core PEs to reduce mesh size.
VPLS Verification Commands and Outputs
show service id base: service state, customer, MTU, and VSI flags.
show service id fdb: MAC address, interface (SAP/SDP), and aging/state.
show service id sap: SAP ID, encapsulation, admin/oper state, and counters.
show service id sdp: PW ID, VC label, state, and flags.
show service sdp detail: far-end IP, signaling state, keepalive, and MTU.
show router ldp session: LDP session state to each PE.
show router mpls lsp: transport LSP state and path.
Use clear service id fdb to flush MAC entries after topology changes when needed.
VPLS Failure Scenarios and Responses
SAP down: customer port or encapsulation issue; check port state and SAP config.
SDP down: underlay or signaling failure; check LDP session and far-end reachability.
PW down with SDP up: vc-id mismatch or label mapping failure; compare both ends.
Partial mesh: missing spoke-SDP; flooded traffic is not delivered to the missing site.
MAC flapping: loop or duplicate MAC; check STP and split-horizon.
MTU mismatch: large frames drop; verify service MTU end to end.
PW redundancy failover not working: check primary/secondary config and keepalive timers.
Silent blackhole: stale MAC entries after topology change; flush FDB and verify relearning.
VPLS Design Patterns
Full-mesh VPLS: simplest, but PW count grows quadratically with PE count.
H-VPLS: spoke PEs connect to core PEs, reducing mesh size at the edge.
PW redundancy: primary/secondary spoke-SDPs provide path protection without full mesh changes.
MC-LAG: dual-homed customer attachment for access redundancy.
STP inside VPLS: breaks customer Layer 2 loops; provider must ensure BPDU transparency.
QoS at SAP: shape and police to protect the VSI and core.
MTU planning: set service MTU to the maximum supported by all access and core links.
Service ID and vc-id planning: structured ranges simplify provisioning and troubleshooting.
VPLS Operations Best Practices
Baseline MAC counts and PW states after commissioning for future comparison.
Monitor SDP keepalives and PW state changes with traps and logs.
Test failover regularly by shutting SAPs and SDPs.
Keep a per-service record of vc-id, SDP IDs, and SAP encapsulations.
Use service-level OAM where supported for end-to-end monitoring.
Alarm on MAC limit and storm control events.
Audit SAP and SDP configurations for unauthorized changes.
Document verification outputs for handover and audits.
VPLS and Customer Edge Interaction
CE devices see the VPLS as a transparent LAN; they run their own STP, which is tunneled across the VPLS.
BPDU transparency: provider does not participate in customer STP unless configured.
L2PT can carry customer control protocols transparently.
Encapsulation must match the CE handoff: null, dot1q, or qinq.
MTU must accommodate CE frames plus MPLS labels.
QoS at SAP protects the VSI from CE bursts.
MAC limits per SAP prevent CE MAC flooding.
Test CE-to-CE connectivity and failover during commissioning.
VPLS Service ID and VC ID Planning
Service ID is locally significant but must be consistent across PEs for a given customer service.
VC ID identifies the pseudowire within an SDP; it must match between the two PEs terminating the PW.
SDP ID is locally significant and maps to a far-end PE address; it is not carried in the data plane.
Use structured ranges for service IDs, vc-ids, and SDP IDs to simplify provisioning.
Document the mapping of service ID, vc-id, and SDP ID per PE for troubleshooting.
Avoid reusing vc-ids across different services on the same SDP.
Verify vc-id match on both ends when a PW fails to come up.
Keep a central inventory of service IDs and vc-ids for audits.
VPLS and Multicast/Broadcast Handling
Unknown unicast, broadcast, and multicast frames are flooded to all other SAPs and PWs in the VSI.
Split-horizon prevents flooding back out the ingress PW.
IGMP snooping can prune multicast to interested receivers, reducing flooding.
Storm control on SAPs limits broadcast/multicast storms.
MAC limits per SAP prevent MAC flooding attacks.
Monitor flooding counters to detect storms.
Multicast pruning requires IGMP snooping support on the platform.
Test flooding behavior with a broadcast test during commissioning.
VPLS and QoS
Apply SAP ingress policers to limit customer traffic into the VSI.
Shape egress at the SAP to match customer access rate.
Use filter policies to drop unwanted Ethertypes at the SAP.
Mark and prioritize control traffic (STP, LACP) over data traffic.
Protect the core with SDP-level QoS policies.
Monitor drops and discards at SAP and SDP counters.
QoS misconfiguration can cause silent drops for large frames.
Test QoS behavior with traffic generators during commissioning.
VPLS Service Verification with Counters
Compare ingress and egress counters at SAP and SDP to localize drops.
Egress drops at SDP often indicate core MTU or label stack issues.
Ingress drops at SAP often indicate policer or storm control hits.
MAC count drops indicate path failure; spikes indicate loops.
Use clear counters before tests to get clean measurements.
Correlate counter trends with alarms and logs.
Baseline counters after commissioning for future comparison.
Document counter anomalies in the service handover package.
VPLS and MPLS Label Stack
Transport label (outer) is used by core routers to forward toward the egress PE.
VC label (inner) identifies the VPLS instance at the egress PE.
PHP may remove the transport label; the VC label remains for the egress PE.
Label stack depth affects MTU; account for labels in MTU planning.
LDP or RSVP-TE assigns transport labels; targeted LDP assigns VC labels.
Verify label mappings with show router ldp bindings.
Label mismatch causes PW down; compare both ends.
Use LSP ping and traceroute to validate the underlay path.
VPLS and Spanning Tree
Customer STP BPDUs are tunneled transparently across the VPLS.
Provider does not participate in customer STP unless configured.
L2PT can carry customer control protocols transparently.
STP inside VPLS breaks customer Layer 2 loops.
Split-horizon does not prevent SAP-to-SAP loops; STP is still needed.
MAC flapping often indicates a loop; check STP state.
Test STP convergence during commissioning.
Document STP topology and root bridge per customer service.
VPLS and MC-LAG
MC-LAG provides dual-homed customer attachment for access redundancy.
Only one PE is active per SAP at a time.
MC-LAG requires coordination between the two PEs (ICCP or similar).
Failover is triggered by link failure or PE failure.
Verify MC-LAG state with show lag and show redundancy commands.
Test failover by shutting one link or PE.
MC-LAG combined with PW redundancy provides end-to-end resiliency.
Document MC-LAG topology and failover behavior.
VPLS and H-VPLS
H-VPLS uses spoke PEs connected to core PEs to reduce mesh size.
Spoke PEs connect via a single spoke-SDP to a core PE.
Core PEs form the full mesh; spoke PEs do not need full mesh.
H-VPLS reduces PW count and control-plane load.
Spoke PEs can be MTU-s or PE-rs depending on vendor terminology.
Verify spoke-SDP state and core mesh reachability.
H-VPLS is suitable for large sites with many edge PEs.
Document H-VPLS topology and spoke-SDP mappings.
VPLS and PW Redundancy
PW redundancy uses primary and secondary spoke-SDPs to the same far-end PE.
Only one PW is active at a time per service.
Failover is triggered by PW status or SDP keepalive failure.
Configure primary/secondary explicitly and verify failover.
Combine with fast IGP convergence (BFD) to minimize traffic loss.
MAC flush on failover prevents blackholing to a dead path.
Test failover by shutting the primary PW.
Document PW redundancy configuration and failover behavior.
VPLS and Service MTU
Service MTU must be consistent end to end; mismatch causes large frames to drop silently.
PW MTU signaling negotiates the minimum of local and remote.
Core MTU must accommodate customer frame plus MPLS labels.
Test with large frames during commissioning.
Small-frame success with large-frame loss indicates MTU mismatch.
Set service MTU to the maximum supported by all access and core links.
Monitor egress drops at SDP for MTU issues.
Document MTU settings per service.
VPLS and MAC Learning
Source MAC is learned against the ingress SAP or PW.
Unknown, broadcast, and multicast frames are flooded to all other SAPs and PWs.
Split-horizon prevents PW-to-PW forwarding.
MAC aging default is 300 seconds in SR OS; tune for large domains.
MAC flapping indicates a loop or duplicate MAC.
MAC limits per SAP prevent MAC flooding attacks.
Flush FDB after topology changes to avoid stale entries.
Monitor MAC counts for trends and anomalies.
VPLS and LDP Signaling
Targeted LDP is used for PW signaling between PE loopbacks.
LDP label mapping assigns VC labels for each PW.
PW state moves to up when both local binding and remote label mapping succeed.
PW status TLV propagates remote failures.
Verify LDP session state with show router ldp session.
Label mismatch causes PW down; compare both ends.
Rate-limit LDP to protect the control plane.
Document LDP session and PW mappings per service.