Courseiva
OSPFPrivileged EXEC

show ip ospf database

Displays the OSPF link-state database (LSDB) to verify OSPF adjacencies, check for missing or corrupt LSAs, and troubleshoot OSPF routing issues.

Definition: show ip ospf database is a Cisco IOS privileged exec command. Displays the OSPF link-state database (LSDB) to verify OSPF adjacencies, check for missing or corrupt LSAs, and troubleshoot OSPF routing issues.

Overview

The 'show ip ospf database' command is a cornerstone of OSPF troubleshooting and verification on Cisco IOS devices. It displays the contents of the OSPF link-state database (LSDB), which is the heart of the OSPF protocol. The LSDB contains all the Link-State Advertisements (LSAs) that the router has received from its OSPF neighbors, representing the topology of the OSPF domain.

This command is essential for verifying that OSPF adjacencies have formed correctly, that the router has a complete and consistent view of the network, and for diagnosing issues such as missing routes, routing loops, or suboptimal path selection. Unlike 'show ip route ospf', which shows only the best routes installed in the routing table, the database command reveals the raw topological information that OSPF uses to compute those routes. This makes it invaluable for advanced troubleshooting, especially when dealing with complex OSPF designs involving multiple areas, virtual links, or route redistribution.

The command is typically used in privileged EXEC mode (enable) and does not require any special privilege level beyond 15. It does not modify the running configuration; it is a read-only diagnostic tool. However, on large networks, the output can be extensive and may be truncated if the terminal length is not set appropriately (use 'terminal length 0' to disable paging).

The command can also be filtered by LSA type, area, or specific LSA ID to focus on particular aspects of the database. Understanding the output of this command is critical for CCNA and CCNP candidates, as it demonstrates a deep understanding of OSPF's operation and is frequently tested in exams and real-world scenarios. The command provides a snapshot of the router's OSPF state, including the router's own LSAs and those received from neighbors.

It is often used in conjunction with 'show ip ospf neighbor' to confirm adjacency states, and with 'show ip ospf interface' to verify interface parameters. In summary, 'show ip ospf database' is a powerful command that reveals the inner workings of OSPF, enabling engineers to validate network convergence, detect anomalies, and ensure the integrity of the routing domain.

Syntax·Privileged EXEC
show ip ospf database

When to Use This Command

  • Verify that all expected LSAs (Type 1, 2, 3, etc.) are present in the LSDB after configuring OSPF.
  • Troubleshoot missing routes by checking if Type 3 summary LSAs are being generated by the ABR.
  • Confirm that an ASBR is advertising external routes by looking for Type 5 LSAs.
  • Check the age and sequence number of LSAs to detect OSPF instability or flapping neighbors.

Parameters

ParameterSyntaxDescription
no parameterWhen issued without any parameters, the command displays a summary of all LSAs in the OSPF database, organized by LSA type (Router, Network, Summary, etc.). This is the most common usage for a quick overview of the database contents.
routerrouterDisplays only the Router LSAs (Type 1) in the database. This is useful for focusing on the state of each OSPF router in the area, including its directly connected links and neighbors.
networknetworkDisplays only the Network LSAs (Type 2) in the database. These LSAs are generated by the Designated Router (DR) on multi-access networks and describe the routers attached to that network.
summarysummaryDisplays only the Summary LSAs (Type 3) in the database. These are generated by Area Border Routers (ABRs) to advertise routes from one area to another.
asbr-summaryasbr-summaryDisplays only the ASBR Summary LSAs (Type 4) in the database. These are generated by ABRs to advertise the location of an Autonomous System Boundary Router (ASBR) to other areas.
externalexternalDisplays only the External LSAs (Type 5) in the database. These are generated by ASBRs to advertise routes redistributed from other routing protocols or static routes into OSPF.
nssa-externalnssa-externalDisplays only the NSSA External LSAs (Type 7) in the database. These are used in Not-So-Stubby Areas (NSSA) to carry external routes that are translated to Type 5 by the ABR.
opaque-areaopaque-areaDisplays only the Opaque LSAs of area scope (Type 10) in the database. These are used for extensions like Traffic Engineering (TE) or Graceful Restart.
opaque-asopaque-asDisplays only the Opaque LSAs of AS scope (Type 11) in the database. These are used for AS-wide extensions.
opaque-linkopaque-linkDisplays only the Opaque LSAs of link scope (Type 9) in the database. These are used for link-local signaling.
database-summarydatabase-summaryDisplays a summary of the OSPF database, showing the count of each LSA type per area. This is useful for a quick check of database size and consistency.
self-originateself-originateDisplays only the LSAs that the router itself has originated. This is useful for verifying that the router's own LSAs are correct and being advertised properly.
adv-routeradv-router [<ip-address>]Displays LSAs originated by a specific advertising router, identified by its router ID. If no IP address is specified, it shows LSAs from the local router. This helps in isolating issues related to a particular router.
link-state-idlink-state-id <ip-address>Displays a specific LSA identified by its Link State ID (usually an IP address). This is used to drill down into a particular LSA for detailed examination.

