OSPF Verification Commands

What you will be able to do

• Verify OSPF process, area, and interface scope before interpreting routes.
• Interpret neighbor and link-state database evidence during adjacency synchronization.
• Connect OSPF neighbor state with the presence or absence of installed OSPF routes.
• Choose the narrowest Cisco IOS show command for an OSPF verification question.

01

Turn the symptom into a verification question

OSPF verification should answer a question, not produce a collection of unrelated output. Begin with the symptom: Is the process running, is the interface participating in the expected area, is the neighbor present, or is the route installed?

Record the router, interface, area, neighbor ID, or destination prefix named by the incident. That scope tells you which command to run first and prevents a healthy OSPF component from hiding the actual failure.

Use broad commands to establish context, then narrow the inspection. Open the link-state database only when process, interface, neighbor, and route evidence do not fully answer the question.

02

Verify the OSPF process

Run `show ip ospf` to inspect general information about the active OSPF process. Confirm the process ID used on that device, the router ID, and the area information relevant to the incident.

Use `show ip protocols` when the question spans routing-protocol state or advertised networks rather than OSPF internals alone. The local process ID is significant on that router; it does not need to match a neighbor's process ID.

If the expected process or area is absent, stop here and compare the intended configuration. Neighbor and route commands cannot prove an adjacency for an interface that never entered the intended OSPF process.

03

Verify participating interfaces

Run `show ip ospf interface brief` to obtain a compact view of OSPF interfaces, including process, area, address, cost, state, and neighbor counts where the platform exposes them. Check the interface named by the topology before inspecting every interface.

For a mismatch, use `show ip ospf interface <interface>` to inspect that interface in detail. Compare area, network type, timers, passive behavior, and operational state with the neighbor-facing design.

An interface check separates local participation from neighbor formation. If the interface is missing or assigned to the wrong area, a neighbor-state command will show the consequence but not replace this local evidence.

R1# show ip ospf interface brief
Interface    PID   Area    IP Address/Mask    Cost  State  Nbrs F/C
Gi0/0        1     0       10.0.12.1/30      1     P2P    1/1
Gi0/1        1     0       10.0.13.1/30      1     P2P    0/0

Both interfaces participate in OSPF process 1 and area 0, but only `Gi0/0` currently has the expected formed neighbor. Field labels can vary by IOS release, so interpret them with the installed platform documentation.

The interface summary separates local OSPF participation from neighbor formation. The useful next check is `Gi0/1` and its peer, not the healthy `Gi0/0` adjacency.

04

Verify neighbors and their state

Run `show ip ospf neighbor` to inspect OSPF neighbor information. The useful fields include the neighbor ID, state, address, dead time, and local interface. Start with the peer and interface expected by the topology.

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:34    10.0.12.2       GigabitEthernet0/0
3.3.3.3           1   EXSTART/BDR     00:00:31    10.0.13.3       GigabitEthernet0/1

The first peer reached Full on `GigabitEthernet0/0`, while the second remains in ExStart on a different interface.

Focus the next comparison on the affected link's parameters and recent changes rather than resetting the healthy adjacency.

Full means the adjacency reached database synchronization for relationships that should become fully adjacent. ExStart, Exchange, and Loading identify different parts of database negotiation and synchronization, so a persistent state narrows the next comparison.

Do not assume every multi-access neighbor relationship must display the same state; network type and DR or BDR roles affect adjacency behavior. Compare the output with the intended network type before declaring a failure.

05

Verify installed OSPF routes

Run `show ip route ospf` to display routes installed from OSPF. Search for the destination prefix named by the incident and record its route type, next hop, outgoing interface, and metric where shown.

A Full neighbor does not guarantee that every expected prefix is installed. The route can be absent because the prefix was not originated, an area boundary changed what is advertised, another route source won, or the local route calculation lacks the needed link-state information.

If the route is present, verify forwarding toward its next hop rather than concluding that the complete application path works. Routing-table evidence answers a Layer 3 decision question, not DNS, transport, or application health.

R1# show ip route ospf
O    10.20.0.0/16 [110/20] via 10.0.12.2, 00:03:12, GigabitEthernet0/0

The `O` code shows that OSPF installed `10.20.0.0/16`; the selected next hop is `10.0.12.2` through `GigabitEthernet0/0`. The age and exact spacing are device-specific observations, not values to memorize.

A route-table entry proves the local Layer 3 forwarding decision. It does not prove DNS, transport, or application health, so end-to-end testing remains a separate step.

06

Read database exchange states

In ExStart, neighbors establish the starting conditions for Database Description exchange. During Exchange, Database Description packets summarize link-state information so each router can identify records that are missing or older.

A router requests specific needed instances and can enter Loading while it obtains them. Full indicates that the adjacency's databases are synchronized for their shared area.

Treat a persistent state as a location in the process. Correlate it with interface parameters and recent neighbor changes instead of memorizing a universal reset command.

07

Inspect the link-state database when needed

Run `show ip ospf database` when the incident requires link-state evidence. The summary lists LSAs in the local link-state database and separates them by area and type, allowing you to check whether a router knows the expected advertisement.

Areas limit database scope. Two routers in different areas are not expected to hold identical area databases, so compare the same LSA type and area rather than treating every difference as corruption.

Use a more specific database form only after the summary identifies what is missing or unexpected. This keeps a large LSDB from becoming noise.

08

Use targeted database commands for targeted questions

A specialized command belongs late in the workflow. For example, `show ip ospf database nssa` can answer a question about NSSA database information and translator behavior, but it does not replace neighbor, interface, or route verification.

Keep the command paired with the hypothesis it tests. If the incident is a missing route, first prove whether the route is absent and whether the required adjacency exists. Inspect the relevant LSA or NSSA output only when that evidence points to advertisement or translation.

This ordering makes the terminal record useful: each command explains why the next command was necessary.

09

Follow a repeatable verification workflow

For a missing remote prefix, begin with `show ip ospf` and `show ip ospf interface brief` to confirm local scope. Then use `show ip ospf neighbor` for the expected peer and `show ip route ospf` for the destination.

If the peer is not established, stay with interface and neighbor evidence. If the peer is Full but the route is absent, inspect `show ip ospf database` for the relevant area and advertisement.

After a controlled correction, repeat the same narrow commands. Completion means the intended neighbor or route state appears and no unrelated adjacency or route disappeared.

10

Record an OSPF verification handoff

Start with a specific OSPF question. Use `show ip ospf` for process context and `show ip ospf interface brief` for interface and area participation.

Use `show ip ospf neighbor` to verify the expected peer, state, address, and local interface. Interpret persistent states as a location in adjacency formation.

Use `show ip route ospf` to prove whether OSPF installed the destination prefix. A Full neighbor and a complete end-to-end path are separate conclusions.

Use `show ip ospf database` only when the route or synchronization question requires LSA evidence. Compare the correct area and LSA scope.

Keep specialized output, including `show ip ospf database nssa`, tied to a specialized hypothesis. Repeat the original commands after a change to verify the result.