The Workings of OSPF And How It Actually Builds A Route Table
Most engineers know how to configure OSPF without really understanding what happens underneath. This is a protocol-level breakdown of LSAs, the LSDB, SPF, and area design — and why getting any of it wrong costs you in production.
Most engineers who run OSPF in production have a working mental model that goes something like this: routers send hellos, form neighbor relationships, exchange information about the network, and eventually everyone agrees on a routing table. That model is accurate enough to get through a configuration and pass a certification exam. It’s not quite accurate enough to confidently troubleshoot a network where OSPF is misbehaving, or to design an area structure that won’t cause you problems two years down the road when the network has grown past what you initially planned for.
OSPF is defined in RFC 2328 for IPv4 and RFC 5340 for IPv6, and the protocol has been running production networks since the late 1980s. What makes it interesting to actually understand rather than just configure is that the decisions baked into its design, the link-state model, the area hierarchy, the different LSA types and their flooding scopes, all of them exist for specific reasons. When you understand the reasons, the behavior makes sense. When you don’t, OSPF feels like it has arbitrary rules that occasionally produce unexpected results.
Link-state versus distance-vector, and why it matters
The first thing to internalize is that OSPF’s fundamental approach to routing is different from older protocols like RIP, and different in a way that explains a lot of the protocol’s behavior. Distance-vector protocols share routing tables. Each router tells its neighbors what destinations it can reach and how far away they are, and those neighbors incorporate that information into their own tables and pass it along. The whole domain builds up a picture of reachability through this chain of updates, but no individual router ever has a complete picture of the actual network topology. They only know what they’ve heard from their neighbors.
OSPF is a link-state protocol, which means every router in an area floods information about its own directly connected links to every other router in the same area. Not routing table entries, actual topology information. What interfaces do I have, what are they connected to, what is the cost to reach them. The result is that every router in an area builds an identical map of the entire area’s topology, stored in what’s called the Link-State Database, and then independently runs Dijkstra’s Shortest Path First algorithm against that map to calculate the best path to every destination. Because every router is working from the same topology data and running the same algorithm, they reach consistent conclusions independently, without relying on what their neighbors think the best path is.
This is why OSPF converges faster and more reliably than distance-vector protocols in most scenarios. When something changes, the affected router immediately floods updated information, every other router receives it, runs SPF, and updates its routing table. There’s no slow propagation of routing table updates hop by hop, and there’s no count-to-infinity problem where routers can temporarily loop while they reconcile conflicting beliefs about the network.
What LSAs actually are
Link-State Advertisements are the individual pieces of topology information that OSPF routers generate and flood through the network to build the LSDB. Each LSA is a specific type of record describing something about the network, and understanding what each type contains and where it gets flooded is what actually explains OSPF’s behavior in multi-area designs.
A Type 1 Router LSA is generated by every OSPF router to describe itself: what interfaces it has, what neighbors it’s adjacent to on each interface, and what the OSPF cost is to reach each one. These stay within the area they originate in. They don’t cross area boundaries. Every router in an area receives every other router’s Type 1 LSA, which is how the complete intra-area topology map gets built.
On multi-access network segments like Ethernet, where you might have several OSPF routers connected to the same subnet, having every router form a full adjacency with every other router would be wasteful. If you have five routers on a segment, that’s ten adjacencies, and every topology change would need to be flooded between all of them individually. OSPF solves this by electing a Designated Router and a Backup Designated Router on each multi-access segment. All other routers on the segment form adjacencies only with the DR and BDR rather than with each other. The DR generates a Type 2 Network LSA representing the entire multi-access segment and the routers attached to it. This is why OSPF priority configuration matters in production: if the wrong router gets elected as DR because no one thought about it during design, and that router is underpowered or flapping, the entire segment feels the impact.
Type 3 Summary LSAs are where inter-area routing gets interesting. When an Area Border Router sits at the boundary between two areas, it doesn’t flood the full topology of one area into the other. It summarizes the reachable prefixes from one area and advertises them as Type 3 LSAs into the adjacent area. Routers in that receiving area see a Type 3 LSA telling them a certain prefix is reachable via the ABR at a certain cost, but they don’t see the individual routers and links inside the originating area. This is a deliberate and important design choice. It means a topology change deep inside Area 1 triggers a full SPF recalculation only among routers in Area 1. Routers in Area 2 receive at most a Type 3 LSA update if the reachability or cost changes, which requires only a partial SPF recalculation rather than a full one.
Type 4 and Type 5 LSAs handle external routes, meaning routes redistributed into OSPF from another routing protocol like BGP or EIGRP. A router doing that redistribution is an AS Boundary Router. It generates Type 5 External LSAs for the redistributed prefixes, and those flood throughout the entire OSPF domain across all areas. The Type 4 ASBR Summary LSA, generated by ABRs, tells routers in other areas how to reach the ASBR itself so they know where to send traffic for those external destinations. Type 7 LSAs are a variant used in NSSA areas, which exist precisely to handle the situation where you want stub-area behavior but also need to redistribute external routes locally. The Type 7 gets translated to a Type 5 by the ABR when it crosses into the rest of the domain.
The LSDB and how SPF turns it into a routing table
Every router in an OSPF area maintains a Link-State Database containing all the LSAs it has received. Routers in the same area have identical LSDBs because OSPF’s reliable flooding mechanism ensures that every LSA reaches every router. When a router needs to calculate its routing table, it runs Dijkstra’s algorithm against this database.
The way SPF works is that the calculating router places itself at the root of a tree and then incrementally builds out the shortest path to every other node in the topology. It starts with nodes directly connected to itself, with costs equal to its own interface costs. It then looks at what’s reachable from those nodes, calculates the total cost to reach them through the tree, and picks the minimum cost paths, adding those nodes to the tree one by one. The result is a Shortest Path Tree rooted at the calculating router that shows the lowest-cost path to every other router and network in the area.
The cost metric OSPF uses is based on interface bandwidth by default, calculated as 100 Mbps divided by the interface bandwidth. A FastEthernet interface has a cost of 1, a T1 has a cost of 64, and a 10 Mbps interface has a cost of 10. This formula made sense when 100 Mbps was the high end of common interface speeds. On modern networks where gigabit and ten-gigabit interfaces are standard, the default reference bandwidth gives everything at or above 100 Mbps a cost of 1, which means SPF can’t distinguish between a gigabit path and a ten-gigabit path. Explicitly setting auto-cost reference-bandwidth to a value above your highest-speed links, typically 10000 for networks with 10G interfaces or 100000 for 100G environments, is not optional on any modern network running OSPF for traffic engineering purposes. It’s one of those settings that gets missed during initial deployment and then causes subtle suboptimal routing that’s genuinely annoying to diagnose later.
Why areas exist and how to design them
A single OSPF area containing all your routers sounds simpler, and for a small network it genuinely is. The problem emerges with scale. Every router in an area must store the complete LSDB for that area and run the full SPF algorithm every time a link-state change occurs anywhere in the area. Put a few hundred routers in a single area and you’re looking at a large LSDB consuming real memory on every router, full SPF calculations across the entire domain on every topology change, and LSA flooding reaching every single router for every event. A flapping interface on the other side of the network is everyone’s problem.
Areas solve this by containing the blast radius. Type 1 and Type 2 LSAs stay within their originating area. A topology change in Area 1 triggers SPF recalculation only on routers inside Area 1. Routers in Area 2 see at most a Type 3 LSA update if the reachability or cost changes at the inter-area level. The flooding and computation are scoped to where they’re actually relevant.
Area 0, the backbone area, is mandatory in any multi-area OSPF design. All inter-area traffic must transit Area 0, which means every non-backbone area must have at least one ABR with a direct connection to Area 0. The reason for this rule is loop prevention. OSPF’s inter-area routing behaves more like a distance-vector protocol than a link-state one at the area boundary level. ABRs summarize reachability across area boundaries without exposing full topology. Without the requirement that all inter-area traffic flows through Area 0, routing loops between areas become a real possibility. If you ever find yourself considering a virtual link to connect a non-backbone area to Area 0 because there’s no physical path available, treat that as a strong signal that something is wrong in your physical or logical design rather than a configuration technique to reach for routinely.
Stub areas are a tool for reducing the LSDB size in areas that have a single exit point and no need for external route information. When you configure an area as stub, the ABR blocks Type 4 and Type 5 LSAs from entering the area and instead injects a default route. Routers inside the stub area use that default for anything outside their own area. If your area has branch routers with one upstream path and they don’t need to know about the full set of redistributed external routes flooding the OSPF domain, a stub area dramatically reduces their routing table and LSDB size. A totally stubby area takes this further by also blocking Type 3 inter-area LSAs, leaving routers with only their local area routes and a single default route for everything else. That’s the right choice for edge routers where you want minimal routing overhead and a simple “send everything up the pipe” behavior.
NSSA, which stands for Not-So-Stubby Area, is for the specific scenario where you want stub behavior to keep external LSAs from flooding in from the rest of the domain, but you also have a router in that area that needs to redistribute routes into OSPF locally. An ASBR in a normal stub area is a contradiction because stub areas don’t allow external route redistribution. NSSA resolves this by letting the local ASBR generate Type 7 LSAs instead of Type 5s. Those Type 7s flood within the NSSA only, and the ABR translates them to Type 5s when they need to cross into the rest of the domain. The result is that the area gets the reduced external LSA flood it wanted from the backbone, while still being able to advertise its own locally redistributed routes outward.
The adjacency state machine and what goes wrong in it
OSPF neighbor formation follows a state machine, and when things go wrong with adjacency formation, knowing the states tells you exactly where the problem is.
Routers start in the Down state for a neighbor and move to Init once they receive a Hello from that neighbor. They reach 2-Way once the Hello exchange confirms bidirectional communication, meaning they can see their own Router ID in the neighbor’s Hello packet. On point-to-point links, routers proceed from 2-Way directly toward establishing a full adjacency. On multi-access segments, only the DR and BDR form full adjacencies with other routers. Non-DR non-BDR routers stay at 2-Way with each other, which is correct behavior, not a problem.
Full adjacency establishment goes through ExStart, where the master-slave relationship for database exchange is negotiated, then Exchange, where Database Description packets are exchanged to synchronize what LSAs each router has, then Loading, where missing LSAs are requested and received, and finally Full, which is the stable state where both routers have identical LSDBs and the adjacency is complete.
When you see a neighbor stuck in ExStart, the most common causes are an MTU mismatch between the two interfaces or a mismatched Router ID. ExStart is also where you first see issues caused by certain types of firewall or security appliances in the path that interfere with OSPF protocol 89 packets. When a neighbor is stuck in Loading for an extended period, it usually means LSA requests are being sent but the responses aren’t arriving, which points to a packet loss or filtering problem in the path. A neighbor that bounces repeatedly between Init and Down typically means Hellos are being sent but not received in both directions, which on a shared segment can indicate a unidirectional link problem.
How to troubleshoot OSPF when things go sideways
The practical debugging flow for most OSPF problems starts with the neighbor table. The output of show ip ospf neighbor on Arista EOS gives you the current state of every neighbor relationship and how long it has been in that state. A neighbor that isn’t showing up at all means either the physical or data link layer has a problem, or OSPF isn’t configured on that interface, or there’s a Hello parameter mismatch. The critical Hello parameters that must match between neighbors are the area ID, the authentication settings, the Hello and Dead intervals, and the network type. These don’t need to match across the entire domain, they only need to match between the two routers on a shared link.
Once neighbors are forming but routing is wrong, the LSDB is the next place to look. On Arista, show ip ospf database gives you a summary of all LSA types present and their counts. If you’re in a multi-area design and you’re not seeing expected Type 3 LSAs in an area, that points to a summarization or filtering problem at the ABR. If you’re seeing a large number of Type 5 LSAs that you didn’t expect, something is redistributing into OSPF in a way that wasn’t planned, and those LSAs are flooding everywhere. show ip ospf database external will show you the specific redistributed prefixes and which ASBR originated them.
For cost-related problems where traffic is taking a suboptimal path, show ip ospf interface shows the OSPF cost configured on each interface. If the costs are right on the interfaces but the routing table is still showing unexpected paths, the reference bandwidth issue mentioned earlier is usually the culprit, with multiple paths appearing equivalent in cost when they shouldn’t be.
A note on summarization
Summarization in OSPF happens only at ABRs, and only for inter-area routes. You cannot summarize Type 1 or Type 2 LSAs within an area, they flood in their full detail to every router in that area. What you can do is configure the ABR to aggregate the prefixes from one area before they’re advertised as Type 3 LSAs into other areas. This is important for two reasons: it reduces the number of LSAs that flood across the domain, and it reduces the size of routing tables in other areas. More importantly, it reduces the impact of topology changes. If an area has a /24 that gets advertised as a summary /22 at the ABR, a link flapping inside that area changes the cost of intra-area routes but doesn’t necessarily change the Type 3 /22 summary that the rest of the domain sees. The churn stays contained.
Route summarization should be designed in at the start of an OSPF deployment, which means allocating address space in a way that makes summarization possible. It’s extremely difficult to retrofit meaningful summarization onto an OSPF domain where the address space was assigned without any thought to summary boundaries. This is one of the lessons that takes getting burned once to really stick.
Why OSPF still runs the enterprise
Despite BGP’s expansion into datacenter fabrics and SD-WAN largely replacing MPLS in many enterprise WAN designs, OSPF remains the dominant IGP for enterprise campus and building networks. It’s well understood, universally supported, has a mature toolset for troubleshooting, and its convergence behavior is predictable. The RFC 2328 specification has been stable since 1998 and the protocol’s behavior is consistent across vendors in a way that newer protocols sometimes aren’t.
What gets engineers into trouble with OSPF isn’t usually the protocol’s limitations. It’s treating it as a black box that runs in the background and occasionally needs poking when neighbors go down. The engineers who run OSPF well understand what the LSDB actually contains, what SPF is doing when it runs, and what the different area types are actually protecting them from. With that understanding, the protocol’s behavior in unusual situations becomes predictable rather than mysterious, and the design decisions that make a domain scale cleanly become obvious rather than arbitrary.