Command Examples

Basic OSPF Database Display

show ip ospf database
       OSPF Router with ID (192.168.1.1) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
192.168.1.1     192.168.1.1     345         0x80000004 0x00B2D4 2
192.168.1.2     192.168.1.2     567         0x80000003 0x00A1C3 3

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.1.3     192.168.1.3     234         0x80000001 0x0099E1

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.0.0        192.168.1.2     123         0x80000002 0x00CC44

                Summary ASB Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.2.1     192.168.1.2     456         0x80000001 0x00DD55

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         192.168.2.1     789         0x80000001 0x00EE66 0

The output is organized by LSA type. 'Router Link States' shows Type 1 LSAs from each router (identified by Link ID = Router ID). 'Net Link States' shows Type 2 LSAs from the DR (Link ID = DR's interface IP). 'Summary Net Link States' shows Type 3 LSAs from ABRs. 'Summary ASB Link States' shows Type 4 LSAs (ASBR summary). 'Type-5 AS External Link States' shows external routes. Key fields: ADV Router (advertising router), Age (seconds since LSA originated, should be < 1800 for stability), Seq# (increments with each update; higher is newer), Checksum (integrity check).

Display OSPF Database for a Specific LSA Type

show ip ospf database router 192.168.1.1
       OSPF Router with ID (192.168.1.1) (Process ID 1)

                Router Link States (Area 0)

  LS age: 345
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 192.168.1.1
  Advertising Router: 192.168.1.1
  LS Seq Number: 80000004
  Checksum: 0xB2D4
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 192.168.1.3
     (Link Data) Router Interface address: 192.168.1.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 192.168.1.0
     (Link Data) Network Mask: 255.255.255.0
      Number of MTID metrics: 0
       TOS 0 Metrics: 10

This shows detailed information for a specific Type 1 LSA. 'LS age' should be low (<1800) for a stable network. 'Link State ID' and 'Advertising Router' identify the originator. 'Number of Links' shows how many interfaces are participating in OSPF. Each link entry describes the type (transit, stub, etc.), the neighbor's DR address, and the metric (cost). A high age or rapidly changing Seq# may indicate instability.

Understanding the Output

The 'show ip ospf database' command displays the entire OSPF link-state database, organized by LSA type. Each section corresponds to a different LSA type: Type 1 (Router), Type 2 (Network), Type 3 (Summary), Type 4 (ASBR Summary), and Type 5 (External). The 'Link ID' field identifies the LSA's origin (e.g., Router ID for Type 1, DR's interface IP for Type 2).

'ADV Router' is the router that originated the LSA. 'Age' is the time in seconds since the LSA was first created; values approaching 1800 (MaxAge) indicate the LSA is about to be flushed. 'Seq#' is a sequence number that increments with each update; a higher number means a more recent LSA.

'Checksum' is used for error detection. In a stable network, ages should be relatively low and consistent, and sequence numbers should not be jumping erratically. Missing or incomplete sections can indicate adjacency problems or misconfigurations (e.g., no Type 3 LSAs if ABR is not working).

Configuration Scenarios

Verify OSPF Database After Configuring a New Area

After adding a new area (Area 1) to an existing OSPF network, you need to verify that the ABR is correctly summarizing routes and that routers in other areas see the new routes.

Topology

R1(Area 0)---(Gi0/0)10.0.12.0/30---(Gi0/0)R2(ABR)---(Gi0/1)10.0.23.0/30---(Gi0/0)R3(Area 1)

