Verifying and troubleshooting OSPF

A real-life situation

After a night of maintenance, users on LAN 3 call in: they can reach their own server but nothing at head office on LAN 1. R3 can ping R2's interface 10.0.23.1, so the cable is fine. Yet show ip route on R3 shows no OSPF routes at all. One small change made during the night broke the adjacency. This lesson shows how to find it quickly, in a fixed order, using the lab from Configuring single-area OSPFv2.

What you are checking

OSPF builds routes in layers, and each layer depends on the one below it. So you troubleshoot in the same order, from the bottom up:

Why it works this way

Without a neighbour, no LSAs are exchanged. Without LSAs, SPF has nothing to calculate. And even with a correct database, a route only appears if it wins against other sources in the routing table. So a missing route can be caused at any layer, but the layer where things first look wrong tells you what kind of fault it is. Jumping straight to the routing table hides that information.

The key show commands, and what each one answers:

How to verify a healthy network

Know what "good" looks like, so a broken output stands out. On R2 in the working lab:

R2#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           0   FULL/  -        00:00:34    10.0.23.2       GigabitEthernet0/1
1.1.1.1           0   FULL/  -        00:00:39    10.0.12.1       GigabitEthernet0/0

R2#show ip ospf database
            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         612         0x80000004 0x00A1B2 3
2.2.2.2         2.2.2.2         598         0x80000005 0x003C4D 5
3.3.3.3         3.3.3.3         601         0x80000003 0x00E5F6 3

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         1.1.1.1         640         0x80000001 0x00D7E8 1

Fault 1: area mismatch

The night's change: someone re-enabled OSPF on R3's Gi0/0 with ip ospf 1 area 1. R2's side is still in area 0.

%OSPF-4-ERRRCV: Received invalid packet: mismatched area ID from backbone area
must be virtual-link but not found from 10.0.23.2, GigabitEthernet0/1

Fault 2: hello or dead timer mismatch

One router has ip ospf hello-interval 5 and the other uses the default 10. Symptoms: no neighbour, no log message by default. Compare both ends:

debug ip ospf hello will also report "Mismatched hello parameters", as shown in OSPF neighbours and adjacencies. Fix by making the values equal, or remove both with no ip ospf hello-interval and no ip ospf dead-interval.

Fault 3: passive interface on a router link

A tidy-up added passive-interface default to R2 but forgot the no passive-interface lines. Both neighbours disappear, and the interfaces still look perfect in show ip ospf interface brief except for the neighbour count of 0/0.

R2#show ip protocols | begin Passive
  Passive Interface(s):
    GigabitEthernet0/0
    GigabitEthernet0/1
    GigabitEthernet0/2
  Routing Information Sources:
    Gateway         Distance      Last Update
    1.1.1.1              110      00:12:30
    3.3.3.3              110      00:12:30

Fault 4: stuck in EXSTART or EXCHANGE (MTU mismatch)

R2#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           0   EXSTART/  -     00:00:36    10.0.23.2       GigabitEthernet0/1
1.1.1.1           0   FULL/  -        00:00:39    10.0.12.1       GigabitEthernet0/0

Each DBD packet carries the sender's IP MTU (the largest IP packet the interface can send). If R3's Gi0/0 has ip mtu 1400 and R2's Gi0/1 has the default 1500, R2 rejects R3's DBDs. Check show interfaces (MTU) and show ip interface (IP MTU, written as "MTU is ... bytes") on both ends.

Fault 5: duplicate router ID

R3 was replaced overnight, and the new router was configured from a copy of R2's saved configuration, including router-id 2.2.2.2. Router IDs name routers in every LSA, so two routers with the same ID corrupt everyone's map.

%OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 2.2.2.2 from 10.0.23.2 on interface GigabitEthernet0/1

Fault 6: neighbours Full, but a route is missing

All neighbours are Full, yet R1 has no route to LAN 3 (192.168.3.0/24). The adjacency is fine, so look higher up:

• Not advertised. On R3, show ip ospf interface brief does not list Gi0/1. Its network statement is wrong, for example network 192.168.3.0 0.0.0.0 area 0, which only matches an interface whose address is exactly 192.168.3.0. Use network 192.168.3.1 0.0.0.0 area 0 or network 192.168.3.0 0.0.0.255 area 0.
• A better source wins. R1 still has an old static route ip route 192.168.3.0 255.255.255.0 10.0.12.2. Static routes have an administrative distance of 1, OSPF 110, so the routing table shows S instead of O. OSPF knows the route (it is in the database) but it lost. See Administrative distance and metric.
• Network type mismatch. One end of a link is point-to-point and the other broadcast. The neighbours can reach Full, but routes through that link are missing. Compare Network Type in show ip ospf interface.
• Wrong path, not missing. If the route is there but uses an unexpected path, compare interface costs and check that auto-cost reference-bandwidth is the same on all routers (show ip ospf | include Reference).

R1#show ip route 192.168.3.0
Routing entry for 192.168.3.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.0.12.2
      Route metric is 0, traffic share count is 1

Common mistakes

• Starting with the routing table. Check neighbours first: most OSPF faults are adjacency faults.
• Checking only one side of a link. Mismatches only show when you compare both ends.
• Assuming 2WAY/DROTHER is a fault on Ethernet segments.
• Changing the router ID and forgetting clear ip ospf process.
• Using ip ospf mtu-ignore as a permanent fix instead of correcting the MTU.
• Forgetting that old static routes override OSPF because of their lower administrative distance.

💡 Exam tip: CCNA questions often show two routers' configurations or show ip ospf interface outputs and ask why they are not neighbours. Compare area, subnet and mask, hello/dead timers, passive interfaces and router IDs; the process ID is the usual distractor. Know that EXSTART/EXCHANGE points to an MTU mismatch, that 2WAY between DROthers is normal, and which command shows what: neighbours, interfaces, database, routes.

Key takeaways

Check yourself