OSPF Routes Not Appearing in Routing Table: Troubleshooting

It is the classic OSPF ticket: the neighbor is FULL, the LSA is sitting right there in the database, and the route still refuses to show up in the routing table. Or worse, the route is not even in the database and you cannot tell which layer lost it. OSPF has a clean separation between learning topology (the LSDB) and choosing routes (SPF results installed in the RIB), and a route can die at either stage. The full OSPF guide walks through that pipeline from hello to installed route.

This article gives you the five causes that account for nearly every missing OSPF route, then works one of them end to end on real hardware, with output captured from a Cisco Modeling Labs topology on IOS XE 17.18. In the lab: R1 and R2 share a LAN in area 0, R2-R3 is a /30 in area 1, and R3 holds a loopback network 192.168.5.0/24 in area 2. Keep that area 2 detail in mind; it becomes the worked example.

The five causes

Before any deep debugging, check these in order. Each one has a distinct fingerprint.

• Another protocol won on administrative distance. OSPF computed the route, but EIGRP (AD 90) or a static route (AD 1) beat its AD of 110. show ip route x.x.x.x shows the winner; if the source is not "ospf", this is your cause. The route is fine, it just lost the election.
• A discontiguous area. The route's origin area has no connection to area 0, so its type 3 summaries never propagate. Nothing is "down", the prefix is simply absent everywhere beyond the stranded area (background in OSPF areas explained).
• Filtering. A distribute-list in blocks installation into the RIB on that router (the LSA still floods), while area filter-list or area range not-advertise on an ABR stops the summary from ever being generated. If the LSA exists but the local table refuses it, look for a distribute-list.
• Inactive or unresolvable next hop. SPF produced a route whose next hop cannot be used, commonly a forwarding address on an external route that is not reachable, or an interface that is up but wrongly addressed.
• Network type mismatch. The subtle one: two ends of a link with mismatched OSPF network types (say point-to-point on one side, broadcast on the other) can reach FULL adjacency with matching timers, but the LSAs describe the link inconsistently, SPF cannot stitch the two descriptions together, and routes through that link never install. The neighbor table looks perfect, which is what makes it cruel.

Note what is not on the list: a neighbor that never formed. If the adjacency itself is missing, the routes were never learned in the first place, and that is a different workflow (see troubleshooting OSPF neighbors not forming). Also check for passive interfaces while you are there; a passive interface still gets advertised but forms no adjacencies, a combination that regularly masquerades as a missing-route problem (details in the OSPF passive interface guide).

Worked example: the discontiguous area

In the lab, R3 connects area 1 and area 2, but has no interface in area 0. Area 2's network 192.168.5.0/24 exists, is advertised, and R3's own database is perfectly healthy. Yet on R1, over in area 0:

R1# show ip route 192.168.5.0
% Network not in table

No error, no log message, no flapping neighbor. Inter-area routes only travel via the backbone, and R3's ABR has no backbone attachment, so its area 2 summary goes nowhere. The fix (short of readdressing the network) is a virtual link through the shared transit area, configured on both ABRs under the OSPF process:

R2(config-router)# area 1 virtual-link 3.3.3.3
R3(config-router)# area 1 virtual-link 2.2.2.2

With R3 logically connected to area 0 again, the same lookup on R1 transforms:

R1# show ip route 192.168.5.0
Routing entry for 192.168.5.0/24
  Known via "ospf 1", distance 110, metric 21, type inter area
  Last update from 10.0.12.2 on Ethernet0/0, 00:00:24 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 3.3.3.3, 00:00:24 ago, via Ethernet0/0
      Route metric is 21, traffic share count is 1

The "from 3.3.3.3" field confirms the advertising router, and "type inter area" confirms it arrived as a normal type 3 route. Total change: two commands, zero interfaces touched.

The ABR discard route surprise

One special case sends people hunting for a problem that does not exist. On an ABR configured with area range summarization, the summarized prefix appears in the ABR's own table pointing at Null0:

R2# show ip route ospf | include Null0
O        172.16.0.0/22 is a summary, 00:00:24, Null0

That is not a broken route eating your traffic. It is the automatic discard route that accompanies every summary: packets matching the /22 but no more-specific component route are dropped on the ABR instead of chasing a default route into a loop. Traffic to real destinations inside the summary follows the longer-prefix /24 routes as usual. If you find a Null0 entry while chasing a missing route, it means you are standing on the summarizing ABR, and the missing more-specific route is your actual problem.

Systematic checklist

When the quick causes above do not jump out, run the layers in order:

1. show ip ospf neighbor: is the adjacency FULL? If not, stop and fix that first.
2. show ip ospf database: is the LSA present? Absent means an advertisement or flooding problem upstream (discontiguous area, filtering at an ABR, or the route was never advertised). Present means the problem is local.
3. show ip route x.x.x.x: what won? Another protocol's AD, a Null0 summary, or genuinely nothing?
4. show ip ospf statistics: is SPF actually running when the topology changes? In the lab, R2 shows per-area execution counts and the reason codes for each run (R for router LSA changes, N for network LSA, SN for summary), which tells you whether OSPF even noticed the event you are debugging.

That order matters because each step rules out an entire layer: adjacency, then database, then route selection, then SPF itself. Ninety percent of tickets end at step 3.

Key Takeaways

• A missing OSPF route dies in one of two places: it never reached the LSDB (flooding, filtering, discontiguous area) or it reached the LSDB and lost at installation (AD, distribute-list, next hop, network type mismatch). show ip ospf database is the fork in the road.
• The five usual suspects: better AD from another protocol, discontiguous areas, filtering, an unusable next hop, and mismatched network types on a FULL adjacency.
• "% Network not in table" with healthy neighbors is the discontiguous-area signature; a virtual link restores the path in two commands.
• A Null0 summary route on an ABR is normal loop-prevention behavior, not the fault.
• Work the checklist in order (neighbor, database, route, SPF statistics) and you will localize the failure in four commands.