OSPFEXEC

show ospf database

Displays the OSPF link-state database (LSDB) for a specified OSPF process or all processes.

Overview

The 'show ospf database' command is a fundamental troubleshooting and verification tool for OSPF on Cisco IOS-XR. It displays the contents of the OSPF link-state database (LSDB), which is the collection of all Link-State Advertisements (LSAs) that the router has received from its OSPF neighbors. The LSDB is the core of OSPF's link-state routing protocol; each router in an OSPF area maintains an identical LSDB, and the Shortest Path First (SPF) algorithm uses this database to compute the routing table.

This command is essential for verifying OSPF convergence, diagnosing routing issues, and understanding the network topology from OSPF's perspective. On Cisco IOS-XR, the command syntax is 'show ospf [process-name] database [options]'. Unlike Cisco IOS, where the command is 'show ip ospf database', IOS-XR uses 'show ospf database' (without 'ip'). The command can be used in EXEC mode and optionally specifies an OSPF process name if multiple OSPF processes are configured.

Common use cases include: verifying that all expected LSAs are present after a network change, checking for LSA age issues (e.g., LSAs approaching MaxAge), identifying LSA corruption via checksum mismatches, and troubleshooting missing routes by examining specific LSA types. The command supports various filters to focus on specific LSA types (router, network, summary, external, NSSA) or specific advertising routers. The 'database-summary' option provides a quick overview of LSA counts per area and type, which is useful for a high-level health check.

In troubleshooting workflows, the 'show ospf database' command is often used after verifying OSPF neighbor adjacencies. If neighbors are full but routes are missing, examining the LSDB can reveal whether the expected LSAs are present. For example, if a route is missing, check if the corresponding Type 3 Summary LSA or Type 5 External LSA exists. If an LSA is missing, the issue may be with the advertising router or with LSA flooding. If an LSA has a high age or sequence number, it may indicate a flapping interface or a router that is constantly regenerating LSAs.

Syntax·EXEC

show ospf [process-name] database [database-summary] [external] [internal] [router] [network] [summary] [asbr-summary] [nssa-external] [opaque-area] [opaque-as] [opaque-link] [self-originate] [adv-router {router-id | self}] [lsid {ls-id}] [detail]

When to Use This Command

Verify OSPF LSDB synchronization between routers after a network change.
Troubleshoot missing or flapping OSPF routes by examining LSA types.
Check for LSA corruption or age issues (e.g., max-age LSAs).
Validate that external routes are being redistributed correctly into OSPF.

Parameters

Parameter	Syntax	Required	Description
process-name	WORD	Optional	The name of the OSPF process. If not specified, the command applies to all OSPF processes. On IOS-XR, OSPF processes are named (e.g., 'default' or a custom name).
database-summary	keyword	Optional	Displays a summary of the LSDB, showing the number of LSAs per area and type. Useful for a quick overview without detailed LSA information.
external	keyword	Optional	Displays only Type 5 External LSAs. These LSAs are originated by ASBRs to advertise external routes into the OSPF domain.
router	keyword	Optional	Displays only Type 1 Router LSAs. Each router originates one Router LSA per area, describing its OSPF-enabled interfaces and their state.
network	keyword	Optional	Displays only Type 2 Network LSAs. These are originated by the Designated Router (DR) on broadcast and NBMA networks, listing all routers attached to the segment.
summary	keyword	Optional	Displays only Type 3 Summary LSAs. These are originated by ABRs to advertise inter-area routes.
asbr-summary	keyword	Optional	Displays only Type 4 ASBR Summary LSAs. These are originated by ABRs to advertise the location of an ASBR.
nssa-external	keyword	Optional	Displays only Type 7 NSSA External LSAs. These are used in Not-So-Stubby Areas (NSSA) to advertise external routes.
opaque-area	keyword	Optional	Displays Opaque LSAs of area scope (Type 9, 10, 11). Used for extensions like Traffic Engineering.
opaque-as	keyword	Optional	Displays Opaque LSAs of AS scope (Type 11).
opaque-link	keyword	Optional	Displays Opaque LSAs of link-local scope (Type 9).
self-originate	keyword	Optional	Displays only LSAs that this router has originated. Useful for verifying what the router is advertising.
adv-router	adv-router {router-id \| self}	Optional	Displays LSAs advertised by a specific router, identified by its router ID. Use 'self' to see LSAs originated by this router.
lsid	lsid {ls-id}	Optional	Displays LSAs with a specific Link State ID. The LSID depends on LSA type (e.g., router ID for Router LSA, network address for Network LSA).
detail	keyword	Optional	Displays detailed information for each LSA, including all link records and options. Without this keyword, a summary line per LSA is shown.

Command Examples

Display OSPF database summary

