OSPF Deep Dive Part 11: Show Commands and the LSDB, Side by Side

Part 10 laid out what to check and in what order. This post is the reference for actually looking at it, on each of the three platforms this series covers. Same underlying state everywhere, three different ways to ask for it.

Command equivalence table

What you’re checking	Cisco IOS/IOS-XE	FortiOS	Junos
Neighbor states	show ip ospf neighbor	get router info ospf neighbor	show ospf neighbor
Interface OSPF config/state	show ip ospf interface brief	get router info ospf interface	show ospf interface
Full LSDB summary	show ip ospf database	get router info ospf database	show ospf database
One LSA in full detail	show ip ospf database router <id>	get router info ospf database router <id>	show ospf database extensive
Routes as OSPF calculated them	show ip route ospf	get router info routing-table ospf	show ospf route
Process-wide summary	show ip ospf	get router info ospf status	show ospf overview
Live event debugging	debug ip ospf adj / debug ip ospf events	diagnose ip router ospf level info / diagnose ip router ospf all enable	show ospf log / interface traceoptions

Reading the neighbor table

All three formats answer the same question, what state is each neighbor in, but arrange the columns differently enough that a quick glance can mislead someone used to a different vendor’s layout.

Cisco, CORE-CSR’s view of both other routers:

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2          1   FULL/DR         00:00:38    10.0.0.6        Gi0/1
10.0.0.3          1   FULL/BDR        00:00:31    10.0.0.10       Gi0/2

FortiOS, BRANCH-FGT’s view:

OSPF process 0, VRF 0
Neighbor ID     Pri   State    Dead Time   Address         Interface
10.0.0.1          1   Full/DR    00:00:35    10.0.0.5        wan1
10.0.0.3          1   Full/BDR   00:00:33    10.0.0.9        wan2

Junos, EDGE-MX’s view:

Address          Interface              State     ID               Pri  Dead
10.0.0.5         ge-0/0/1.0             Full      10.0.0.1          1     33
10.0.0.6         ge-0/0/2.0             Full      10.0.0.2          1     35

The state field is the one thing to read carefully across all three: Cisco and FortiOS both append the DR/BDR role directly to the state (FULL/DR, Full/DR), while Junos reports state alone in this column and shows role separately under show ospf interface detail instead. Reading Junos’s plain Full and assuming DR/BDR information isn’t available is a common miss; it’s just one command deeper than the equivalent Cisco or FortiOS output.

Reading interface state

This is where MTU, network type, and area membership from Parts 1 and 7 through 9 actually get confirmed rather than assumed. Cisco’s show ip ospf interface brief and FortiOS’s get router info ospf interface both summarize cost, area, and neighbor count in one table. Junos splits this across show ospf interface (state, area, DR/BDR role) and show ospf interface detail (adds hello/dead timers and authentication type), which means confirming a full hello-parameter match on Junos, exactly the checklist Part 10 lays out for a neighbor stuck below Full, takes the detail variant, not the summary one.

Reading the LSDB

This is the step Part 10 calls out as the dividing line between a neighbor-state problem and everything else: once Full, is the expected LSA actually present, and does its content match what was configured. All three summary commands (show ip ospf database, get router info ospf database, show ospf database) group LSAs by type and print one line each, an originating router-id, a sequence number, and an age. None of the three summary forms show the actual prefix content of a Type 3 or Type 5 LSA, only that it exists, meaning confirming a specific missing route requires drilling into the detailed variant:

Cisco: show ip ospf database network (Type 2) or show ip ospf database summary (Type 3), narrowed further with the originating router-id FortiOS: get router info ospf database summary <router-id> or the external / nssa-external keywords for Type 5/7 Junos: show ospf database extensive, which prints full LSA content for every type in one pass rather than requiring a type-specific command the way the other two do

Junos’s single extensive command being genuinely more convenient here than needing to know the right per-type keyword on Cisco or FortiOS is worth calling out plainly, since most of this series’ vendor comparisons so far have landed on tradeoffs rather than a clean win for one platform.

Confirming a route actually came from where it looks like it came from

show ip route ospf on Cisco, get router info routing-table ospf on FortiOS, and show ospf route on Junos all filter the routing table down to OSPF-originated entries specifically, which is the fastest way to answer Part 10’s final question: is the correct LSA present in the LSDB but not making it into the routing table. If a prefix shows up in the LSDB summary but not in this OSPF-filtered route view, the cause is downstream of OSPF entirely, a route-map or policy denial, an administrative distance or preference loss to another protocol (Part 9’s Junos-vs-eBGP preference default being the sharpest example in this series), or a filter-list blocking the prefix from being installed at all. If it’s missing from the LSDB summary in the first place, the cause is upstream, back in Part 2’s area-type filtering or Part 4’s summarization and redistribution.

Part 12 puts every command in this post and every cause in Part 10 to work on one deliberately broken scenario across all three routers, start to finish.