The lab and the method
Every ticket uses the five-router lab from Multi-area OSPF design: R1 in area 1, R2 and R4 as ABRs, R3 in area 0, R5 in area 2 and as the ASBR for the partner network 10.50.0.0/16. Read the symptom and the output, decide on a cause, then open the diagnosis.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Ticket 1: area 2 routes are missing in area 0
R3 has no routes for networks in area 2. R4 has neighbours and its own area 2 routes.
R4#show ip ospf | include border|Number of areas Number of areas in this router is 1. 1 normal 0 stub 0 nssa
R4#show running-config | section router ospf router ospf 1 router-id 4.4.4.4 network 10.2.45.0 0.0.0.3 area 2
Show diagnosis
R4 has only one area, so it is not an ABR and has no link into area 0. The R3–R4 link (10.0.34.0/30) is missing from the process, so R3 and R4 have no adjacency. Add network 10.0.34.0 0.0.0.3 area 0 on R4. Then show ip ospf shows it is an area border router with two areas.
Ticket 2: R1 and R2 never become neighbours
The R1–R2 link is up and pings work. Someone configured area 1 as a stub on R1 only.
R2#show ip ospf neighbor (no output)
R1#show ip ospf | include Area|stub Area 1 It is a stub area
Show diagnosis
Hello packets carry a stub flag. If one side sets it and the other does not, the hello is rejected and no adjacency forms. Both ends of every link in the area must agree. Configure area 1 stub on R2 as well (every router in the area needs it). Compare area ID and authentication too, which cause the same symptom.
Ticket 3: a failed subnet times out instead of being unreachable
R2 summarises 172.16.0.0/22. LAN 1 (172.16.1.0/24) fails. Users elsewhere see timeouts and traffic seems to disappear.
R3#show ip route 172.16.1.5 Routing entry for 172.16.0.0/22 Known via "ospf 1", distance 110, metric 3, type inter area * 10.0.23.1, from 2.2.2.2, via GigabitEthernet0/0
R2#show ip route 172.16.0.0 255.255.252.0 Routing entry for 172.16.0.0/22 Known via "ospf 1", distance 110, metric 1 Routing Descriptor Blocks: * directly connected, via Null0
Show diagnosis
While other /24 networks remain, R2 keeps advertising the /22. Traffic for the failed /24 still matches the summary and reaches R2, where the ABR's discard route sends it to Null0. This is correct behaviour for a summary, and it is why failed hosts time out rather than being reported unreachable. If users need quick feedback, add more specific monitoring for the /24 or avoid summarising networks that need individual reachability checks.
Ticket 4: area 1 cannot reach the partner network
R1 can reach everything except 10.50.0.0/16 after area 1 was made a stub.
R1#show ip route ospf O*IA 0.0.0.0/0 [110/3] via 10.1.12.2, 00:02:10, GigabitEthernet0/0 O IA 10.0.23.0/30 [110/2] via 10.1.12.2, 00:02:10, GigabitEthernet0/0
Show diagnosis
A stub area blocks type 5 LSAs, so the external partner route is not in R1's table. The ABR injects a default route instead (O*IA). Traffic to 10.50.0.0/16 should follow that default through R2. If it fails, check that the default reaches R1 and that R2 has the external route. If R1 needs the specific external route, use a normal area. If it only needs a way out, the default is enough.
Check your understanding
R4 reports 'Number of areas in this router is 1'. What does that tell you?
One end of a link has the area as a stub, the other does not. What happens?
Why does traffic to a failed subnet inside a live summary time out?