Nokia NRS II Composite (OSPF) common mistakes
Nokia NRS II Composite (OSPF) · Understand the traps and how to avoid them.
Treating an OSPF neighbor stuck in ExStart/Exchange as a generic 'adjacency problem' and resetting the session repeatedly instead of diagnosing MTU mismatch.
Candidates memorize the state names but not what each state negotiates. ExStart is where the master/slave relationship and initial DD sequence number are agreed; if the two routers cannot agree on an MTU that fits the Database Description packets, the exchange stalls and the session flaps back to ExStart. Because the routers do form a two-way relationship, the failure looks like 'almost working', which tempts a reset rather than a config comparison.
What to do instead
On SR OS, verify interface MTU with 'show router interface' and check OSPF interface parameters with 'show router ospf interface'. Confirm MTU matches on both sides (including any transport or L2 MTU that silently drops large frames), or configure 'mtu-ignore' only as a deliberate workaround. Learn the state-by-state failure signatures: Init = one-way hellos, ExStart/Exchange = MTU or DD negotiation, Loading = missing LSAs, Full = success.
Assuming any two routers that exchange Hellos will become adjacent, without checking that area ID, Hello/Dead intervals, authentication, and area type all match.
The Hello packet carries many fields and candidates often check only the area ID and network mask. Mismatched Hello/Dead timers, authentication type or key, stub/NSSA flag, or MTU-related options silently prevent the neighbor from progressing past Init or 2-Way. On broadcast segments, a mismatch with a DR-eligible router is easy to miss because non-DR routers legitimately stay in 2-Way.
What to do instead
Compare the full Hello contents on both sides: area ID, interface address/mask, Hello and Dead intervals, options field (E-bit for stub, N/P bits for NSSA), authentication type and key ID, and router priority. On SR OS use 'show router ospf neighbor detail' and 'show router ospf interface detail'. Remember that 2-Way is normal between DROther routers on a broadcast segment; only failure to reach Full with the DR/BDR is a fault.
Believing that a virtual link carries all traffic between the transit area and the backbone, and configuring it as a general-purpose tunnel.
Virtual links are commonly taught as 'connecting a discontiguous area', so candidates assume they forward user traffic or that they can transit a stub area. In reality a virtual link is a logical adjacency over the transit area's best path, used to extend the backbone (Area 0) so that Area 0 LSAs and inter-area routes can pass. It must transit a normal (non-stub, non-NSSA) area and both endpoints must be ABRs with a common area.
What to do instead
Configure the virtual link on both ABRs with the transit area ID and the remote router ID, and confirm the transit area is not stub or NSSA. Verify it with 'show router ospf virtual-link' and confirm the adjacency reaches Full. Explain that the virtual link is part of the backbone topology, not a data tunnel, and that the transit area must have full reachability between the endpoints.
Expecting a default route to be injected into a totally stubby area by redistributing a static default, rather than by the ABR's no-summary behavior.
Candidates conflate stub, totally stubby, and NSSA behavior. In a stub area the ABR injects a default via a Type 3 summary LSA; in a totally stubby area it also suppresses Type 3 and Type 4 LSAs and injects only the default. Redistributed externals are not allowed in stub or totally stubby areas at all, so a static default redistribution simply will not appear.
What to do instead
Map the area types explicitly: stub blocks Type 5 and uses an ABR-generated Type 3 default; totally stubby additionally blocks Type 3/4 and injects only a default; NSSA blocks Type 5 but allows Type 7 from an ASBR, translated to Type 5 by the ABR; totally NSSA blocks Type 3/4 and Type 5. On SR OS check 'show router ospf area' and 'show router ospf database' to see which LSA types are actually present.
Assuming ECMP will use all equal-cost paths without checking the SPF tie-breakers, the maximum-paths setting, and per-flow hashing behavior.
Candidates see multiple equal metrics and expect load sharing, but OSPF installs multiple next hops only when the paths are truly equal after tie-breaking, when the router's ECMP limit is not exceeded, and when the next hops differ. SR OS also has a configurable ECMP maximum and hashing behavior that may send a given flow down one path, so a single ping or iperf flow can look like no ECMP at all.
What to do instead
Verify with 'show router route-table ' and 'show router ospf routes' that multiple next hops are installed, and check the configured ECMP maximum and hash settings. Test with varied source/destination pairs or a tool that varies the flow tuple rather than a single stream. Remember intra-area SPF prefers lower-cost paths first, then tie-breaks on other criteria before ECMP is considered.
Configuring LFA and assuming it is active, without verifying that a loop-free alternate actually exists and that the protected interface and prefix are covered.
LFA requires a neighbor whose shortest path to the protected destination does not go through the calculating router, plus matching backup criteria. On ring or hub-and-spoke topologies the condition often fails, so LFA silently protects nothing. Candidates also forget that remote LFA or TI-LFA may be needed, and that the repair path must be enabled per interface or per area.
What to do instead
Check 'show router ospf interface' for LFA status and 'show router ospf routes' for the backup next hop on each prefix. Confirm the interface is included in the LFA policy and that the topology provides a valid alternate; where it does not, evaluate remote LFA or TI-LFA with a segment-routing or MPLS repair path. Test by failing the protected link and observing the repair path in the FIB.
Misreading the LSDB by confusing router-LSA link types and assuming a Type 4 summary LSA appears in every area.
Candidates memorize LSA numbers without understanding scope. Type 1 router LSAs describe links with types (point-to-point, transit, stub, virtual), Type 2 network LSAs are generated by the DR, Type 3/4 are ABR-generated and area-scoped, and Type 5 is domain-wide. A Type 4 (ASBR summary) is only generated into areas that need to reach an ASBR elsewhere, so its absence in some areas is normal, not a fault.
What to do instead
Practice reading 'show router ospf database' output by LSA type and area, and relate each LSA to the topology that generated it. Know which router originates each type and its flooding scope, and use 'show router ospf database detail' to inspect link types and advertising router IDs. Explain why Type 4 is absent in a stub area and why Type 7 appears only in an NSSA.
Configuring OSPF authentication on an interface but forgetting the matching key or key ID on the neighbor, then blaming the area or the adjacency logic.
Authentication failures drop Hellos, so the neighbor never appears or flaps between Down and Init, which looks like a reachability or area problem. SR OS supports simple password and MD5, with key IDs and optional key chains; a mismatched key ID or a key configured on only one side produces exactly this symptom, and candidates often check the area config but not the interface-level authentication block.
What to do instead
Compare the authentication type, key ID, and key value on both interfaces, and confirm whether a key chain is in use. On SR OS inspect 'show router ospf interface detail' for the authentication mode and verify the key chain configuration. Change keys in a coordinated way and remember that authentication is per-interface, not per-area, so one mismatched link can isolate a whole segment.
Expecting sub-second convergence from default OSPF timers, or tuning Hello/Dead timers without understanding the resulting failure-detection trade-off.
Default Hello/Dead intervals (10/40 s on broadcast, 30/120 s on point-to-point in many implementations) mean failure detection is slow, and candidates assume SPF itself is the bottleneck. Lowering timers speeds detection but increases control-plane load and the risk of false failures on congested or jittery links; BFD is the usual better answer. Candidates also forget that SPF and LSA throttling timers affect how fast the change propagates.
What to do instead
Use BFD for fast failure detection rather than aggressive Hello timers where the platform and link support it, and verify with 'show router bfd session'. Review LSA generation and SPF throttling parameters, and confirm that the adjacency and route change appear within the expected time after a link failure. Explain the detection-versus-stability trade-off and why timer values must match on both ends.
Treating OSPFv3 configuration as OSPFv2 with a different address family, missing that OSPFv3 runs per-link and uses link-local addresses and a separate instance/topology model.
Candidates carry OSPFv2 habits into OSPFv3: they expect network statements with IPv4-style wildcards, assume authentication is configured the same way (OSPFv3 relies on IPsec AH/ESP rather than the OSPFv2 authentication field), and overlook that OSPFv3 adjacencies form over link-local addresses and that multiple instances can share a link.
What to do instead
Configure OSPFv3 on the interface with an explicit area and instance, verify adjacencies with 'show router ospf3 neighbor' and interfaces with 'show router ospf3 interface', and confirm IPv6 link-local reachability. Use IPsec for OSPFv3 authentication rather than the OSPFv2 key model, and remember that router-ID and instance ID must be consistent for adjacencies to form.