Nokia MPLS common mistakes
Nokia MPLS · Understand the traps and how to avoid them.
Treating an LSP as a single hop-by-hop routed path and answering IGP shortest-path questions as if the labelled packet were re-examined at every node, so the candidate picks the hop-by-hop forwarding result instead of the label-switched path the ingress computed.
Candidates carry over hop-by-hop IP intuition from plain routing study and forget that the ingress LER assigns the label stack and interior LSRs forward purely on the incoming label, with PHP stripping the label before the egress. The exam leans on this distinction in forwarding and troubleshooting items.
What to do instead
Before answering, draw the label stack at each hop: ingress pushes, transit swaps, penultimate pops, egress delivers. Rehearse a three-node LSP on paper until you can state the exact LFIB entry and outgoing label at each node, then check whether the question is about control-plane path selection (CSPF/TED) or data-plane forwarding.
Assuming a single area or a flat IGP everywhere when the scenario describes a large aggregation domain, and then predicting that a summary or a specific prefix will be visible where it will not be, or that a route will be preferred when it is actually suppressed by summarisation.
Candidates memorise OSPF/IS-IS basics but never practise multi-area design with Nokia's area and level boundaries, so they miss that inter-area routes are learned via ABR/L1-L2 and that summarisation hides more-specifics. The exam tests design consequences, not definitions.
What to do instead
Build a two-area OSPF and a two-level IS-IS lab and record which LSAs/PDUs cross each boundary. For every summarisation question, list which specific prefixes disappear from the far side and which traffic then follows the summary route; answer from that table, not from memory.
Confusing control-plane protection with data-plane protection: choosing a fast-reroute or redundancy answer when the question asks what happens to in-flight traffic during a failure, or the reverse.
Terms such as primary/secondary, protected path, and redundancy are used loosely in study material, and candidates do not separate 'signalling a backup path' from 'traffic actually moving within a given time'. Nokia exams probe exactly this gap in convergence questions.
What to do instead
For each protection mechanism you study, write two lines: what is pre-signalled or pre-computed, and what action the forwarding plane takes at the moment of failure. Practise classifying scenarios into 'path recomputed after failure' versus 'standby already established', and answer only from that classification.
Answering aggregation and switching questions as if all traffic between access and core is routed, ignoring that the design may bridge at Layer 2 and that MAC learning, flooding, and loop prevention then govern behaviour rather than routing tables.
Candidates over-index on the routing portions of their study and treat the aggregation domain as a routing problem, so they mispredict behaviour for broadcast handling, unknown unicast, and topology-change effects in a bridged aggregation ring or square.
What to do instead
For any topology in a question, first label each segment as routed or bridged before reasoning. If bridged, trace the path of an unknown unicast frame and note where it floods and where it is dropped; if routed, trace the prefix lookup. Answer from the label, not from habit.
Treating link aggregation as automatically providing both more bandwidth and sub-second failure recovery, and picking answers that assume a single member failure is invisible to higher layers without checking how the bundle is hashed and monitored.
Bundles are taught as a simple 'add links' feature, so candidates miss that per-flow hashing means one flow stays on one member, that a failed member only helps flows rehashed onto survivors, and that failure detection depends on the configured mechanism rather than on the bundle existing.
What to do instead
Study one bundle end to end: hashing inputs, member failure detection options, and what happens to a single large flow when one member dies. Write a one-line rule for bandwidth questions and a separate one for convergence questions, and apply the matching rule to the scenario.
Assuming a controller or automation platform pushes intent directly to forwarding hardware, so a question about a failed intent deployment is answered as if the data plane changed immediately rather than through a modelled service and device-level configuration.
Candidates learn automation as a black box and skip the layering between service intent, the model of the network, and the per-node configuration actually generated. Exam items test where a failure or mismatch appears in that chain.
What to do instead
Draw the chain explicitly: intent or service definition, the platform's network model and computed configuration, then the device configuration and its commit. For each fault scenario, state which layer holds the wrong state. Answer by locating the layer, not by guessing the platform behaviour.
Confusing configuration reconciliation with state synchronisation, and answering that a device will be corrected automatically when the platform only reports a deviation, or that a deviation will be reported when the platform actually overwrites it.
Both ideas sound like 'the platform manages the device', and candidates never separate detect-and-report from enforce-and-overwrite. Nokia automation questions test precisely which mode is in effect and what the operator sees afterwards.
What to do instead
Memorise the two behaviours as a pair with their observable outcomes: one leaves device configuration untouched and raises a difference, the other rewrites the device to match the model. For each question, identify which behaviour the described mode implies, then predict the device state and the alarm.
Answering security questions by naming a feature rather than the enforcement point, so a control-plane protection answer is given for a data-plane attack scenario, or a filtering answer is placed at the wrong interface direction.
Candidates memorise feature lists without mapping each feature to where it acts and in which direction. Exam items describe an attack or a requirement and expect the candidate to place the control at the correct point.
What to do instead
Build a table with three columns: what is protected, where it is enforced, and which direction traffic is examined. Fill it for control-plane protection, interface filtering, and subscriber or service-level separation. Answer by locating the enforcement point first, then choosing the feature.
Treating an optical span as lossless and distance-independent, and choosing an answer that ignores that reach depends on budget, dispersion, and amplification rather than on the nominal interface rate alone.
Candidates study optical transport as a list of line rates and pluggables and never practise a link-budget or reach calculation, so they accept answers that would only hold over a short, low-loss span.
What to do instead
Practise one worked budget: launch power, connector and splice losses, fibre attenuation over the stated distance, and remaining margin against receiver sensitivity. Then check any dispersion or amplification constraint. Reject any option that ignores distance or margin, even if the line rate matches.
Mixing up the roles of the interconnected data centre sites, assuming that a Layer 2 stretch makes two sites one failure domain, or that a Layer 3 interconnect preserves the same addressing and broadcast behaviour as a local fabric.
Interconnect designs are taught as 'connect the sites', and candidates do not separate what is stretched, what is routed, and where a failure is contained. Exam items test the consequence for addressing, broadcast, and failure propagation.
What to do instead
For each interconnect scenario, write three answers before looking at options: what is stretched, what is routed, and what fails together. If the option contradicts any of the three, discard it. This forces you to reason about failure domains rather than about the technology name.