Verifying and troubleshooting OSPF

Know which neighbours and prefixes should exist

PC-A, 192.168.1.10/24, needs to reach the server, 192.168.3.10/24. R1 connects PC-A's LAN, R2 joins the router links and R3 connects the server's LAN. All three routers use area 0. R2 should have R1 and R3 as directly attached OSPF neighbours. R1 and R3 learn about each other through R2; they do not need a direct neighbour relationship.

A prefix is an IP network and its mask, such as 192.168.3.0/24. OSPF advertises that network so routers can reach any matching host, including the server. A router ID identifies the OSPF router; it is not the host destination or necessarily an interface address.

Each fault starts independently from the healthy three-router configuration below.

Start with show ip interface brief to check address and up/up state. On the R2–R3 link, R2 Gi0/1 is 10.0.23.1/30 and R3 Gi0/0 is 10.0.23.2/30. If the link or addressing is wrong, fix that before changing OSPF. Then inspect the OSPF interface and neighbour entries on both ends.

Ping success does not prove OSPF can pass. Check filtering of IP protocol 89 and the required multicast traffic.

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

Area mismatch · compare the interface area

The area ID in received OSPF packets must match the area expected on this ordinary link. R2 expects area 0. If R3 uses area 1, the routers reject the incompatible exchange even though an ordinary ping may succeed. Compare the active interface area, not just a process name in the saved configuration.

%OSPF-4-ERRRCV: Received invalid packet: mismatched area ID from 10.0.23.2, GigabitEthernet0/1

Timer mismatch · compare two values on two interfaces

The Hello interval controls how often discovery packets are sent. The Dead interval says how long a router waits without hearing its neighbour before declaring it lost. Both configured values must agree on this link. A shorter interval on one end is not enough to make detection faster; mismatched settings can prevent the adjacency.

Passive router link · keep the LAN passive

A passive interface sends no OSPF Hellos and forms no adjacency. That is useful on the PC LAN, where no OSPF neighbour is expected. It is a fault on R2 Gi0/1 because R3 is there. Repair the affected router link; do not remove the passive policy from every LAN.

R2#show ip ospf interface GigabitEthernet0/1
Internet Address 10.0.23.1/30, Area 0
No Hellos (Passive interface)

ExStart or Exchange · investigate database exchange

ExStart is where neighbours negotiate how to exchange database descriptions. In Exchange, they compare descriptions of their stored records. Repeatedly remaining in these states means discovery has progressed, but synchronisation has not finished.

The maximum transmission unit (MTU) is the largest IP packet the interface can send without fragmentation in this context. A mismatch can cause a router to reject a database description (DBD) packet based on its advertised MTU. A small ping can succeed while this OSPF check fails.

ExStart/Exchange alone does not diagnose MTU. If MTUs agree, inspect loss, filtering, duplicate RIDs and exchange logs.

ip ospf mtu-ignore bypasses the DBD check; it does not fix data-packet MTU.

Duplicate router ID · verify the active identity

OSPF associates topology records with the router that created them. If R2 and R3 both identify themselves as 2.2.2.2, the records no longer describe distinct routers reliably. Give R3 its intended unique ID, then check the ID the running process actually uses.

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

Authentication mismatch · compare the intended policy

Authentication checks whether OSPF packets carry the proof expected by the receiver. If the two ends expect different methods or keys, the link can remain up while OSPF packets are rejected. Compare the approved method and key settings locally without putting real key material into a ticket or screenshot. Disabling authentication just to reach Full leaves the policy fault unresolved.

Restore the intended authentication policy on both ends. See OSPF authentication.

Full neighbours · trace the missing prefix

Full confirms that an adjacency has completed database synchronisation. It does not prove that R3 included its server LAN. A link-state advertisement (LSA) is a stored network record. Check whether R3's record describes 192.168.3.0/24, then check whether R1 can calculate a route from those records.

A broadcast/P2P mismatch can allow Full but prevent route calculation. Compare network types and LSA link descriptions on both ends.

A known OSPF route · check which source won

A router can learn the same prefix from more than one source. Administrative distance compares those sources locally. A smaller distance is preferred for otherwise usable routes to the identical prefix. OSPF path cost is a separate comparison within OSPF; lowering it does not make a default-distance OSPF route beat a default-distance static route.

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

Remove the static only if it is unintended. A usable OSPF route can then install if no preferred source remains.

Verify the repair at both control and data layers

The control plane learns routes through neighbour exchanges and calculations. The data plane forwards the user's packets using the installed result. A repair is complete only when the relevant control checks recover and the intended traffic works in both directions.

Recheck the interface, neighbour, prefix and next hop. Test server 192.168.3.10 ↔ PC-A 192.168.1.10; check gateways and filtering if hosts still fail. Save after validation.

Practise with the OSPF troubleshooting tickets.

Short lab: find one deliberate fault

Start from the working isolated lab and record R2's two Full neighbours. On R3 only, enter passive-interface GigabitEthernet0/0 under router ospf 1. Wait for the neighbour-loss condition to be reflected on both routers. Do not introduce another fault.

Explain the evidence before repairing it. Restore no passive-interface GigabitEthernet0/0 under R3's OSPF process, confirm Full returns, then verify the LAN route and PC-A-to-server traffic. The correct repair changes the setting responsible for the fault, rather than restarting every router.

Sources: Cisco neighbour troubleshooting, ExStart/Exchange checks, database and route issues, and administrative distance.

Test yourself on broken OSPF labs