01Observe
Read the design before touching a router.
Three areas around one backbone. R2 and R3 are the area border routers; R6 is the ASBR at the simulated ISP edge.
Two ABRs, one ASBR, three areas — a small-branch stub site and an Internet-edge NSSA hung off a single Area 0 backbone. Six routers, two L2 switches and one host, built in PNETLab on Cisco IOSv.
Evidence — device roles
R1 Area 1 internal router
R2 ABR — areas 0 and 1
R3 ABR — areas 0 and 2
R4 Area 0 internal · DR · LAN gateway
R5 Area 2 internal router
R6 ASBR — simulated ISP edge
02Build
Single-area baseline first.
Every adjacency FULL before any area type is applied. R4 wins DR on the SW1 segment deterministically, not by boot order.
OSPF process 1 on all six routers against the addressing table, with no area-type commands. FULL adjacency confirmed on every link before touching stub, NSSA or summarisation — multi-area faults compound fast if you build on a shaky base.
Evidence — baseline checkpoint
! all six routers — process 1, no area types
router ospf 1
! confirm FULL on every configured link
! R4 priority set → wins DR on SW1
! R2, R3 → DROTHER
03Configure
Area types and summarisation applied at the ABRs. The LAN is advertised but kept off the adjacency list.
Area 1 made totally stubby, so R1 sees a single default route and nothing else. Area 2 made an NSSA, so R6 can inject a simulated ISP default without flooding the domain with Type 5 externals. Loopbacks summarised to one /24 at each ABR; R4’s LAN interface advertised but passive.
Evidence — configuration approach
! R2 — totally stubby Area 1
router ospf 1
area 1 stub no-summary
area 1 range 172.16.1.0 255.255.255.0
! R1 — stub flag must match
area 1 stub
! R3 and R5 — NSSA Area 2
area 2 nssa
! R3 — summarise R5’s loopback
area 2 range 172.16.5.0 255.255.255.0
! R6 — existing static default into OSPF
default-information originate
! R4 — advertise the LAN, never peer on it
passive-interface GigabitEthernet0/1
04Verify
Confirm each stage against live output.
PC1 → 172.16.1.1: 5 of 5 replies, ttl 253, 11.3–14.3 ms — through R1’s single default route.
R1’s routing table holds exactly one OSPF route — a single O*IA default via R2. 172.16.1.0/24 arrives summarised at R3, R4, R5 and R6. R3’s database shows R6’s Type 7 and the Type 5 it re-originates. PC1 reaches both far loopbacks, five for five.
Evidence — R3 show ip ospf database · PC1 ping
Type-7 AS External Link States (Area 2)
172.16.6.0 6.6.6.6 359 0x80000001
Type-5 AS External Link States
172.16.6.0 3.3.3.3 307 0x80000001
PC1> ping 172.16.1.1
84 bytes from 172.16.1.1 icmp_seq=1 ttl=253 time=14.280 ms
84 bytes from 172.16.1.1 icmp_seq=2 ttl=253 time=11.316 ms
84 bytes from 172.16.1.1 icmp_seq=3 ttl=253 time=12.702 ms
84 bytes from 172.16.1.1 icmp_seq=4 ttl=253 time=11.432 ms
84 bytes from 172.16.1.1 icmp_seq=5 ttl=253 time=13.521 ms
05Break
Load three faults, one per failure category.
Three faults, marked where they live: i. area-ID mismatch, ii. Hello/Dead timers, iii. MTU.
A separate set of startup-configs brings up the same topology with three independent adjacency faults already injected — one per classic failure category. Each fails at a different point in how neighbours form.
Evidence — injected faults
i R1–R2 stuck DOWN/INIT area-ID mismatch
ii SW1·R4 flapping Hello/Dead mismatch
iii R3–R5 EXSTART/EXCHANGE MTU mismatch
06Troubleshoot
The one that got me.
Neighbour state R3 ↔ R5. Before the fix it stalls at EXSTART; after it, the adjacency reaches FULL.
R3–R5 sat in EXSTART/EXCHANGE. Both sides reached 2-way and agreed on everything Hello packets carry, so timers and area type were the wrong suspects. IOS won’t complete the Database Description exchange when the two ends disagree on MTU. Comparing show interfaces on both ends, rather than re-checking timers, found it.
Evidence — what carried through
Confirm each stage is genuinely working
before layering the next one on top.
An adjacency that looks fine at 2-way
can still be broken further up the stack.