Nokia NRS II common mistakes
Nokia NRS II · Understand the traps and how to avoid them.
Treating the NRS II written exam as a single-technology test and studying only routing, skipping the automation and security domains that make up a substantial share of the blueprint.
Candidates come from an operations background where day-to-day work is mostly OSPF/IS-IS/BGP, so they default to what feels comfortable and underestimate how many questions probe IP network automation (model-driven management, NETCONF/YANG, telemetry) and IP network security (uRPF, control-plane protection, BGP/IS-IS authentication, segment isolation).
What to do instead
Build a study plan directly from the five published domains and allocate time proportionally, with a minimum block for automation and security even if they are unfamiliar. For automation, be able to explain the difference between CLI/SNMP polling and model-driven NETCONF/YANG with gNMI telemetry, and where each fits. For security, be able to justify a concrete filter or protection mechanism (uRPF strict versus loose, control-plane policing, MD5/SHA authentication for routing protocols) and state what attack it mitigates.
Reciting protocol theory (timer values, packet formats, state-machine names) but failing scenario questions that ask which mechanism to deploy or why a design breaks.
NRS II is aimed at design and troubleshooting competence, not recall. Candidates who memorized OSPF LSA types or BGP path-selection order from a summary sheet cannot connect that knowledge to a topology description, so they pick the answer that names the right protocol but not the right behaviour.
What to do instead
Convert every fact into a decision rule. For example, instead of memorizing that OSPF uses type 3 LSAs for inter-area routes, practise answering: given an ABR with a stub area and a summary route, what does each router's LSDB contain and where does traffic go? Work through at least a dozen small topologies on paper, predicting the RIB/FIB and the failure behaviour before checking the answer.
Confusing the roles of IGP and BGP and misapplying route redistribution, leading to wrong answers on route selection and loop-prevention questions.
In real networks the IGP carries infrastructure and loopbacks while BGP carries customer/service routes; candidates blur this and assume BGP will provide fast convergence or that redistributing BGP into OSPF is harmless. They then choose answers that would create feedback loops or suboptimal routing.
What to do instead
Internalize the division of labour: IGP for reachability of next hops and loopbacks, BGP for policy and scale, with redistribution only at well-defined boundaries and always with filtering. Practise tracing a packet from a PE loopback through an IGP route to a BGP next hop, and practise spotting a redistribution loop (mutual redistribution without tags or prefix filters) in a diagram.
Ignoring the data plane when diagnosing a described fault, and answering purely in terms of control-plane protocol state.
Questions often describe a symptom (traffic black-holed, one direction failing, MTU-related drops) where the routing table looks correct. Candidates stop at 'the adjacency is up, so routing is fine' and miss that the forwarding path, FIB programming, or MTU is the real cause.
What to do instead
Adopt a fixed troubleshooting order for every scenario: physical/link, then Layer 2, then control plane adjacency and LSDB/RIB, then FIB/data plane, then policy (filters, MTU, uRPF). For each layer, name the specific command output or counter you would check. Practise questions that hinge on MTU, asymmetric routing, or a route present in the RIB but not installed in the FIB.
Treating switching and aggregation as trivial Layer 2 and skipping spanning tree, link aggregation, and Layer 2/Layer 3 boundary design questions.
Candidates assume 'switching is easy' and spend their time on BGP, so they cannot reason about STP/RSTP topology changes, root bridge placement, loop guard/BPDU protection, LAG hashing, or where to place the Layer 2/Layer 3 boundary in an aggregation ring or square.
What to do instead
Study aggregation design as a first-class topic: root bridge and STP timers, RSTP edge ports and topology-change propagation, loop protection features, LAG/LACP behaviour on member failure, and the trade-offs of Layer 2 versus Layer 3 aggregation. Draw a two-tier aggregation topology and predict the effect of a single link or node failure at each layer before checking.
Answering IP addressing and subnetting questions from memory without verifying with a quick calculation, producing off-by-one errors on usable host ranges and prefix boundaries.
Under time pressure, candidates estimate rather than compute, and VLSM or summarization questions punish small errors: the wrong broadcast address, the wrong usable range, or a summary that is not the longest match.
What to do instead
Use a consistent written method: convert the mask to a block size, list network and broadcast addresses explicitly, and for summarization verify the candidate summary by checking that every component prefix falls inside it and the next prefix outside does not. Do timed drills of 20 subnetting and summarization problems until the method is automatic.
Choosing the 'most secure-sounding' answer in IP network security questions rather than the one that matches the stated requirement and the traffic path.
Security questions often present several plausible controls. Candidates pick the strongest-sounding option (for example, dropping all ICMP, or applying strict uRPF everywhere) even when it breaks legitimate asymmetric traffic or management access described in the scenario.
What to do instead
Read the scenario for the constraint: is traffic symmetric, is multihoming present, is in-band management required? Then select the control that satisfies the requirement without collateral damage, and be able to say what it does not protect against. Learn the specific limitations of uRPF strict versus loose, of control-plane policing, and of routing-protocol authentication, and practise rejecting the over-broad option with a one-sentence justification.
Skipping hands-on configuration and verification practice and relying only on reading, so answers on command output and operational behaviour are guesses.
The exam tests operational understanding: what a show command reveals, what a log message means, what happens when a timer expires. Readers who have never configured or verified the feature cannot interpret the described output.
What to do instead
For each major topic, run a small lab (physical, virtual, or simulator) and perform the failure: break an adjacency, misconfigure an area, apply a wrong filter, watch the counters and logs. Keep a one-page note per feature recording the verification command and the expected output, and review those notes in the final week.
Misreading multi-part or 'which two' questions and selecting one correct option or an extra incorrect one, losing marks on questions the candidate actually knows.
Under time pressure candidates skim the stem, miss qualifiers such as 'least', 'except', or 'choose two', and answer the question they expected rather than the one asked.
What to do instead
Adopt a mechanical reading habit: underline the qualifier and the number of selections before evaluating options, eliminate options one at a time with a written reason, and re-check the selection count before moving on. In practice sets, track every lost mark caused by misreading and review that list before the exam.
Leaving automation and security topics to the last week and then memorizing acronyms (YANG, NETCONF, gNMI, telemetry) without understanding the data flow between manager and device.
These domains feel abstract to candidates with a routing background, so they are deferred; cramming produces acronym recall but no ability to answer questions about which protocol carries which operation, or how configuration and state data differ.
What to do instead
Learn automation as a data-flow story: manager opens a session (NETCONF over SSH or gNMI over gRPC), retrieves or edits a YANG-modelled datastore, and subscribes to telemetry streams for state. Be able to distinguish configuration datastores from operational state, and to say when SNMP polling is still appropriate. For security, tie each mechanism to the layer it protects and the attack it addresses, and test yourself by explaining both aloud without notes.