Multi-Area OSPF
A three-area OSPFv2 domain built and broken on purpose: a totally stubby branch area, an NSSA carrying a simulated ISP default route, ABR summarization on both sides, and a three-fault adjacency troubleshooting pass. Built and verified in PNETLab on Cisco IOSv.
01Topology
Two ABRs, one ASBR, three areas — a small-branch stub site and an Internet-edge NSSA hung off a single Area 0 backbone.
Full configuration approach, verification output, and troubleshooting writeup also live in the GitHub repo.
| Device | Role | Area(s) |
|---|---|---|
| R1 | Area 1 internal router | 1 (totally stubby) |
| R2 | ABR | 0, 1 |
| R3 | ABR | 0, 2 |
| R4 | Area 0 internal router; LAN gateway for PC1; elected DR on the SW1 segment | 0 |
| R5 | Area 2 internal router | 2 (NSSA) |
| R6 | ASBR — redistributes a simulated default route | 2 (NSSA) |
02Addressing
| Segment | Network | Device : Interface | IP |
|---|---|---|---|
| R1 – R2 | 10.1.12.0/30 | R1 : Gi0/0 R2 : Gi0/0 | 10.1.12.1 10.1.12.2 |
| Area 0 backbone (SW1) | 10.1.0.0/24 | R2 : Gi0/1 R3 : Gi0/0 R4 : Gi0/0 | 10.1.0.2 10.1.0.3 10.1.0.4 |
| R3 – R5 | 10.2.35.0/30 | R3 : Gi0/1 R5 : Gi0/0 | 10.2.35.1 10.2.35.2 |
| R5 – R6 | 10.2.56.0/30 | R5 : Gi0/1 R6 : Gi0/0 | 10.2.56.1 10.2.56.2 |
| Area 0 LAN (SW2) | 10.1.10.0/24 | R4 : Gi0/1 PC1 : eth0 | 10.1.10.1 10.1.10.100 |
| R1 loopback (Area 1) | 172.16.1.0/24 | R1 : Lo0 | 172.16.1.1 |
| R5 loopback (Area 2) | 172.16.5.0/24 | R5 : Lo0 | 172.16.5.1 |
| R6 loopback (simulated ISP) | 172.16.6.0/24 | R6 : Lo0 | 172.16.6.1 |
03What I built
Single-area baseline first
Brought up OSPF process 1 on all six routers against the addressing table with no area-type commands, and confirmed FULL adjacency on every link before touching stub, NSSA, or summarization — multi-area faults compound fast if you build on a shaky base.
Deterministic DR election
R2, R3, and R4 share the SW1 multi-access segment. Set R4's priority so it wins DR deterministically, rather than leaving it to boot order.
Totally stubby Area 1
R1 sits on a single-homed link with no need for inter-area or external visibility, so Area 1 suppresses both down to one default route from R2.
NSSA Area 2
R6 needed to inject a locally simulated ISP default route without the rest of the domain being flooded with standard Type 5 externals — the textbook NSSA use case.
ABR summarization both sides
R1's and R5's loopback networks are each collapsed to a single /24 at their respective ABR before crossing into the backbone, instead of leaking host-specific routes across the domain.
LAN segment kept off the adjacency list
R4's Gi0/1 advertises 10.1.10.0/24 into OSPF without ever attempting to form a neighbor relationship with anything on that segment.
Configuration approach
! Totally stubby Area 1 — ABR (R2) suppresses Type 3 and Type 5
router ospf 1
area 1 stub no-summary
! Area 1 internal router (R1) — stub flag must match on every router in the area
router ospf 1
area 1 stub
! Summarize R1's loopback at the Area 1 ABR
area 1 range 172.16.1.0 255.255.255.0
! NSSA Area 2 — on both R3 (ABR) and R5 (internal)
area 2 nssa
! Summarize R5's loopback at the Area 2 ABR
area 2 range 172.16.5.0 255.255.255.0
! R6 (ASBR) — get the existing static default into OSPF as an NSSA external
default-information originate
! R4 — advertise the LAN subnet, never peer on it
passive-interface GigabitEthernet0/104Verification & results
Every checkpoint below was confirmed against live console output before moving on to the next stage.
All six routers reached FULL adjacency on every configured link, with R4 confirmed as DR and R2/R3 as DROTHER on the SW1 segment.
R1's routing table holds exactly one OSPF route — a single O*IA 0.0.0.0/0 default via R2 — confirming Area 1 is genuinely totally stubby, not just stub.
172.16.1.0/24 appears as a single summarized route at R3, R4, R5, and R6, rather than as unaggregated host routes.
R3's LSA database confirms the NSSA translation chain — a Type 7 external for 172.16.6.0 originated by R6 (6.6.6.6), and a Type 5 external for the same network translated and re-originated by R3 (3.3.3.3) into Area 0.
End-to-end reachability confirmed from PC1 — 5/5 ping success to both R1's loopback (172.16.1.1) and R6's simulated ISP loopback (172.16.6.1).
R1 reaches 172.16.6.0/24 via its single default route, which is the correct behaviour for a totally stubby area — R2 and R4, sitting in Area 0, both carry the explicit O E2 entry for it.
R3 — show ip ospf database (excerpt)
Type-7 AS External Link States (Area 2)
Link ID ADV Router Age Seq# Checksum Tag
172.16.6.0 6.6.6.6 359 0x80000001 0x005421 0
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
172.16.6.0 3.3.3.3 307 0x80000001 0x00C50C 0PC1 — end-to-end verification
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
PC1> ping 172.16.6.1
84 bytes from 172.16.6.1 icmp_seq=1 ttl=252 time=14.474 ms
84 bytes from 172.16.6.1 icmp_seq=2 ttl=252 time=12.489 ms
84 bytes from 172.16.6.1 icmp_seq=3 ttl=252 time=14.985 ms
84 bytes from 172.16.6.1 icmp_seq=4 ttl=252 time=13.394 ms
84 bytes from 172.16.6.1 icmp_seq=5 ttl=252 time=11.687 ms05Troubleshooting scenario
A separate set of startup-configs loads the same topology with three independent adjacency faults already injected — one per classic failure category. All three were found and fixed; the MTU mismatch was the one that actually made me stop and think.
R1 – R2: stuck DOWN/INIT
Area-ID mismatch — one side's network statement placed the link in the wrong area, so the Hello packets never agreed on area membership.
SW1 segment (R4): flapping neighbors
Hello/Dead timer mismatch on one router's interface, out of step with the defaults the other two were using on the same multi-access segment.
R3 – R5 The one that got me
Stuck in EXSTART/EXCHANGE. Both sides showed FULL Hello exchange and reached 2-way, so the first instinct is to suspect timers or area type again — but the neighbors were agreeing on everything Hello packets carry. The actual cause was an MTU mismatch: one interface was left at a non-default MTU, and IOS refuses to complete the Database Description exchange when the two sides disagree on packet size. Comparing show interfaces MTU on both ends, rather than re-checking timers a second time, is what actually found it.
06Real-world relevance
Stub-site pattern
A small, single-homed branch that never needs full routing visibility is a strong candidate for totally stubby treatment — it keeps the routing table and LSA processing overhead minimal on modest branch hardware, at the cost of only ever seeing a single exit path.
Local-edge pattern
A site with its own Internet or WAN edge, like the R5/R6 pair here, is a natural fit for NSSA: it can inject its own default or external route locally without importing external routes it has no use for.
Verify before you build on it
The main lesson that carried through both the challenge build and the troubleshooting scenario: 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.