Nokia 4A0-113 OSPF common mistakes
Nokia 4A0-113 OSPF · Understand the traps and how to avoid them.
Treating the OSPF router ID as an address that must be reachable, and expecting a router whose router ID is set to a loopback that is not in any OSPF area to fail adjacency formation.
Candidates carry over a BGP-style intuition that the identifier must be a valid, reachable address. In OSPF the router ID is only a 32-bit identifier used to break ties in DR election and to label LSAs; it does not have to be reachable or even configured on an interface.
What to do instead
Memorize the election order (explicit router-id, then highest loopback address, then highest active interface address) and the fact that it is chosen once at startup unless a change triggers a restart of the OSPF instance. Practice predicting the router ID from a given interface list, and remember that duplicate router IDs break the LSDB rather than the adjacency.
Assuming two routers with mismatched MTU will still form a FULL adjacency because the hello parameters match, and blaming the area ID when the adjacency sticks in ExStart.
The MTU is not carried in the hello; it is checked during the Database Description exchange. A mismatch therefore allows the neighbor to reach 2-Way and even ExStart, then the larger-MTU side's DBD packets are dropped, producing a silent stall rather than a clear error. Candidates who only check hello timers, area, and authentication miss it.
What to do instead
Learn the state-by-state signature: stuck in ExStart/Exchange points to MTU mismatch or a DBD sequencing problem, not to hello parameters. On Nokia SR OS, check the interface MTU and use the 'ignore-mtu' option on the OSPF interface only when intentionally tolerating a mismatch, and verify with the neighbor detail output that shows the negotiated MTU.
Believing that an area must be physically contiguous and that a virtual link is the normal way to fix a discontiguous area, rather than recognizing that a virtual link is a temporary repair for a partitioned backbone.
The rule that all non-backbone areas must touch Area 0 is learned as an absolute, so candidates reach for virtual links whenever an area is split. In practice a discontiguous area is a design error, and a virtual link only works when both endpoints have an interface in a common transit area and one endpoint is in Area 0.
What to do instead
Separate the two rules: virtual links repair a split backbone or attach a remote area across a transit area, and both ends must share the transit area. For a genuinely discontiguous non-backbone area, redesign with additional ABRs or tunnels. Be able to state the virtual link's transit area, the router ID of the far end, and that it must be configured on both routers.
Describing summarization as something an ABR does to any routes it knows, instead of restricting it to Type 3 LSAs generated for inter-area prefixes, and expecting it to suppress Type 1 or Type 2 LSAs.
The word 'summary' suggests aggregation of everything, but OSPF summarization is scoped by LSA type and by router role. Area range on an ABR aggregates Type 3 LSAs it originates into another area; it does not touch the intra-area LSAs inside the source area, and it cannot summarize external routes.
What to do instead
Build a table of which router and which LSA type each tool acts on: area range on an ABR for Type 3, ASBR summarization (export/aggregate policy) for Type 5 or Type 7, and no summarization of Type 1/2 at all. Practice the discard-route and cost behavior of a range, and remember that a more specific component still advertised elsewhere will still be preferred by longest match.
Assuming a stub area blocks all external information, then being surprised that Type 3 summary LSAs still appear in the stub area's database.
Stub and totally stubby are conflated. A stub area blocks Type 5 (and Type 7) LSAs but still receives Type 3 summaries from its ABR; a totally stubby area additionally blocks Type 3s except a default. Not-so-stubby areas reintroduce external information as Type 7.
What to do instead
Memorize the LSA types allowed per area type and the default route each generates: stub injects a default Type 3, totally stubby injects a single default Type 3, NSSA injects a default Type 7 (or Type 3 depending on configuration). Verify with the link-state database filtered by area and LSA type rather than trusting the configuration alone.
Explaining SPF as 'the shortest path wins' without distinguishing intra-area SPF over the router-LSA graph from inter-area and external prefix selection, and without noting that equal-cost paths are installed.
The exam tests the two-stage model: SPF builds the shortest-path tree to routers and networks within an area, then Type 3 and Type 5/7 prefixes are attached with their advertised costs and compared using preference rules. Candidates who collapse everything into one SPF calculation misanswer questions about why a shorter external path loses to an intra-area route.
What to do instead
Study the order of preference: intra-area, then inter-area, then Type 1 external, then Type 2 external, with the Type 1/Type 2 distinction depending on whether the external metric includes the internal cost to the ASBR. Practice tracing a route from the router-LSA graph through the summary and external advertisements, and note that ECMP installs up to the configured maximum.
Configuring OSPF areas and interfaces on Nokia SR OS but forgetting that the interface must be added to the OSPF instance with the correct area and interface type, then wondering why no hellos are sent.
SR OS separates the interface configuration (ports, SAPs, loopbacks) from the OSPF instance configuration. Adding an address to a port does not automatically put it into OSPF; the interface must be referenced under the OSPF instance with an area ID, and passive or point-to-point settings change the behavior.
What to do instead
Practice the full configuration path: create the router interface, then under the OSPF instance add the interface with its area, set the interface type where needed, and mark stub-facing or unneeded interfaces passive. Verify with the OSPF neighbor and interface operational commands that the interface is up, in the intended area, and exchanging hellos.
Assuming that changing an OSPF cost or timer on one side of a link takes effect immediately and symmetrically, without accounting for the need to reset the adjacency or for the fact that cost is per-interface and directional.
Cost is configured per interface and is used in the outbound direction of the SPF calculation, so the two directions can differ. Some parameter changes require the adjacency to be re-formed before the neighbor accepts them, and a change on one router does not alter the other router's cost.
What to do instead
Remember that cost is local and directional, and that the effective path cost is the sum of outbound costs along the path. After changing parameters that affect the hello or the database exchange, clear or bounce the adjacency and confirm the neighbor returns to FULL. Verify the resulting tree with the route and link-state database output rather than assuming the change propagated.
Configuring authentication on one neighbor only, or mixing plain-text and MD5 (or MD5 and SHA) on the two ends, and expecting the mismatch to be reported as an authentication error rather than as a silently dropped hello.
Authentication failures cause the hello to be discarded before any error is logged against the neighbor, so the adjacency simply never forms and the neighbor may not even appear. Candidates therefore chase area or MTU problems instead of checking the authentication type and key.
What to do instead
Treat authentication type and key as part of the hello parameter set that must match exactly on both ends, along with area ID, hello and dead intervals, and stub flags. When an adjacency will not form, compare all hello parameters first, then check MTU. On SR OS, verify the configured authentication type and key on the interface, and remember that key changes may require the adjacency to be reset.
Reading the link-state database as a list of routes, and concluding that a prefix is reachable because it appears in the LSDB, without checking whether the SPF calculation actually installed it in the routing table.
The LSDB holds topology and prefix advertisements, not forwarding decisions. A prefix can be present in the database but lose the preference comparison, be filtered by policy, or fail to be installed because the advertising router is unreachable in the SPF tree.
What to do instead
Separate the three views: the adjacency table (neighbors and states), the link-state database (LSAs and their advertising routers), and the routing table (installed routes with preference and metric). When troubleshooting, confirm the adjacency is FULL, then confirm the LSA is present and its advertising router is reachable, then confirm the route is installed and selected.