Nokia NRS I common mistakes
Nokia NRS I · Understand the traps and how to avoid them.
Treating OSPF area design and LSA types as static trivia: assuming an ABR only ever injects Type 3 summaries, and forgetting that Type 5 LSAs are flooded unchanged through normal (non-stub, non-NSSM) areas, so redistribution from a non-backbone area is reachable everywhere.
Candidates memorise 'Type 3 = summary, Type 5 = external' but never map LSAs onto a multi-area topology. The exam presents redistribution in a non-backbone area and expects you to trace the LSA path, which pure memorisation cannot do.
What to do instead
For each area type (normal, stub, totally stubby, NSSM, totally NSSM), write out which LSA types exist and where redistribution is allowed. Practice one diagram where an ASBR sits in a non-backbone area and trace the Type 5 flooding hop by hop.
Configuring and verifying an IPv4/IPv6 dual-stack interface by copying the IPv4 command sequence and assuming the IPv6 address is active, without checking that the interface has a link-local address and that the global address is not in tentative or duplicate state.
IPv6 brings neighbour discovery, DAD and RA behaviour that IPv4 candidates never had to reason about. The address appears in the configuration but the interface is not forwarding until DAD completes or an RA/prefix is actually being advertised.
What to do instead
Learn the verification chain: interface link-local address present, global address not tentative, neighbour entry reachable, and Router Advertisements or managed-config flags set as intended. Practise reading the IPv6 address state flags rather than only the configured address.
Assuming a route is active simply because it exists in the routing table, and failing to check the route preference (administrative distance) and the longest-prefix-match interaction when a static route, an OSPF route and a BGP route compete for the same destination.
Candidates learn protocols in isolation and then answer based on which protocol was configured last or which is 'more specific' by intuition, forgetting that Nokia's route preference values decide between equal-prefix routes and that more-specific prefixes always win regardless of preference.
What to do instead
Memorise the default route preference ordering used in Nokia SR OS and apply a two-step test on every question: first longest prefix match, then route preference among equal prefixes. Build a small table of the preferences you are expected to know and re-derive the answer for each competing-route scenario.
Answering an aggregation or redundancy question by naming the protocol (LAG, MC-LAG, STP, VRRP) without stating which specific failure the mechanism does and does not cover, such as assuming a LAG protects against a single member link failure and a peer failure at the same time.
Protocol names are easy to recall; failure semantics are not. The exam deliberately presents a failure event and asks what happens, and a candidate who only knows the acronym guesses.
What to do instead
For each mechanism, write one sentence on what it protects against and one on what it does not. Practise describing the exact sequence after a member link goes down versus after a peer node fails, including which control protocol detects it and how fast.
Confusing the control-plane and data-plane roles in a switching and aggregation design: assuming a spanning-tree or loop-prevention protocol decides the forwarding path in a fully routed or MC-LAG design, or that an aggregation layer must run STP even when it is L2-free.
Candidates mix up L2 and L3 design patterns and apply whichever loop-prevention tool they last studied, rather than identifying whether the design is bridged or routed at that layer.
What to do instead
Before answering, classify each layer as bridged or routed. If bridged, identify the loop-prevention mechanism and the blocked port; if routed, identify the routing protocol and the equal-cost paths. State the classification explicitly in your reasoning.
Describing NSP automation as 'it pushes config' without naming the specific function being asked about, such as service fulfilment versus assurance versus model-driven configuration, or the role of the intent/ template versus the device adapter.
NSP is a broad platform and candidates learn the marketing summary rather than the functional decomposition. Exam questions target a specific stage of the workflow, so a generic answer cannot score.
What to do instead
Map the NSP workflow into distinct stages: service intent and modelling, service design and templates, provisioning to devices, and assurance/telemetry feedback. For each question, name the stage and the artefact (template, intent type, adapter) involved.
Treating a model-driven or template-based change as automatically safe: assuming that because the configuration was generated by automation it will apply cleanly, without checking pre-conditions, device state, or rollback behaviour.
Candidates equate automation with correctness. In practice a template applied to a device in an unexpected state (missing prerequisite, version mismatch) produces a partial or failed change, and the exam tests exactly that gap.
What to do instead
For every automation scenario, state the pre-check, the intended change, the verification after the change, and the rollback path. Learn to distinguish a failed commit from a partially applied change and how each is detected.
Answering a security question by naming the feature (ACL, uRPF, control-plane protection, MACsec, IPsec) without specifying the direction, the match criteria, and the default action, which is what actually determines whether traffic is permitted or dropped.
Feature names are memorable; semantics are not. An ACL applied in the wrong direction or with an implicit permit at the end produces the opposite result from the one the candidate assumes.
What to do instead
For every filter question, write out: interface, direction, match order, and the default action for unmatched traffic. Practise predicting the outcome for a specific packet by walking the entries in order rather than reasoning from the feature name.
Assuming a data-centre or transport design is symmetric and that a single underlay path exists, then answering about traffic behaviour without considering ECMP, overlay encapsulation overhead, or the MTU implications of tunnelling.
Candidates study the overlay (VXLAN or similar) and the underlay separately and forget that the overlay depends on the underlay's MTU, ECMP hashing and failure convergence. Questions about one layer are answered as if the other did not exist.
What to do instead
For each DC scenario, draw the full stack: physical links, underlay routing, tunnel endpoints, overlay. Then check MTU end to end, how ECMP distributes flows, and what happens on a single underlay link failure. Answer from the full stack, not one layer.
Reading the question's scenario once and answering from the first plausible keyword match, instead of identifying the exact object being asked about (which node, which direction, which protocol instance, which failure event) before choosing an answer.
NRS-style questions embed the decisive detail in a subordinate clause, such as 'after the primary peer fails' or 'on the standby node'. Candidates under time pressure pattern-match on the topic and miss the qualifier that changes the answer.
What to do instead
Adopt a fixed routine: underline the object, the event, and the direction in the stem before looking at the options. Eliminate options that are correct in general but wrong for the stated event. If two options remain, re-read the qualifier rather than re-reading the whole stem.