Understanding Network Infrastructure · Part 3 · How does traffic reach other networks and the Internet?
When a link fails, how does OSPF find a new route?
From Hello to LSDB synchronization, LSA flooding, and SPF recalculation: link-state convergence
OSPF routers establish neighbor relationships and exchange link-state information so that devices in the same area synchronize their LSDBs. Each router uses that topology to run SPF with itself as the starting point, then applies the result to its RIB and FIB. We follow Hello exchanges, neighbor states, LSA synchronization, area boundaries, and troubleshooting in the order that routes are built.
Routers exchange OSPF Hello messages—but what must match before they become neighbors?↑
An OSPF-enabled interface sends Hello packets to exchange the router ID, area, timers, and other information needed to form a neighbor relationship. If key parameters do not match, devices may see each other's packets without becoming valid neighbors.
Discovering a neighbor does not mean forming a Full adjacency with every peer. On a broadcast network, database synchronization centers on the DR and BDR to reduce unnecessary adjacencies. A 2-Way state is not always a fault; interpret it alongside the network type and peer's role.
Two routers exchanging Hello messages must meet the relevant neighbor conditions: area ID, network mask and type where applicable, Hello and dead intervals, authentication, and stub-related options. Platform logs may identify a mismatch; packet captures let you compare the Hello fields directly. Router IDs must be unique within the OSPF domain, or neighbor and LSA identification can become confused.
On a broadcast network, DROther routers normally discover each other in 2-Way without forming a Full adjacency. If neither device is the DR or BDR, treating 2-Way as “stuck” prompts unnecessary intervention. A point-to-point link, by contrast, may be expected to reach Full. Interpret neighbor states in the context of network type and peer role, and document the expected state for each interface.
On a broadcast network, the DR/BDR election means not every pair of routers needs to reach Full; 2-Way is normal for some pairs. Point-to-point and NBMA networks have different expected relationships. Do not diagnose a fault from the state name alone. Compare the interface network type, expected neighbor role, and both sides' Hello contents.
Sources for this section IETF RFC 2328 · IETF RFC 5709
Before neighbors reach Full, how do routers synchronize their LSDBs?↑
Adjacent routers use Database Description packets to compare summaries of their LSAs. They request needed LSAs with Link State Request messages, receive them in Link State Updates, and confirm receipt with Link State Acknowledgments.
Being stuck in ExStart or Exchange is different from simply having Hello messages blocked. Look for conditions that interfere with database exchange: interface MTU mismatches, duplicate router IDs, network type, authentication, or packet loss. The state identifies the stage where progress stopped.
ExStart establishes the master/slave relationship and DD sequence. In Exchange, Database Description messages compare LSA header lists. During Loading, requests, updates, and acknowledgments supply missing LSAs. Full means the database synchronization required for that adjacency is complete. The state that repeats helps separate Hello reception problems, DD negotiation failures, and trouble transferring a particular LSA.
A common example is two routers with different MTUs: they exchange Hello messages but cannot process Database Descriptions, so ExStart or Exchange repeats. Authentication mismatches, packet loss, and duplicate router IDs can cause similar stalls. Restarting the OSPF process may briefly restore progress and obscure the cause. Preserve state-transition logs, interface MTUs, and DD packet sequences and flags before comparing both configurations.
Repeated ExStart/Exchange transitions can point to MTU, router ID, or packet processing problems. A stall in Loading can point to a problem requesting or receiving a particular LSA. Confirm the cause with captures and logs. Correlate the times of neighbor state changes on both sides with DBD sequence numbers, MTU, and LSR/LSU/LSAck exchanges to narrow a vague report of an unstable adjacency to a specific failed state transition. Preserve the last known good state before restarting.
Sources for this section IETF RFC 2328
What to look for in the diagram Read the Hello parameter checks and the neighbor states from Down to Full. Then distinguish the DBD/LSR/LSU/LSAck exchange and LSDB synchronization boxes from each router's local SPF calculation, RIB selection, and FIB installation. Neighbor state and the local calculation needed for forwarding are separate stages.
↔ Scroll horizontally to explore the diagram.
A link fails. How do LSAs carry the news throughout an area?↑
Router and network connectivity, prefixes, and external routes are described by the appropriate LSA types. Each LSA includes its originator, link-state ID, sequence number, and age so routers can distinguish newer information.
A new LSA is flooded onward by the receiving router according to neighbor and interface state and DR/BDR roles. Not sending it back to the sender is different from excluding the entire receiving interface. A DR on a shared network may forward it to other neighbors on that same interface. When reading captures, consider the sending neighbor, receiving interface, and DR/BDR roles together.
When a router detects a link going down, it updates the relevant LSAs it originates with newer sequence numbers and floods them over its adjacencies. A neighbor compares the information with its existing LSDB entry, stores it if it is newer, and forwards it to other neighbors. Acknowledgments and retransmissions improve flooding reliability when packets are lost. Distance-vector protocols advertise distances and route information to neighbors, which use that information to calculate their own routes. Rather than simply accepting a neighbor's calculated route, OSPF distributes link-state information so each router can calculate its own paths.
An LSA's flooding scope depends on its type and area boundaries. Not every LSA spreads across the entire AS in the same way; ABRs and ASBRs may originate other forms of information. Age and sequence numbers prevent stale information from replacing newer facts. During an outage, go beyond the routing table. For the failed link's LSA, compare the advertising router, sequence, and age across LSDBs to locate differences in origination or flooding.
An LSA's type, link-state ID, advertising router, sequence, age, and checksum identify an entry and help determine which instance is newer. LSAs do not propagate without limit through every area and beyond; scope depends on LSA type and area type. Instead of searching only for a prefix, identify the relevant LSA and its originator, then compare the sequence and age seen in each router's LSDB.
Sources for this section IETF RFC 2328
With the same LSDB, each router still calculates routes from its own position↑
When the LSDB changes, the router runs shortest path first with itself as the root. It adds link costs to build a shortest-path tree, then derives next hops and outgoing interfaces. Results that satisfy routing policy and installation conditions enter the RIB and are applied to the FIB.
LSA arrival times, SPF scheduling, CPU load, and FIB programming time can leave a gap between control-plane convergence and the actual packet path change. Shortening failure detection alone does not reduce end-to-end interruption by the same proportion.
Even with identical LSDBs, routers root the tree at themselves, so their next hops differ by location. Router A may choose a path with total link cost 20, while router B uses another neighbor for the same destination. SPF turns prefixes into route candidates that compete with other protocol routes in RIB selection before FIB installation. Identical LSDBs do not imply identical router routing tables.
As a link change propagates, differences between routers in LSA arrival, SPF execution, and FIB programming times can briefly create microloops or blackholes. Features such as SPF throttling, LSA pacing, and fast reroute affect this interval, but their defaults and effects vary by implementation. When measuring convergence, do not record only the time of neighbor loss. Distinguish new LSA origination, remote receipt, SPF completion, FIB changes, and end-to-end packet delivery recovery.
An LSDB prefix is not guaranteed a place in the RIB. A more-preferred static or connected route may win, a recursive next hop may not resolve, or a different OSPF path may be selected. Trace SPF timing and results, competing RIB routes, the FIB, and adjacency to distinguish topology knowledge from usable forwarding. Compare the number of installed equal-cost paths with the configured limit too.
Sources for this section IETF RFC 2328
How do areas limit the scope of topology changes and the LSDB?↑
Within one area, routers share link-state information. An area border router can advertise summary information to another area instead of replicating the detailed topology. Backbone area 0 connects the other areas.
Creating more areas does not always speed convergence. Design ABR placement, summarization boundaries, redundancy, and external-route entry points together. Stub area variants restrict the LSAs they accept; exact behavior varies with implementation and area type.
An area's internal routers share its detailed area topology, while an ABR advertises summary information to other areas. This can keep a branch access link change from reaching every area's routers as the same detailed LSA. But concentrating all connections on one ABR across areas, or using unstable summaries, can create bottlenecks and incorrect routes. Boundary placement and redundancy matter more than the number of areas.
Stub areas, vendor variants such as totally stubby areas, and NSSAs differ in how they accept external LSAs and provide a default route. Mismatched area types may prevent adjacency or leave expected external routes missing. A summary can remain after some child prefixes disappear, so test discard routes and partial failures. Area design determines route visibility and failure propagation, not just LSDB size.
OSPF inter-area routing is organized around a logically contiguous Area 0. Where the required conditions are met, virtual links can connect physically separated backbone sections. The actual forwarding path can then include links in a nonbackbone area; this does not mean every packet traverses only physical Area 0 links. Define area boundaries by considering ABR capacity and redundancy, LSA types and propagation scope, and the detailed and default routes required.
Sources for this section IETF RFC 2328 · IETF RFC 5340
What to look for in the diagram Follow the Area 1, area 0, and External Domain boxes, distinguishing Type 3 summaries from ABRs and Type 5 external LSAs from ASBRs. In this multi-area example, compare the area-local propagation of Types 1 and 2 with the inter-area flooding scopes.
↔ Scroll horizontally to explore the diagram.
Missing an OSPF route? Check neighbors, then the LSDB, RIB, and FIB↑
Scenario: After a link failure, some routers select a new path while other routers retain the old one.
- In the affected area and on the affected interface, record neighbor state, router IDs, and DR/BDR roles.
- Compare both sides' Hello and dead timers, area IDs, authentication, network types, and MTUs.
- For the changed LSA, compare the advertising router, sequence number, and age in each router's LSDB.
- Check SPF execution time and results, then the selected OSPF route's cost and next hop.
- Check whether a route exists in the RIB but not the FIB, or another source or policy won selection for the same prefix.
- Align packet captures and device logs to measure detection, flooding, calculation, and installation separately.
After confirming that two routers' neighbors are Full, do not jump straight to checking for a route. Find the prefix's originating LSA in the source router's LSDB, then check whether the same sequence reached neighboring and remote routers. Next, inspect each router's SPF results, OSPF RIB candidate, global RIB, and FIB, in that order. This separates adjacency, flooding, calculation, route selection, and installation problems.
When reproducing an outage, use interface down or a cost change as the reference event and align packet-capture and log clocks. A more-preferred static or BGP route may beat the OSPF candidate, or unresolved next-hop ARP may prevent usable FIB forwarding. After a fix, do not stop at neighbor Full. Test actual forwarding for the affected prefix and its return path. After rollback, check for unwanted leftover LSAs and routes.
This sequence distinguishes failure to form a neighbor relationship, inconsistent databases, a missing LSA, exclusion during SPF/RIB selection, and a data-plane problem. Align all routers' clocks in the evidence so the order of LSA flooding and route changes is preserved.
Sources for this section IETF RFC 2328
FAQ↑
Is a neighbor in 2-Way always a fault?
Glossary↑
Sources and verification
- IETF RFC 2328 — OSPF version 2 packets, LSAs, areas, and SPF
- IETF RFC 5340 — IPv6 support in OSPF version 3
- IETF RFC 5709 — OSPFv2 HMAC-SHA authentication extensions
OSPF timers, LSA throttling, SPF scheduling, ECMP limits, and FIB updates depend on the platform and configuration. This article focuses on RFC 2328 states and packet exchanges.