Steps

  1. 1.Step 1: Enter privileged EXEC mode on R2: R2> enable
  2. 2.Step 2: Display the OSPF database summary to see LSA counts: R2# show ip ospf database database-summary
  3. 3.Step 3: Check for Type 3 Summary LSAs from R2 to Area 0: R2# show ip ospf database summary
  4. 4.Step 4: Verify that R1 sees the Type 3 LSAs for Area 1 networks: R1# show ip ospf database summary
Configuration
! On R2 (ABR)
router ospf 1
 network 10.0.12.0 0.0.0.3 area 0
 network 10.0.23.0 0.0.0.3 area 1
! On R1
router ospf 1
 network 10.0.12.0 0.0.0.3 area 0
! On R3
router ospf 1
 network 10.0.23.0 0.0.0.3 area 1

Verify: On R1, the command 'show ip ospf database summary' should show Type 3 LSAs with Link State ID representing the network 10.0.23.0/30, advertising router R2's router ID. The output should include 'Summary Net Link States (Area 0)'.

Watch out: A common mistake is forgetting that ABRs only generate Type 3 LSAs for inter-area routes if the network is not a stub area. If Area 1 is configured as a stub, Type 3 LSAs are still generated but Type 5 are blocked. Ensure area type matches design.

Troubleshoot Missing External Routes Using Type 5 LSAs

A router in Area 0 is not receiving external routes redistributed from EIGRP on an ASBR in Area 1. You need to verify that the Type 5 LSAs are present in the database.

Topology

R1(ASBR, Area 1)---(Gi0/0)10.0.12.0/30---(Gi0/0)R2(ABR)---(Gi0/1)10.0.23.0/30---(Gi0/0)R3(Area 0)

Steps

  1. 1.Step 1: On R1 (ASBR), verify redistribution is configured: R1# show running-config | section router ospf
  2. 2.Step 2: On R1, check that Type 5 LSAs are originated: R1# show ip ospf database external self-originate
  3. 3.Step 3: On R2 (ABR), check if Type 5 LSAs are present: R2# show ip ospf database external
  4. 4.Step 4: On R3, check if Type 5 LSAs are present: R3# show ip ospf database external
Configuration
! On R1 (ASBR)
router ospf 1
 redistribute eigrp 100 subnets
! On R2 (ABR)
router ospf 1
 network 10.0.12.0 0.0.0.3 area 1
 network 10.0.23.0 0.0.0.3 area 0
! On R3
router ospf 1
 network 10.0.23.0 0.0.0.3 area 0

Verify: On R3, 'show ip ospf database external' should show Type 5 LSAs with the redistributed routes. If not, check that R2 is not in a stub area (stub areas block Type 5). Also verify that R1's router ID is reachable.

Watch out: If Area 1 is configured as a stub or NSSA, Type 5 LSAs are not flooded into that area. Instead, Type 7 LSAs are used and translated to Type 5 by the ABR. Ensure area type matches redistribution requirements.

Troubleshooting with This Command

The 'show ip ospf database' command is a primary tool for diagnosing OSPF routing issues. A healthy OSPF database should contain consistent LSAs from all routers in the area, with no missing or duplicate entries. Key indicators of a healthy database include: all expected Router LSAs (Type 1) present with correct link information, Network LSAs (Type 2) for multi-access segments, and appropriate Summary/External LSAs for inter-area and external routes.

The sequence numbers should be increasing and consistent across routers. Common problems that this command helps diagnose include: missing LSAs (indicating adjacency issues or LSA flooding problems), corrupt LSAs (checksum errors), stale LSAs (high age), and LSA type mismatches (e.g., Type 5 in a stub area). When troubleshooting, start with 'show ip ospf database database-summary' to get a high-level view of LSA counts per type and area.

Compare the counts with expected values based on network design. For example, if a router is missing Type 1 LSAs from a neighbor, check OSPF adjacency with 'show ip ospf neighbor'. If Type 3 LSAs are missing, verify ABR configuration and area type.

If external routes are missing, check redistribution on the ASBR and ensure Type 5 LSAs are present. Focus on the 'Link State ID', 'Advertising Router', and 'Age' fields. A high age (close to 3600 seconds) indicates an LSA that is about to expire, possibly due to a neighbor being unreachable.

Checksum errors are rare but indicate corruption; if seen, investigate hardware or software issues. A step-by-step diagnostic flow: 1) Check OSPF neighbor states with 'show ip ospf neighbor'. 2) Use 'show ip ospf database database-summary' to see LSA counts. 3) If counts are low, check for missing LSAs by type. 4) For missing Type 1, investigate the specific router. 5) For missing Type 3, check ABR and area configuration. 6) For missing Type 5, check ASBR and redistribution. 7) Use 'show ip ospf database <type> link-state-id' to examine a specific LSA in detail. Correlate with 'debug ip ospf lsa' to see LSA updates in real time.

