Missing route — SPF not running, summarisation hiding route, LSA not flooded, area filter

A missing OSPF route is one of the most common OSPF failures the operator encounters. The route is expected but not in the RIB; the operator cannot reach the destination; the diagnostic must distinguish between two failure layers:

1. The route is in the LSDB but not in the RIB. The SPF did not install the route; possible causes include summarisation, area filter, stub area filtering, R-bit clear.
2. The route is not in the LSDB. The originator is not advertising; possible causes include missing network statement, area scope, redistribution not configured, LSA not flooded.

This lesson covers the two-layer diagnostic, the route-trace playbook, and the production scenarios for missing routes.

The two-layer failure model

OSPF route installation is a two-stage process:

1. LSDB population. Type 1 (Router), Type 2 (Network), Type 3 (Summary), Type 4 (ASBR-Summary), Type 5 (AS-External), Type 7 (NSSA-External) LSAs are flooded throughout the area (Type 1, 2, 3, 4, 7) or the entire domain (Type 5).
2. RIB installation via SPF. The router runs SPF over the LSDB and installs the resulting routes in the RIB. The RIB is what the forwarding plane uses.

A missing route can fail at either stage:

flowchart TB
  subgraph "Layer 1: LSDB population"
    O1["Originator<br/>generates LSA"]
    L1["LSA flooded<br/>throughout area/domain"]
    LSDB["LSDB has LSA"]
  end
  subgraph "Layer 2: SPF and RIB"
    SP["SPF runs<br/>computes path"]
    RIB["RIB has route"]
  end
  subgraph "Forwarding"
    FW["Forwarding plane<br/>uses RIB"]
  end
  O1 --> L1 --> LSDB
  LSDB --> SP --> RIB --> FW

The diagnostic sequence:

1. Check the RIB. show ip route <prefix>. If the route is there, the failure is elsewhere (forwarding, firewall).
2. Check the OSPF RIB. show ip route ospf. If the route is there, the OSPF installation is working.
3. Check the LSDB. show ip ospf database. If the LSA is there, the LSDB is populated.
4. Check the originator. show ip ospf database self-originate on the originator. If the originator does not have the LSA, the originator is not advertising.

Layer 1 failures — Route not in the RIB

The LSA is in the LSDB but the route is not in the RIB. The common causes:

Cause 1 — SPF did not run

The LSA is in the LSDB but the SPF did not run because:

• The LSA is the same as an existing LSA (no change).
• The SPF is throttled (the operator configured timers throttle spf).
• The LSA is outside the router’s scope (Type 1 / Type 2 LSAs are area-scoped; a router in Area 0 cannot see Area 1’s Type 1).

The diagnostic:

show ip ospf
# SPF schedule delay: ...
# SPF last executed: ...

debug ospf lsa
# log shows: "LSA received but no SPF scheduled"

Cause 2 — Summarisation hides the route

The operator configured a summary on the ABR. The summary aggregates multiple prefixes into one; specific prefixes inside the summary are not advertised across the ABR.

The diagnostic:

# On the ABR
show configuration commands | match "range"
# area 1 range 10.0.0.0/16

# The summary 10.0.0.0/16 is advertised
# The specific prefix 10.0.1.0/24 inside the summary is not

The fix is to remove the summary or to advertise the specific prefix outside the summary:

delete protocols ospf area 1 range 10.0.0.0/16
# Or:
set protocols ospf area 1 range 10.0.0.0/16
# The specific prefix is filtered

Cause 3 — Area filter blocks the route

The operator configured an area filter that blocks the prefix from being injected into the area’s LSDB.

The diagnostic:

show configuration commands | match "filter-list\|area.*filter"
# area 1 filter-list prefix FILTER in

show ip prefix-list FILTER
# (rules of the filter)

Cause 4 — Stub area filtering

The router is in a stub area and the prefix is an external (Type 5) route. Stub areas do not carry Type 5 LSAs.

The diagnostic:

show ip ospf database external
# (empty — the area does not carry Type 5)

