Articles
OSPF Interview Questions: Adjacency States, LSDB Evidence, and Missing Routes
Practice OSPF interview questions with original adjacency, MTU, and LSDB exercises. Explain normal 2-Way states, missing routes, and forwarding-address checks.
OSPF interview questions become easier when you separate three claims: a neighbor has formed the expected adjacency, the relevant link-state information is present, and a usable route has been calculated and installed. Those claims require different evidence. A neighbor in Full state does not prove that every destination is reachable, and a neighbor in 2-Way state is not automatically broken.
For graph reasoning before the protocol exercises, try Find Shortest Paths in Road Network. A graph algorithm exercise helps with path costs; it does not reproduce OSPF's complete protocol behavior.
Evidence boundary: this article covers OSPFv2 and IPv4, with explicitly scoped Cisco diagnostics. Official sources establish protocol and implementation facts. Candidate reports: none are used to predict employer questions. The topology snapshots, outputs, and reasoning drills are original practice material, not production captures or evidence of live router testing.
OSPF interview questions: identify the stage before the fix
OSPF's neighbor state, link-state database, route calculation, and forwarding state describe different parts of routing. Official protocol fact: RFC 2328 defines neighbor states and adjacency formation separately from the routing-table calculation. RFC 2328
Preparation guidance: start every diagnosis with the router, interface, area, routing context, exact destination, and observation time. Then ask what should happen at that boundary. An area-scoped database comparison made against a different area can produce an apparent discrepancy that is not a failure.
A useful explanation follows this sequence: expected adjacency, observed neighbor state, relevant LSA, calculation prerequisites, installed route, and packet evidence. Do not skip directly from “I can ping the neighbor” to “OSPF must be healthy.” IP reachability and successful protocol exchange are different observations.
The same discipline applies to a fix. State the suspected cause, the evidence that could confirm it, and the narrow change justified by that evidence. A command that resets the process might change the symptoms without proving the diagnosis.
Exercise 1: when is 2-Way the correct result?
Original topology. Four routers share one broadcast Ethernet segment in area 0. R1 is the designated router, R2 is the backup designated router, and R3 and R4 are DROTHER routers. Their identities and roles are already established; this exercise is not asking you to predict an election.
R3's normalized neighbor snapshot is:
Neighbor R1: FULL/DR
Neighbor R2: FULL/BDR
Neighbor R4: 2-WAY/DROTHER
An interviewer asks whether R4 is stuck. The correct first question is whether this pair should form a full adjacency on this network type.
Official vendor fact: on broadcast networks, a DROTHER forms full adjacencies with the DR and BDR and can remain 2-Way with another DROTHER. Cisco also explains why a DR can show FULL/DROTHER for a fully adjacent neighbor. The role after the slash describes the neighbor; it is not a second neighbor-state label. Cisco neighbor states
Worked answer: R3-to-R4 is behaving as expected under the stated topology. R3's Full relationships with R1 and R2 provide the required adjacencies. Do not force all four routers into a full mesh simply because Full sounds healthier.
Change the topology and revisit the expectation
Original follow-up: replace the shared broadcast segment with a point-to-point link between R3 and R4. A persistent 2-Way relationship now needs a different explanation because the adjacency expectation has changed. Cisco distinguishes point-to-point behavior from the broadcast case. Cisco neighbor states
Before comparing outputs, inspect the effective network type at both ends. Do not infer it solely from the physical medium. A configuration can change the protocol's interpretation of that interface.
Preparation inference: the useful skill is conditional reasoning: “On this broadcast segment, these two DROTHERs need not reach Full; on the specified point-to-point link, I expect a full adjacency.” Memorizing a list of states without that topology qualification produces misleading diagnoses.
Neighbor states tell you which evidence to request
Official Cisco explanation: Init means a received Hello does not list the receiving router's ID. ExStart and Exchange concern database-description negotiation and exchange; Loading involves requests for required link-state information. Persistent failures at these stages point to different checks. Cisco neighbor troubleshooting
Preparation guidance: distinguish a transient state during convergence from a state that remains or repeatedly restarts. One snapshot immediately after an interface comes up cannot establish that a neighbor is permanently stuck.
| Observation | Discriminating next check |
|---|---|
| No expected neighbor | Verify OSPF participation, interface state, routing context, and whether valid Hellos arrive. |
| Persistent Init | Inspect both directions of Hello reception and whether each router lists the other. |
| 2-Way | Establish network type and DR/BDR roles before declaring a fault. |
| Repeated ExStart or Exchange | Inspect DBD exchange, MTU evidence, identities, and sequence behavior. |
| Persistent Loading | Inspect outstanding requests, updates, and acknowledgments. |
| Full but missing destination | Examine the relevant LSA and route calculation rather than restarting Hello diagnosis. |
This is a troubleshooting map, not a claim that each state has exactly one cause. The next observation should distinguish competing explanations.
Exercise 2: ExStart and an MTU discrepancy
Original evidence snapshot. R5 and R6 are intended to form a point-to-point adjacency in area 0. Valid Hellos are observed in both directions. The neighbor repeatedly returns to ExStart during database-description exchange.
R5 interface IP MTU: 1500
R6 interface IP MTU: 9000
Received DBD at R5 advertises interface MTU 9000
R5 log records rejection associated with that MTU
These are normalized synthetic observations, not a copied Cisco command capture.
Official vendor fact: Cisco documents an MTU mismatch as a cause of persistent ExStart/Exchange. The receiver can reject a database-description packet advertising an interface MTU larger than it can receive. The document also notes that multiple causes can produce these states. Cisco ExStart/Exchange troubleshooting
Worked answer: the stated DBD and rejection evidence support an MTU-related failure. Successful small Hellos do not contradict it. The failure is at database synchronization, after bidirectional discovery has been observed.
Ask which MTU the link and encapsulation actually support, then align the intended configuration and verify the exchange. Do not assume that increasing the smaller setting to 9000 is always the right repair. The path may only support a smaller packet size.
Why an ignore setting is not a diagnosis
Cisco documents ip ospf mtu-ignore, but bypassing a comparison is different from demonstrating that large traffic can traverse the link. Cisco ExStart/Exchange troubleshooting
Preparation inference: describe the supported MTU, the underlying mismatch, and a packet-size check before considering a workaround. After a repair, confirm that the neighbor reaches its expected state and that ordinary data traffic meets the link's requirements. A Full adjacency is evidence about the protocol exchange, not proof that every packet size works.
If the MTUs match and the logs do not show a rejection, abandon this hypothesis rather than insisting that every ExStart incident must be MTU-related. Request the DBD sequence and identity evidence indicated by the actual platform.
Full is scoped evidence, not an inventory of reachable prefixes
Official protocol interpretation: Full indicates completion of the adjacency's synchronization process. OSPF information and calculations have area and LSA-type scope; do not interpret Full as a promise that every route in every area is present or installed. RFC 2328
Original cost drill: within a supplied intra-area graph, the directed cost from R7 to R8 is 10 and R8 to R9 is 5. The direct R7-to-R9 cost is 20. Assume both paths are eligible and the destination's additional advertised cost is equal on both choices.
The path through R8 costs 15, so it beats the direct cost of 20 under these inputs. The fewest hops do not win this exercise. If the R7-to-R8 cost becomes 30, that path costs 35 and the direct path becomes preferable.
This arithmetic checks your graph reasoning; it does not model area preference, external metrics, or every OSPF tie. State those exclusions. The routing-table calculation is more than choosing the smallest number from an unrelated LSA listing.
Preparation guidance: compare the relevant link-state records and identities before attempting a calculation. An LSA identifier without its type, advertising router, area, and freshness information is incomplete evidence. Two similarly named records need not describe the same object.
Exercise 3: a Type-5 LSA exists, but its route is missing
Original normalized snapshot. R10 has a synchronized adjacency in the relevant routing context. Its database contains this external advertisement:
LSA type: 5
Destination: 203.0.113.0/24
Advertising router: 10.0.0.9
Forwarding address: 192.0.2.9
Metric type: 2; external metric: 20
Lookup for 192.0.2.9: only an OSPF external route
No usable intra-area or inter-area route for that address
What should you investigate before changing the external metric?
Official requirement: for a nonzero forwarding address in this external-route calculation, the required matching route must be intra-area or inter-area. Cisco demonstrates a Type-5 LSA whose route is not installed because its forwarding address is known only through an external route. Cisco route database troubleshooting, RFC 2328, section 16.4
Worked answer: the LSA's presence does not satisfy its forwarding-address prerequisite. Lowering metric 20 does not create the missing internal route. Investigate why the forwarding-address network is not reachable through the intended intra-area or inter-area path.
Do not substitute the advertising router's reachability for the nonzero forwarding address's reachability. They are different fields in this exercise. Likewise, a successful ping using some other routing mechanism does not demonstrate the specific route-type condition.
Original follow-up: if the matching route is repaired to an appropriate inter-area route, re-evaluate the external candidate with the remaining prerequisites and policies. This change removes the stated obstacle; it does not prove that no other obstacle exists.
Cisco also documents installation filtering that can leave an LSA in the database while preventing a corresponding routing-table entry. Keep database propagation and local installation policy separate. Cisco route database troubleshooting
Build a command-to-question ledger
Preparation guidance, using Cisco-style commands: use show ip ospf neighbor for the observed neighbor state and role, and show ip ospf interface for the interface's relevant OSPF settings. Use show ip ospf database and a suitably scoped LSA query for database evidence. Then inspect show ip route for the exact destination and any forwarding-address lookup. Syntax and additional qualifiers vary by platform.
Cisco's common-problem guide routes troubleshooting by neighbor and routing symptoms. It supports collecting targeted evidence before broad changes. Cisco common OSPF problems
End with a forwarding check for a specified source and destination. A router-originated probe may have a different source or context from the affected application. Verify the installed next hop, interface, packet path, and return route independently when the symptom is failed communication.
Your conclusion should name the proven stage: “The broadcast neighbor states are expected,” “DBD rejection supports the MTU diagnosis,” or “The external LSA lacks its required forwarding-address route.” That makes the answer reviewable and the next action specific.