Nokia NRS II Composite (IS-IS) common mistakes
Nokia NRS II Composite (IS-IS) · Understand the traps and how to avoid them.
Candidates treat the NSAP/NET as if it were an IP address and try to read the system ID as a subnet or interface identifier, then misplace the area portion when designing an address plan.
They carry over IPv4 habits and assume the whole address is hierarchical end-to-end, so they do not separate the three IS-IS components (area ID, system ID, NSEL). They also forget the NSEL must be 00 on a router NET and that the system ID must be a fixed length within a domain.
What to do instead
Drill the structure explicitly: area ID (variable length, 1-13 bytes), system ID (6 bytes on Nokia SR OS), NSEL (1 byte, 00 for a router). Convert the system ID from the loopback IPv4 address into 3 groups of 4 decimal digits (e.g. 10.1.1.1 becomes 0100.0101.0001) and verify the total length. Practice writing a full NET such as 49.0001.0100.0101.0001.00 and labelling each field.
When asked why two routers will not form an adjacency, candidates answer 'the areas differ' even though Level 1 and Level 2 adjacency rules are asymmetric and area mismatch only breaks Level 1.
They memorise 'same area required' without distinguishing Level 1 (same area ID required) from Level 2 (area IDs may differ, but the routers must both be capable of Level 2 and the system IDs must differ). They also overlook the other mandatory checks: MTU, authentication, and matching hello parameters.
What to do instead
Build a checklist per level. Level 1: matching area ID, matching Level 1 hello timers/hold multiplier, matching authentication, MTU sufficient for the largest LSP, unique system ID. Level 2: both interfaces enabled for Level 2, unique system ID, matching Level 2 hello parameters, authentication and MTU. State explicitly that area mismatch alone does not prevent a Level 2 adjacency.
Candidates describe the DIS as a DR/BDR-style election with a priority tie-break and preemption, and expect a full mesh of adjacencies on a broadcast LAN.
They transfer OSPF DR/BDR behaviour to IS-IS. In IS-IS there is no BDR, the DIS election is preemptive (a new higher-priority router immediately takes over), the DIS is identified by the pseudonode LSP, and all routers on the LAN form adjacencies with each other (IS-IS uses a full mesh, not OSPF's partial mesh).
What to do instead
Memorise the differences: no backup DIS, preemptive election by priority then highest SNPA/MAC, DIS generates the pseudonode LSP (system ID of DIS plus a non-zero pseudonode ID) representing the LAN. On SR OS, verify with 'show router isis adjacency' and 'show router isis database detail' to see the pseudonode LSP and confirm which router is DIS.
Candidates assume an LSP is flooded only to routers in the same area, or conversely that Level 1 LSPs cross area boundaries freely, and they misread the ATT (attached) bit and default route behaviour.
They do not distinguish Level 1 flooding (within an area, using Level 1 LSPs) from Level 2 flooding (the backbone, using Level 2 LSPs). They also forget that a Level 1/2 router sets the ATT bit in its Level 1 LSP to signal it can reach other areas, and that Level 1 routers install a default route toward the nearest attached router.
What to do instead
Draw the flooding scope for each LSP type: Level 1 LSPs stay in the area, Level 2 LSPs flood the backbone, and only the Level 1/2 router leaks reachability via the ATT bit and a default route. On SR OS, inspect the ATT bit in 'show router isis database detail' and confirm the default route with 'show router route-table'.
Candidates compute SPF by hand and pick the path with the lowest total metric without checking whether the route is Level 1, Level 2, or a leaked/attached default, and without respecting the Level 1 preference over Level 2.
They treat IS-IS like a single flat IGP. In practice the router prefers intra-area Level 1 routes, then Level 2, then inter-area, and leaked routes carry specific semantics. Candidates also forget that SPF runs separately per level and per topology.
What to do instead
Work through a small topology twice: once as Level 1 and once as Level 2, and note that a Level 1/2 router prefers Level 1 for intra-area destinations. On SR OS, use 'show router isis routes' and 'show router route-table protocol isis' to confirm which level installed each prefix, and check the metric type (internal vs external) before choosing a path.
Candidates configure or reason about metrics as if IS-IS only supports the narrow 6-bit metric, and they mix up narrow and wide metric behaviour when a link exceeds the narrow maximum.
Narrow metrics are 6 bits (0-63) and the TLV layout differs from wide metrics (up to 24 bits per link, plus traffic-engineering sub-TLVs). If one router advertises wide metrics and another narrow, the result is inconsistent or ignored metrics, and narrow metrics silently cap at 63.
What to do instead
State the limits explicitly: narrow 0-63, wide up to 16,777,215 per link, and note that wide metrics are required for TE extensions. On SR OS, set 'level-capability' and 'wide-metrics-only' consistently across the domain, and verify with 'show router isis interface detail' and the metric TLVs in 'show router isis database detail'.
Candidates enable IPv6 and assume it is automatically carried in the existing single-topology IS-IS, or they enable multi-topology without checking that all routers in the area support it.
Single-topology IS-IS can carry IPv6, but it forces IPv4 and IPv6 to share one SPF and one set of adjacencies, which breaks when link addresses differ per family. Multi-topology (MT) requires consistent support; a router without MT support will not form the expected adjacencies or will ignore MT TLVs.
What to do instead
Decide per design: single-topology (IPv6 over the same adjacencies, one SPF) versus multi-topology (separate MT ID 2 for IPv6, independent SPF). On SR OS, configure 'ipv6' and 'multi-topology' under the IS-IS instance and interface as required, then verify with 'show router isis adjacency' and 'show router isis database detail' for MT TLVs, and confirm IPv6 routes in 'show router route-table ipv6'.
Candidates troubleshoot a missing route by checking only the interface state and never look at the link-state database for the expected LSP, its sequence number, or whether it is being flooded.
IS-IS convergence depends on LSP generation, flooding, and SPF in sequence. A route can be missing because the LSP was never generated (no prefix advertised), was rejected (MTU/authentication), or was not flooded (adjacency down or overload bit set).
What to do instead
Follow the pipeline: adjacency up, LSP generated with the prefix, LSP flooded to all routers, SPF run, route installed. On SR OS, use 'show router isis adjacency', 'show router isis database detail' (check sequence number and prefixes), 'show router isis status' (check overload bit), and 'show router route-table protocol isis' in that order.
Candidates set the overload bit or rely on it without understanding that it makes the router a transit-only exception, and they misjudge how it affects traffic during maintenance.
The overload bit tells other routers not to use this router as a transit hop for prefixes it does not originate, but it still advertises its own directly connected prefixes. Candidates assume it removes the router from routing entirely or that it stops all traffic.
What to do instead
State the effect precisely: overload excludes the router from transit paths while its own prefixes remain reachable. On SR OS, set it with 'set-overload' under the IS-IS instance (optionally with a timer or on-boot delay) and verify with 'show router isis status' and by checking the OL bit in 'show router isis database detail'.
Candidates treat the SR OS IS-IS configuration as a set of independent knobs and forget the required hierarchy: an IS-IS instance, an interface with an interface-type, and a level-capability, plus the NET on the instance.
SR OS uses a strict CLI hierarchy (configure router isis, then interface, then level settings), and omitting the interface-type (point-to-point vs broadcast) or the NET prevents the adjacency or the LSP from forming. Candidates also forget that the interface must be added to IS-IS explicitly.
What to do instead
Memorise the minimum working config: 'configure router isis ' with 'area-id'/'system-id' (or a NET), 'level-capability', then 'configure router isis interface ' with 'interface-type point-to-point' or broadcast and the appropriate level settings. Verify with 'show router isis interface' and 'show router isis adjacency' before moving on to route checks.