OSPF Multi-Area Lab

Single-area OSPF is easy enough that it's easy to never really learn what an area boundary actually changes. This lab is the smallest topology that still shows it: three routers, two areas, one ABR in the middle. Build it in GNS3, Containerlab, EVE-NG, or on real hardware -- the configs below are Cisco IOS-style, but the concepts (and the verification commands) carry over to any vendor.

Topology

R2 is the Area Border Router (ABR) -- one interface in Area 0, one in Area 1. That single fact is what the rest of this lab is actually about.

Objectives

• Bring up OSPF adjacencies across both links and confirm the area assignment on each interface.
• Watch R2 generate Type-3 (summary) LSAs at the area boundary, and see the difference in R1's and R3's own databases as a result.
• Summarize R3's loopback at the ABR and confirm the summary -- not the original route -- is what actually reaches R1.
• Break the Area 0 link on purpose and confirm R1 and R3 lose reachability to each other, even though R2 itself is still fully up -- OSPF's "every non-backbone area must reach Area 0" rule, seen instead of just quoted.

Base configuration

IP addressing from the diagram, OSPF process 1 everywhere, each router's loopback advertised into its own area.

! R1
interface GigabitEthernet0/0
 ip address 10.0.12.1 255.255.255.252
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
router ospf 1
 router-id 1.1.1.1
 network 10.0.12.0 0.0.0.3 area 0
 network 1.1.1.1 0.0.0.0 area 0

! R2 -- the ABR: two interfaces, two different areas
interface GigabitEthernet0/0
 ip address 10.0.12.2 255.255.255.252
!
interface GigabitEthernet0/1
 ip address 10.0.23.1 255.255.255.252
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
router ospf 1
 router-id 2.2.2.2
 network 10.0.12.0 0.0.0.3 area 0
 network 10.0.23.0 0.0.0.3 area 1
 network 2.2.2.2 0.0.0.0 area 0

! R3
interface GigabitEthernet0/0
 ip address 10.0.23.2 255.255.255.252
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
router ospf 1
 router-id 3.3.3.3
 network 10.0.23.0 0.0.0.3 area 1
 network 3.3.3.3 0.0.0.0 area 1

Verify the adjacencies

On R2, both neighbors should show FULL, one against each area:

R2# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        00:00:38    10.0.12.1       GigabitEthernet0/0
3.3.3.3           1   FULL/BDR        00:00:33    10.0.23.2       GigabitEthernet0/1

The actual point: look at the LSA types

Check R1's database. It should have Type-1 (Router) LSAs for itself and R2 (both in Area 0), and a Type-3 (Summary) LSA for 3.3.3.3/32 -- R1 has never seen R3's actual Router LSA, only what R2 summarized about it:

R1# show ip ospf database summary

            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Summary Net Link States (Area 0)

  Link ID         ADV Router      Age         Seq#       Checksum
  3.3.3.3         2.2.2.2         44          0x80000001 0x00a1b2

That's the whole mechanism in one command: R2 didn't forward R3's LSA, it originated a brand new one describing the same destination. Everything inside Area 1 (R3's actual topology, its Router LSA, any other router that might join that area later) stays invisible to Area 0 -- only the reachability summary crosses the boundary. This is exactly why OSPF scales past a few dozen routers where flat single-area designs stop converging cleanly: a change inside Area 1 that doesn't affect reachability (a new subinterface, a metric tweak) never triggers an SPF recalculation on R1 at all.

Summarize at the ABR

Right now every /32 loopback crosses the boundary individually. Pretend Area 1 had 20 routers instead of one -- summarize its whole range at R2 so Area 0 sees one route instead of 20:

R2(config)# router ospf 1
R2(config-router)# area 1 range 3.3.3.0 255.255.255.0

Back on R1, the Type-3 LSA for 3.3.3.3/32 is gone, replaced by one for 3.3.3.0/24 -- the summary, not the original route:

R1# show ip route ospf
     3.0.0.0/24 is subnetted, 1 subnets
O IA     3.3.3.0 [110/2] via 10.0.12.2, 00:01:12, GigabitEthernet0/0

O IA -- inter-area, exactly what it is. If Area 1 had a second loopback subnet in the same summarized range, R1 still wouldn't see it as a separate route; the summary is one route standing in for the whole range.

Break the backbone rule on purpose

Shut down R1–R2's link (R1's only path to Area 0) and watch what happens, even though R2–R3 is untouched:

R1(config)# interface GigabitEthernet0/0
R1(config-if)# shutdown

R1 loses its OSPF adjacency to R2 entirely -- not degraded, gone, because that link was Area 0 itself for R1. R3, still fully adjacent to R2 in Area 1, loses reachability to 1.1.1.1/32 the moment R2's Type-3 LSA for it ages out, even though nothing in Area 1 changed. This is the rule that trips people up in real designs: a non-backbone area's only value is what its ABR can reach in Area 0. Lose that, and the area doesn't route around it through anything, no matter how healthy the area is internally -- OSPF just doesn't have a mechanism for it without a virtual link, which is its own, separate topic.

Where this goes next

Add a fourth router as a second ABR between the same two areas and watch OSPF pick the better path automatically (or, on purpose, watch it not, if both paths are unequal cost). Or stub the non-backbone area (area 1 stub) and see the summary LSAs disappear from R3's database entirely, replaced by a single default route -- the next real lesson in why area types exist.