show ospf database database-summary

            OSPF Router with ID (10.0.0.1) (Process ID 100)

                Summary OSPF database for process 100

 Area 0.0.0.0 database
   Type      LSID            Adv Router      Age   Seq#       Checksum
 Router  10.0.0.1        10.0.0.1         123   0x80000005 0x00A1B2
 Router  10.0.0.2        10.0.0.2         456   0x80000003 0x00C3D4
 Network 10.0.1.0        10.0.0.1         789   0x80000001 0x00E5F6

 Area 0.0.0.1 database
   Type      LSID            Adv Router      Age   Seq#       Checksum
 Summary 10.0.2.0        10.0.0.1         234   0x80000002 0x00G7H8

 Total LSAs: 4

The output shows a summary of LSAs in each area. For area 0.0.0.0, there are two Router LSAs (from routers 10.0.0.1 and 10.0.0.2) and one Network LSA. Area 0.0.0.1 has one Summary LSA. The 'Age' column indicates seconds since LSA origination; healthy values are below 1800 (MaxAge is 3600). 'Seq#' increments with each update; high numbers indicate many changes. 'Checksum' verifies LSA integrity.

Display detailed OSPF database for a specific LSA

show ospf database router 10.0.0.1 detail

        OSPF Router with ID (10.0.0.1) (Process ID 100)

                Router Link States (Area 0.0.0.0)

  LS age: 123
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.0.0.1
  Advertising Router: 10.0.0.1
  LS Seq Number: 0x80000005
  Checksum: 0x00A1B2
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Network/Interface address: 10.0.1.0
     (Link Data) Router Interface address: 10.0.1.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/Interface address: 10.0.2.0
     (Link Data) Router Interface address: 10.0.2.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

The detailed output shows the Router LSA originated by 10.0.0.1. 'LS age' is 123 seconds (healthy). 'Options' indicate capabilities. 'LS Type' is Router Links. 'Link State ID' and 'Advertising Router' identify the LSA. 'LS Seq Number' increments with each update. 'Checksum' and 'Length' validate the LSA. 'Number of Links' lists the router's OSPF interfaces. Each link shows its type (Transit Network, Stub, etc.), Link ID (neighbor's router ID or network address), Link Data (local interface IP), and metric.

Understanding the Output