Also, 'show ip ospf interface' can reveal interface-level issues like mismatched MTU or timers that prevent adjacency formation. In summary, the database command provides the raw data needed to pinpoint OSPF problems, and mastering its output is essential for efficient troubleshooting.

CCNA Exam Tips

1.

CCNA exam tip: Know that Type 1 LSAs are generated by every router, Type 2 by the DR, Type 3 by ABRs, Type 4 by ABRs for ASBRs, and Type 5 by ASBRs.

2.

CCNA exam tip: The 'show ip ospf database' command is used to verify that the LSDB is synchronized; if an LSA is missing, the route will not be in the routing table.

3.

CCNA exam tip: In the exam, you may be asked to identify which router is the DR based on Type 2 LSA output (the Link ID is the DR's interface IP).

4.

CCNA exam tip: A high 'Age' value (close to 1800) indicates the LSA is about to expire; if it resets to 0, the LSA was refreshed. Frequent refreshes may indicate a flapping link.

Common Mistakes

Mistake 1: Confusing 'Link ID' with 'ADV Router' — the Link ID identifies the object (e.g., router ID or network), while ADV Router is the router that sent the LSA.

Mistake 2: Assuming that missing Type 5 LSAs mean no external routes exist — check if the ASBR is properly configured and reachable.

Mistake 3: Ignoring the 'Age' field — if ages are consistently high or vary wildly, it may indicate OSPF instability or a router with a bad clock.

show ip ospf database vs show ip ospf

Both commands are used to verify OSPF operation but serve different purposes: `show ip ospf database` dives into the link-state database, while `show ip ospf` provides process-level overview. They are often confused because their names differ only by the word 'database'.

Aspectshow ip ospf databaseshow ip ospf
ScopeEntire LSDB (all LSA types)OSPF process parameters and area statistics
Output DetailLists every LSA with age, sequence, link-state IDRouter ID, SPF runs, neighbor counts, LSDB size
Typical Use CaseTroubleshoot missing or corrupt LSAs, verify LSDB consistencyVerify OSPF process is running, check router ID, area configuration
Impact on RouterHigher CPU if LSDB is large (scans all LSAs)Low CPU (reads process counters)
Information HierarchyGives per-LSA details, not per-area or per-process summariesProvides per-area and per-process summary statistics

Use show ip ospf database when you need to inspect individual LSAs to troubleshoot OSPF network reachability or database corruption.

Use show ip ospf when you want a quick health check of the OSPF process, including router ID, neighbor counts, and area parameters.

Platform Notes

On Cisco IOS-XE (e.g., Catalyst 9000 switches), the 'show ip ospf database' command syntax and output are largely identical to classic IOS. However, IOS-XE may support additional parameters like 'show ip ospf database opaque-area' for MPLS-TE. The output format is similar but may include additional fields such as 'Instance ID' for multi-instance OSPF.

On NX-OS (Cisco Nexus switches), the equivalent command is 'show ip ospf database' but with different output formatting. NX-OS also supports 'show ip ospf database internal' for detailed LSA information. On ASA firewalls, OSPF is supported but the command is 'show ospf database' (without 'ip').

The output is similar but may lack some advanced LSA types. On IOS-XR, the command is 'show ospf database' and the output is significantly different, organized by LSA type and area with more granular filtering options. For example, 'show ospf database router' displays Router LSAs.

IOS-XR also supports 'show ospf database opaque' for TE. In terms of version differences, IOS 12.x and 15.x have similar output, but 15.x introduced support for OSPFv3 and additional LSA types. IOS 16.x (IOS-XE) maintains backward compatibility.

Always check the specific platform documentation, as some features like 'opaque-link' may not be supported on all platforms. When migrating from classic IOS to IOS-XE, the command remains the same, but output may be paginated differently. On NX-OS, note that OSPFv2 and OSPFv3 are separate processes, so use 'show ip ospf database' for IPv4 and 'show ipv6 ospf database' for IPv6.

Overall, while the core functionality is consistent, engineers should be aware of platform-specific nuances to avoid confusion.

Related Commands

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions