Nokia IS-IS Routing Protocol common mistakes
Nokia IS-IS Routing Protocol · Understand the traps and how to avoid them.
Treating IS-IS Level 1 and Level 2 as a simple hierarchy analogous to OSPF areas, and assuming an L1 router automatically learns all inter-area prefixes.
Candidates map IS-IS levels onto OSPF area concepts and assume L1 acts like a totally stubby area by default, missing that L1 routers only get a default route toward L2 unless the L1/L2 router sets the attached bit or exports prefixes with route leaking.
What to do instead
Learn the rule explicitly: L1 routers build an L1 LSDB with intra-area routes plus a default toward the nearest L1/L2 router (via the ATT bit); inter-area prefixes require route leaking on the L1/L2 router. Practice tracing how a packet from an L1-only router reaches a remote L2 prefix and identify where the ATT bit or leak appears.
Confusing the DIS election on broadcast networks with an OSPF DR/BDR election, expecting a backup DIS and preemption by a newly arrived higher-priority router.
OSPF habits carry over: candidates assume a BDR exists and that a higher-priority router immediately takes over. In IS-IS there is no backup DIS, and the DIS is not preempted until it fails or the interface goes down; the DIS also advertises pseudonode LSPs on behalf of the segment.
What to do instead
Memorize the differences: one DIS per broadcast segment, no backup, no preemption, priority 0 still participates (unlike OSPF priority 0), and the DIS originates the pseudonode LSP with the system ID plus nonzero circuit ID. Drill the election tie-breakers (priority, then highest SNPA/MAC) and the effect of the pseudonode on SPF.
Misreading the NSAP/NET address structure and misplacing the system ID, area ID, or AFI bytes when validating a configuration.
The address is written as a single hex string, so candidates split it arbitrarily instead of applying the rule: AFI (1 byte, 49 for private), area ID (variable), system ID (typically 6 bytes), NSEL (1 byte, 00 for a router). They also forget that all routers in one area share the area ID and that the system ID must be unique and is what forms the LSP ID.
What to do instead
Practice decomposing NETs of differing area lengths (e.g., 49.0001.1921.6800.1001.00 vs 49.0001.0002.1921.6800.1001.00), stating each field and its length. Check that the NSEL is 00, the system ID is 6 bytes for Cisco/Nokia-style deployments, and that the LSP ID is system ID plus circuit ID plus fragment number.
Assuming IS-IS runs directly over IP or that it requires a specific Layer 3 protocol, and misidentifying the encapsulation and adjacency requirements on point-to-point versus broadcast links.
IS-IS is an ISO protocol that runs directly over Layer 2 (802.3/802.2 LLC on LAN, HDLC/PPP on WAN), independent of IP. Candidates coming from OSPF expect IP protocol 89-style transport and overlook that IP connectivity is not needed to form an adjacency, only consistent L2 and matching level/area.
What to do instead
State the encapsulation explicitly: LLC SAP 0xFE on LAN, and the fact that IS-IS PDUs are not IP packets. Then list adjacency requirements per media: matching area ID for L1, matching levels enabled, matching authentication, MTU sufficient for hellos and LSPs, and unique system IDs. Test yourself by explaining how two routers with no IPv4 reachability can still be IS-IS neighbors.
Mixing up the PDU types and their functions, e.g., saying LSPs are exchanged in hellos or that CSNPs carry full LSP contents like PSNPs.
The nine PDU types (IIH for L1/L2/P2P, LSP, CSNP, PSNP) look similar on the wire, and candidates memorize names without the role each plays in database synchronization: IIH for neighbor discovery, LSP for topology/prefix data, CSNP for database summary, PSNP for acknowledgment and requesting missing LSPs.
What to do instead
Build a table mapping each PDU to its purpose and its scope (point-to-point vs broadcast, L1 vs L2). Specifically note that on point-to-point links there is no DIS and no pseudonode, and that CSNPs are sent periodically by the DIS on broadcast links while PSNPs acknowledge and request. Practice describing the full adjacency bring-up sequence on both media.
Forgetting that IS-IS prefixes are carried in TLVs and that narrow metrics cannot exceed 63 per link, then misdiagnosing a path that looks valid but is not selected.
The original IS-IS metric field is 6 bits, giving a maximum of 63 per interface, and candidates configure or reason about larger values without enabling wide metrics. They also overlook that IPv4 and IPv6 reachability use different TLVs (132 vs 236/237) and that metric style must be consistent across the area for correct SPF.
What to do instead
Memorize the narrow metric limit (1-63, with 0 reserved) and that wide metrics (up to 2^24-1) require consistent configuration. Practice reading a TLV breakdown: TLV 22 for extended IS reachability, TLV 135 for extended IP reachability, TLV 236/237 for IPv6. When a path is not chosen, check metric style mismatch and TLV presence before assuming a design error.
Ignoring the overload (OL) bit and its effect, and misinterpreting why traffic avoids a router that is actually up and forwarding.
The overload bit is set in the LSP header and tells other routers not to use the node for transit; candidates see the router in the LSDB and assume it is fully usable. They also forget that overload can be set manually or automatically (e.g., during startup or due to resource exhaustion) and that some implementations still allow it to be used for directly attached prefixes.
What to do instead
Learn the overload bit semantics precisely: transit traffic is avoided, but prefixes directly connected may still be reachable depending on configuration (e.g., overload-bit-on-startup with a timeout). Practice reading an LSP header and identifying the ATT, OL, and partition-repair bits, and explain the resulting SPF behavior for each.
Treating authentication as a single global setting and missing the per-level and per-PDU-type scope, then failing to explain why an adjacency stays down despite matching passwords.
IS-IS authentication can be applied to hello PDUs, LSPs, CSNPs, and PSNPs, and separately for Level 1 and Level 2, with plaintext or MD5 (and HMAC-SHA in newer implementations). Candidates configure one level and expect both to work, or mismatch the authentication type between neighbors.
What to do instead
Memorize the matrix: authentication scope (per level, per PDU type) and type (cleartext, MD5, HMAC-SHA). When an adjacency fails, check that both neighbors use the same type and key for the relevant level's IIH, and that LSP/SNP authentication matches if database synchronization fails after adjacency comes up. Practice a troubleshooting sequence that isolates hello authentication from LSP authentication.
Assuming SPF runs identically to OSPF and that partial SPF or PRC behavior is the same, then mispredicting convergence after a single link change.
IS-IS separates topology from reachability, so a prefix-only change triggers a partial route calculation rather than a full SPF, and a topology change triggers full SPF. Candidates apply OSPF mental models and expect full SPF for every change, or miss that L1 and L2 run independent SPF computations.
What to do instead
Learn the distinction: full SPF on topology change (new/removed adjacency, pseudonode change), partial route calculation on prefix metric or reachability change. Note that L1 and L2 maintain separate LSDBs and SPF processes, so a change in one level does not recompute the other. Practice classifying sample events as full SPF vs PRC and stating which LSDB is affected.
Overlooking the MTU and LSP fragment size constraints, then failing to explain why a large LSP is not flooded or why an adjacency flaps on a link with a smaller MTU.
IS-IS hellos can be padded and LSPs can be large; if the link MTU cannot carry the PDU, the adjacency may come up but flooding fails or the session resets. Candidates focus on hello timers and authentication and ignore MTU and LSP fragmentation (256 fragments, each up to the interface MTU minus overhead).
What to do instead
Include MTU in every adjacency and flooding checklist: verify interface MTU on both sides, understand LSP fragmentation and the 256-fragment limit, and know that padding of hellos is optional but can expose MTU mismatches. Practice a scenario where the adjacency forms but the LSDB never synchronizes, and trace it to an MTU or fragmentation problem.