Nokia VPLS common mistakes
Nokia VPLS · Understand the traps and how to avoid them.
Treating a VPLS as a Layer 3 VPN and describing the service as routing customer prefixes, then answering questions about VRFs and route targets as if they applied to the VPLS itself.
Candidates arrive from an IP-VPN background and carry over the mental model that a VPN service terminates IP. In a VPLS the PE learns customer MAC addresses and forwards Ethernet frames, so the service is Layer 2 multipoint; route targets appear only in the BGP-based auto-discovery and signalling context, not as a forwarding mechanism.
What to do instead
Build one clear mental sentence before studying: 'VPLS is a bridged LAN emulation; PEs learn MACs, flood unknown unicast, and never route customer traffic.' Then, for every concept you revise, ask 'is this a Layer 2 or Layer 3 concept?' and write the answer next to it. Practise describing the same topology twice, once as VPLS and once as an IP VPN, to see where the models diverge.
Confusing the VPLS service identifier with the transport identifiers, for example quoting the service ID where the exam asks for the SDP or tunnel used, or assuming one SDP equals one VPLS.
In SR OS a VPLS service, an SDP, and a pseudowire (VC) are separate objects with separate IDs, and one SDP can carry many VPLSs. Candidates who configure only via the CLI quickly lose track of which number belongs to which layer, and under exam pressure they pick the first familiar number.
What to do instead
Draw a three-layer stack on paper: service (VPLS ID) on top, SDP in the middle, VC/pseudowire ID at the bottom, and put the actual numbers from a lab config on each layer. Repeat until you can state which object a given number identifies without hesitation. Verify in the lab by showing one SDP carrying two VPLSs with different VC IDs.
Assuming a SAP is automatically a member of the VPLS and will forward traffic as soon as it is created, without checking that it is bound to the correct service and that its encapsulation and port are right.
The CLI accepts a sap command under a service context even when the port or encapsulation does not match the physical configuration, and many candidates configure the port separately and never return to confirm the binding. The service then exists but carries no customer traffic.
What to do instead
Adopt a fixed provisioning checklist for every service: create customer, create service, add SAP with explicit port and encapsulation, add SDP bindings, then verify with the service ID and SAP show commands before testing traffic. In the lab, deliberately create a SAP with the wrong encapsulation to see the error and the operational state it produces, so you recognise the symptom in exam scenarios.
Explaining VPLS MAC learning as if the PE learns every customer MAC in the data plane across the whole mesh, or claiming the PE never floods, and then predicting unicast-only behaviour for unknown destinations.
The control plane (BGP auto-discovery, or manual SDP configuration) sets up the pseudowire mesh, but customer MAC addresses are learned in the data plane from received frames. Unknown unicast, broadcast, and multicast must be flooded to all other mesh members. Candidates mix up what the control plane distributes with what the data plane learns.
What to do instead
Separate the two planes explicitly in your notes: control plane distributes VPLS membership and labels; data plane learns MACs per SAP and per SDP. Then trace one frame from an unknown source through the PE: learn source, flood to all other SAPs and SDPs, receive the reply, install the MAC. Rehearse the flooded-versus-known-unicast decision for three scenarios.
Designating a primary and backup path in the VPLS and then expecting automatic failover without verifying that the SDP or pseudowire is configured for redundancy and that the standby path is administratively up and monitored.
Redundancy in SR OS is explicit: you must configure the standby SDP or spoke SDP and the mechanism that selects between them, and the backup must be operational before it can take over. Candidates assume the mesh or the IGP reroute alone provides service-level protection and never test the failure.
What to do instead
In the lab, build a VPLS with a primary and a standby SDP, then shut the primary port and observe which commands show the switchover and how long it takes. Learn the difference between IGP/LDP reconvergence and VPLS-level redundancy so you can answer questions about what protects the service versus what protects the tunnel. Record the exact show output that proves the standby is active.
Ignoring split-horizon rules and predicting that a frame received from one pseudowire will be forwarded out another pseudowire in the same VPLS.
Full-mesh VPLS relies on split horizon to prevent loops: a frame arriving on a spoke SDP is not sent back out other spoke SDPs of the same service. Candidates reason only about MAC learning and forget the forwarding constraint, so they mispredict traffic paths in mesh and hierarchical designs.
What to do instead
Memorise the rule as a one-liner: 'spoke in, never spoke out, within the same VPLS.' Then apply it to a three-PE full mesh and to a hierarchical VPLS with a spoke layer, drawing arrows for every allowed and blocked direction. Test it in the lab with a frame capture or service counters to confirm the blocked direction.
Diagnosing a VPLS outage by starting with customer equipment or the access port, rather than first confirming the service and pseudowire operational state on the PE.
VPLS failures usually sit at the service or transport layer, and the PE already reports that state. Candidates who lack a fixed troubleshooting order jump to the most visible device and waste time, and in exam scenarios they choose the least informative first step.
What to do instead
Use a top-down order every time: service operational state, then SAP state, then SDP/VC state, then tunnel and IGP/LDP state, then access port, then customer equipment. Practise on injected faults in the lab so the order becomes automatic, and be able to name the specific show command that answers each step.
Assuming a VPLS is fully resilient because the underlying IGP has redundant links, and failing to check whether the pseudowire mesh itself has a path around a failed PE.
IGP reconvergence restores IP reachability between PEs, but if the VPLS mesh is built on a hub or a single SDP per pair, the service may still lose connectivity or blackhole traffic. Candidates conflate transport resilience with service resilience and answer questions about VPLS protection using IGP facts.
What to do instead
For each design, ask two separate questions: 'if this link fails, does IP reachability return?' and 'if this PE or SDP fails, does the VPLS still have a path between every pair of sites?' Practise drawing the VPLS mesh separately from the IP topology so the two are never confused, and note which redundancy features address which question.
Reading service counters or MAC tables without knowing what normal looks like, then declaring a fault when the output is simply the expected full-mesh behaviour.
In a healthy full mesh, a PE legitimately shows MACs learned from every remote site and counters incrementing on many SDPs. Candidates who have not baselined a working service misinterpret normal flooding, ageing, or counter values as faults and pick wrong answers in verification questions.
What to do instead
Before injecting any fault, capture and annotate the show output of a working VPLS: MAC table, SAP and SDP operational state, and counters. Keep that baseline next to you during fault exercises so you compare against known-good rather than against intuition, and be able to say which single field changes when a pseudowire goes down.
Answering questions about VPLS scaling and design limits with general Ethernet knowledge, without knowing which PE functions (MAC learning, flooding, replication) consume resources and how mesh size affects them.
Every additional site in a full mesh adds pseudowires and replication load at each PE, and candidates who never studied the scaling implications assume VPLS behaves like a simple switch. Exam questions on design choices then expose the gap.
What to do instead
Learn the scaling relationship explicitly: full mesh grows with the square of the number of PEs, and flooding and unknown unicast replicate to all peers. Compare full mesh, hub-and-spoke, and hierarchical VPLS on that basis, and be able to state which design trades resilience for scale. Write the trade-off in one sentence per design so you can recall it under time pressure.