show configuration commands | match "area .* stub"
# area 1 stub

The fix is to use NSSA instead of stub, or to accept the external route is not available inside the stub area.

Cause 5 — R-bit clear (OSPFv3)

In OSPFv3, the R-bit in Type 3 Summary LSAs and Type 1 Router LSAs indicates whether the originating router is forwarding. If the R-bit is clear, the downstream router does not install the route.

The diagnostic:

show ipv6 ospf6 database summary verbose
# (R-bit flag)

The fix is to ensure the originating router is forwarding (non-passive interfaces, OSPFv3 enabled on the egress).

Layer 2 failures — LSA not in the LSDB

The route is not in the RIB because the LSA is not in the LSDB. The common causes:

Cause 1 — Originator does not advertise the prefix

The originator’s interface is not in the OSPF network statement (OSPFv2) or the interface is not enabled for OSPF (OSPFv3).

The diagnostic:

# On the originator
show ip ospf interface
# (the interface should be listed)

# For OSPFv2
show configuration commands | match "area .* network"
# (the prefix should be in a network statement)

# For OSPFv3
show configuration commands | match "area .* interface"
# (the interface should be enabled)

Cause 2 — The prefix is in a different area

The originator’s interface is in Area 1 but the operator looks for the route in Area 0. Type 1 and Type 2 LSAs are area-scoped; the route is in Area 1’s LSDB, not in Area 0’s.

The diagnostic:

show ip ospf database router <router-id>
# (LSA is in this area's LSDB)

show ip ospf border-routers
# (which router is the ABR)

The fix is to verify the operator is looking at the correct area’s LSDB.

Cause 3 — Redistribution not configured

The prefix is learned from another source (static, connected, BGP) but the redistribution block is missing.

The diagnostic:

show configuration commands | match "redistribute"
# (the redistribution block should be configured)

# On the originator
show ip route <prefix>
# (the prefix should be in the RIB)

# The redistribution block converts the RIB entry to an LSA

The fix is to add the redistribution block:

set protocols ospf redistribute static route-map STATIC-INTO-OSPF
commit
save

Cause 4 — LSA not flooded (area scope issue)

The LSA is generated but not flooded to the area where the operator looks. Type 5 LSAs are flooded throughout the domain; Type 1, Type 2, Type 3, Type 4 LSAs are flooded within an area.

The diagnostic:

# On the originator
show ip ospf database self-originate
# (the LSA is originated)

# On a remote router in the same area
show ip ospf database
# (the LSA should be visible)

# On a remote router in a different area
show ip ospf database
# (Type 1/2 not visible — area scope)
# (Type 5 should be visible if it exists)

Cause 5 — The LSDB is fragmented

A duplicate router-id (covered in vyos-xxii-05-duplicate-router-id) fragments the LSDB; the SPF tree diverges; the route does not install correctly.

The diagnostic:

journalctl -u frr | grep -i duplicate
# (duplicate-LSA warnings)

The route-trace diagnostic playbook

The route-trace diagnostic sequence:

1. Confirm the destination. Verify the destination prefix and the expected path.
2. Check the local RIB. show ip route <prefix> shows whether the route is in the RIB.
3. Check the OSPF RIB. show ip route ospf shows the OSPF-installed routes.
4. Trace the LSA chain. If the prefix is in the RIB, the chain is complete. If not, walk the chain:
   • LSDB? show ip ospf database for the prefix’s LSA type (Type 1 / Type 2 / Type 3 / Type 5).
   • Originator? show ip ospf database self-originate on the originator.
   • Adjacency? show ip ospf neighbor on the originator and on the local router.
   • Area? show ip ospf interface on the originator and on the local router.
5. Check the SPF. show ip ospf shows when SPF last ran.
6. Apply the fix. Address the layer-1 or layer-2 failure.
7. Validate. show ip route <prefix> confirms the route.

