Nokia VPLS study materials
Nokia VPLS study resources

Nokia VPLS cheat sheet

Nokia VPLS · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.