The neighbor relationship is up. show ip ospf neighbor reports FULL, no flapping, no retransmissions in the counters. The LSDB is synced across the area. Every sign says OSPF is doing its job correctly, and yet traffic to one specific subnet keeps going out the old path, the one that was supposed to be retired when OSPF was rolled out. Someone spends an hour re-checking OSPF: network statements, area numbers, the cost on the interface, whether the route is actually in the topology table. It's all fine. OSPF calculated the right route and would gladly install it. The router just isn't using it.
The part that makes this genuinely confusing is that show ip route ospf won't show the route either, so the instinct is to keep looking for a reason OSPF failed. OSPF didn't fail. Something else already won.
Every routing information source, connected interfaces, static routes, OSPF, EIGRP, BGP, gets a default trust ranking called administrative distance, and the router installs into its actual forwarding table only the route with the lowest AD for a given prefix, full stop, regardless of which one has the better path, the fresher information, or a lower metric. Connected interfaces sit at 0. Static routes default to 1. OSPF is 110. External BGP is 20, internal BGP is 200. If two sources both claim to know how to reach the same prefix, the router doesn't compare their metrics against each other at all, it just picks the lower AD and never looks at the loser again.
That's the trap. A static route to that subnet, typed in by hand years ago during whatever migration OSPF was eventually supposed to replace, is still sitting in the config with the default AD of 1. Nobody removed it when OSPF went live, because it wasn't causing visible problems, it was just quietly winning every single time. OSPF's route, AD 110, is correct, current, and completely irrelevant, because the router never gets far enough to compare the two paths on merit. It compares trust rankings first, and static wins that comparison before OSPF is ever in the running.
The way to actually catch this is to stop asking "why isn't OSPF installing this route" and start checking what's already installed for that exact prefix: show ip route <prefix> shows you the winning source directly, and if it says "S" for static where you expected "O" for OSPF, that's the whole diagnosis in one line. show ip ospf database or show ip route ospf confirm OSPF knew the right answer the entire time, it just never got asked to act on it.
Once you've found it, the fix depends on intent. If the static route has no reason to exist anymore, remove it and let OSPF do the job it was deployed for. If it genuinely needs to stay as a backup, for a path that should only activate if OSPF goes down, give it a floating static distance instead of the default: ip route <prefix> <mask> <next-hop> 200 sets its AD above OSPF's 110, so OSPF wins during normal operation and the static only takes over if OSPF's route disappears entirely. Same static route, same next hop, completely different behavior, because AD is the only thing that decides who gets to drive.
This is the kind of thing that looks obvious in a table and is genuinely hard to catch at 2am with a ticket open, which is exactly the gap the Network Engineer Book Bundle is built to close across its L1 to L3 arc, from the fundamentals of how a router actually chooses a route through the enterprise routing and BGP design where this stuff decides whether a network scales: https://resources.codelivly.com/product/network-engineer-complete-bundle-l1-l2-l3-foundations-to-advanced-architecture/
The free Routing & Switching Fundamentals and Network Services Administration learning paths on codelivly.com cover this same routing-table reasoning hands-on before you spend anything: https://codelivly.com/learning-paths/routing-switching-fundamentals and https://codelivly.com/learning-paths/network-services-administration
Top comments (0)