The 'show ospf database' command output displays the OSPF link-state database (LSDB) stored on the router. The LSDB contains all LSAs that the router has received and is used to compute the shortest path tree. The output is organized by area and LSA type. Key fields include: 'LS age' – time in seconds since the LSA was originated; values approaching 1800 (MaxAge) indicate the LSA is about to be refreshed or is stale. 'Seq#' – sequence number; increments with each update; a very high number may indicate a flapping interface. 'Checksum' – used to detect corruption; if mismatched, the LSA is ignored. 'Advertising Router' – the router that originated the LSA. 'Link State ID' – identifies the LSA (e.g., router ID for Router LSA, network address for Network LSA). For Router LSAs, the 'Number of Links' field shows how many OSPF interfaces the router has in that area. Each link entry includes the link type (Transit, Stub, Virtual, Point-to-Point), Link ID (neighbor's router ID or network), Link Data (local interface IP), and metric. For Network LSAs, the output lists the DR's router ID and all attached routers. Summary LSAs show the destination network and metric. External LSAs include a forwarding address and external route tag. Healthy LSDBs have LS ages well below 1800, consistent sequence numbers, and no missing LSAs. Problems include: LS age at 1800 (MaxAge) indicating a stale LSA; high sequence numbers suggesting frequent updates; missing LSAs for known routers; or checksum errors. The 'database-summary' option provides a quick count of LSAs per area and type, useful for verifying that all expected LSAs are present.

Configuration Scenarios

Verifying OSPF LSDB after adding a new network

A new subnet 192.168.10.0/24 is added to an OSPF area 0. You want to verify that the Router LSA is updated and that other routers receive the information.

Topology

R1 (10.0.0.1) --- R2 (10.0.0.2)
R1 has new loopback 192.168.10.1/24 in area 0

Steps

1.Configure the new interface under OSPF on R1.
2.On R1, run 'show ospf database router self-originate detail' to see the updated Router LSA.
3.On R2, run 'show ospf database router 10.0.0.1 detail' to verify the LSA is received.
4.Check that the new link appears with correct metric.

Configuration

! On R1
interface Loopback10
 ipv4 address 192.168.10.1 255.255.255.0
!
router ospf 100
 area 0
  interface Loopback10
   passive
  !
 !
!

Verify: On R1: 'show ospf database router self-originate detail' should show a new stub link for 192.168.10.0/24 with metric 1. On R2: 'show ospf database router 10.0.0.1 detail' should show the same link.

Watch out: Ensure the interface is in the correct OSPF area. Also, if the interface is passive, it will appear as a stub link; if not passive, it may appear as a transit link if a neighbor is present.

Troubleshooting missing external routes

An ASBR is redistributing static routes into OSPF, but some external routes are not appearing on other routers. Use the LSDB to check if the Type 5 LSAs are being generated and received.

Topology

ASBR (10.0.0.1) redistributes static routes. R2 (10.0.0.2) is an internal router in area 0.

Steps

1.On ASBR, verify redistribution configuration.
2.On ASBR, run 'show ospf database external self-originate' to see if Type 5 LSAs are generated.
3.On R2, run 'show ospf database external' to see if the LSAs are received.
4.If LSAs are missing on R2, check OSPF neighbor state and MTU issues.

Configuration

! On ASBR
router ospf 100
 redistribute static
!
ipv4 route 10.10.0.0 255.255.0.0 Null0

Verify: On ASBR: 'show ospf database external self-originate' should show a Type 5 LSA for 10.10.0.0/16. On R2: 'show ospf database external' should show the same LSA with age increasing.

Watch out: If the ASBR is in a stub area, Type 5 LSAs are not allowed; use Type 7 instead. Also, ensure that the redistribution policy is not filtering the route.

Troubleshooting with This Command

The 'show ospf database' command is a primary tool for troubleshooting OSPF routing issues on Cisco IOS-XR. When routes are missing or incorrect, the LSDB reveals whether the expected LSAs exist. Start by checking the database summary to see if the number of LSAs per area and type looks reasonable. For example, if a router is missing, its Router LSA should be present. If an inter-area route is missing, check for Type 3 Summary LSAs from the ABR.

If an LSA is present but the route is not installed, examine the LSA details. For Router LSAs, verify that the link metrics are correct and that the link type matches the network type. For Network LSAs, ensure that the DR is correctly elected and that all routers on the segment are listed. For External LSAs, check the forwarding address and external route tag; if the forwarding address is not reachable, the route may not be installed.

Common issues include: LSA age approaching MaxAge (1800 seconds) indicating a stale LSA; this can happen if a router is not refreshing its LSAs. A rapidly increasing sequence number suggests a flapping interface or a router that is constantly regenerating LSAs. Checksum errors indicate corruption, possibly due to a faulty link or memory issue. Missing LSAs may be due to OSPF neighbor issues, filtering, or MTU mismatches preventing LSA flooding.

On IOS-XR, the 'show ospf database' command can be combined with other show commands for deeper troubleshooting. For example, 'show ospf neighbor' verifies adjacency states, and 'show ospf interface' checks interface parameters. If LSAs are not being received, check for OSPF packet drops using 'show ospf statistics'. Also, use 'debug ospf lsa' with caution to monitor LSA flooding.

When troubleshooting, always start with the database summary to get an overview. Then drill down into specific LSA types or advertising routers. Compare the LSDB on multiple routers to ensure consistency. If a router's LSDB is missing LSAs that others have, the issue is likely with that router's OSPF process or its connectivity.

CCNA Exam Tips

Remember that 'show ip ospf database' is the IOS equivalent; on IOS-XR, the command is 'show ospf database'.

Know the different LSA types: Type 1 (Router), Type 2 (Network), Type 3 (Summary), Type 4 (ASBR Summary), Type 5 (External), Type 7 (NSSA External).

Be able to identify a flapping route by a rapidly increasing sequence number in the LSDB.

Common Mistakes

Forgetting to specify the process name when multiple OSPF processes exist; the command will prompt for it.

Confusing 'show ospf database' with 'show ospf route'; the former shows LSAs, the latter shows the routing table.

Assuming that 'database-summary' shows all LSAs; it only shows counts, not details.

Platform Notes

On Cisco IOS-XR, the OSPF database command syntax differs from classic IOS. The IOS command is 'show ip ospf database', while IOS-XR uses 'show ospf database' (without 'ip'). Additionally, IOS-XR requires specifying the OSPF process name if multiple processes exist; otherwise, the command applies to all processes. IOS-XR also supports named OSPF processes, whereas IOS uses process IDs (numbers). The output format is similar but may have slight differences in field labels and ordering.

Compared to other platforms, such as Juniper JunOS, the equivalent command is 'show ospf database' (similar) but with different output formatting. JunOS uses a hierarchical display and includes additional fields like 'Options' and 'Advertising Router' in a different layout. On IOS-XR, the 'detail' option provides extensive information, including TOS metrics and link data.

Version differences: In earlier IOS-XR releases, the command may not support all filtering options (e.g., opaque-area). Always check the specific version documentation. IOS-XR also supports the 'database-summary' option, which is not available in classic IOS. Additionally, IOS-XR allows filtering by 'adv-router' and 'lsid' for more precise queries.

For network engineers transitioning from IOS to IOS-XR, remember that the 'show ip ospf' commands are replaced with 'show ospf' (without 'ip'). Also, the OSPF process configuration is under 'router ospf <process-name>' rather than 'router ospf <process-id>'. The database command behavior is largely the same, but the output may include additional fields like 'Options' and 'DC' (Demand Circuit) bits.

Practice for the CCNA 200-301

Test your knowledge with hundreds of CCNA practice questions covering all exam domains.

Practice CCNA Questions