flowchart TB
  S1["show ip route<br/>destination"] --> S2{"in RIB?"}
  S2 -- "yes" --> S3["valid"]
  S2 -- "no" --> S4["show ip route ospf"]
  S4 --> S5{"in OSPF RIB?"}
  S5 -- "yes" --> S6["valid (OSPF)"]
  S5 -- "no" --> S7["show ip ospf database"]
  S7 --> S8{"LSA in LSDB?"}
  S8 -- "yes" --> S9["SPF / RIB issue"]
  S8 -- "no" --> S10["originator issue"]
  S9 --> S11["summarisation? filter?<br/>stub area? R-bit?"]
  S10 --> S12["network statement?<br/>redistribution? area scope?"]

Production scenarios

Scenario 1 — Summarisation hides specific routes

An operator configured area 1 range 10.0.0.0/16 on the ABR. A downstream router expects to see 10.0.1.0/24 but sees only 10.0.0.0/16.

The diagnostic:

# On the ABR
show configuration commands | match "area 1 range"
# area 1 range 10.0.0.0/16

show ip ospf database summary self-originate
# Type 3 Summary 10.0.0.0/16 (only)

The fix is to either remove the summary or to advertise the specific prefix outside the summary.

Scenario 2 — Redistribution missing

A static route is configured on R1 but not redistributed into OSPF. The remote routers do not see the static route.

The diagnostic:

# On R1
show ip route 10.99.0.0/24
# S 10.99.0.0/24 [1/0] via 192.0.2.1, eth1

show ip ospf database external self-originate
# (empty — no Type 5 originated)

show configuration commands | match "redistribute"
# (no redistribution block)

The fix is to add the redistribution:

set protocols ospf redistribute static route-map STATIC-INTO-OSPF
commit
save

Scenario 3 — Stub area with external routes

A router in a stub area expects to see an external route. The route is in the OSPF domain but not in the stub area.

The diagnostic:

show ip ospf database external
# (empty in the stub area)

show configuration commands | match "area .* stub"
# area 1 stub

The fix is to use NSSA or to inject a default route into the stub area.

Production failure modes

• Summarisation hides specific routes. The operator configured a summary on the ABR. The fix is to remove the summary or to advertise the specific prefix outside.
• Area filter blocks the route. The operator configured a filter-list on the ABR. The fix is to remove or adjust the filter.
• Stub area with external routes. The operator expects Type 5 in a stub area. The fix is to use NSSA.
• Redistribution missing. The prefix is in the RIB but not in the OSPF LSDB. The fix is to add the redistribution block.
• Originator’s interface not in OSPF. The prefix is on the router but the OSPF process is not enabled on the interface. The fix is to add the interface to the OSPF configuration.
• LSA not flooded. The LSA is generated but not flooded. The fix is to verify the adjacency and the flooding domain.

Rollback

The rollback for a missing-route change:

# Capture the running configuration
show configuration commands | save /tmp/ospf-missing-route-$(date +%s).txt

# Compare
compare

# Commit with a short confirm window
commit-confirm 5

# Rollback if needed
rollback 1
commit

For a redistribution change:

# Remove the redistribution
delete protocols ospf redistribute static route-map STATIC-INTO-OSPF
commit
save

For a summary change:

# Remove the summary
delete protocols ospf area 1 range 10.0.0.0/16
commit
save

Production discipline

Cross-course references

The OSPF fundamentals lessons vyos-xviii-03-lsa-types (LSA types) and vyos-xviii-06-spf-and-cost (SPF and cost) cover the conceptual basis. The OSPF configuration lessons vyos-xix-04-ospf-redistribute (redistribution) and vyos-xx-03-summarisation (summarisation) cover the primitives this lesson assumes. The OSPF troubleshooting lessons vyos-xxii-01-neighbour-stuck (neighbour-stuck states), vyos-xxii-02-mtu-mismatch (MTU mismatch), and vyos-xxii-05-duplicate-router-id (duplicate router-id) cover related failure modes. The OSPFv3 lesson vyos-xxi-04-ospfv3-troubleshoot covers the OSPFv3 missing-route variants.

Quiz