Multi-Area OSPF

Updated

September 4, 2026

Multi-Area OSPF

Single-area OSPF is the right first lab. Multi-area OSPF exists to bound flooding, summarize, and structure large domains. This chapter extends FRR OSPF into a small multi-area topology in Containerlab (mid-2026 free path)—useful for campus/WAN; fabrics often prefer BGP underlays instead.

Learning goals

By the end of this chapter you can:

  • Explain area, ABR, ASBR, and LSA-type roles at operator level
  • Build a three-router multi-area lab (backbone 0 + spoke area)
  • Summarize at an ABR and predict reachability holes
  • Contrast stub-ish ideas without drowning in edge-case flags
  • Verify with database, route, and failure drills

Concepts

Why areas

Single area Multi-area
Every router full topology Topology flooding scoped
SPF on full graph Smaller SPF domains
Simple Needs backbone rules

Backbone rule (practical)

  • Area 0 is the backbone
  • Non-backbone areas attach via ABRs that touch area 0
  • Virtual links exist for scars—not for greenfield labs

Roles

Role Meaning
ABR Router with interfaces in multiple areas; can summarize
ASBR Injects external routes (redistribution)
Internal All interfaces one area

LSA awareness (not flash cards)

Type idea Carries
Router / network Topology inside area
Summary (ABR) Inter-area prefixes
External From outside OSPF

You operate with: show ip ospf database, show ip ospf border-routers, show ip route.

Summarization

ABR can advertise 10.1.0.0/16 instead of many /24s. Mis-summary → blackholes if holes exist inside the aggregate.

Topology

        area 1              area 0              area 2
   h1--r1---------------abr-r2---------------r3--h2
       (1.1.1.1)         (2.2.2.2)          (3.3.3.3)
Node Areas Notes
r1 1 only internal
r2 0 + 1 + 2 ABR
r3 2 only internal

Links:

Link Subnet Area
r1–r2 10.0.12.0/24 1
r2–r3 10.0.23.0/24 2
r1 LAN 192.168.1.0/24 1
r3 LAN 192.168.3.0/24 2
r2 lo 2.2.2.2/32 0

Optional second area-0 link later; one ABR is enough to learn.

Topology YAML

name: ospf-ma

topology:
  nodes:
    r1:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
      binds:
        - ./config/r1:/etc/frr
    r2:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
      binds:
        - ./config/r2:/etc/frr
    r3:
      kind: linux
      image: quay.io/frrouting/frr:10.2.1
      binds:
        - ./config/r3:/etc/frr
    h1:
      kind: linux
      image: alpine:3.20
      exec:
        - apk add --no-cache iproute2 iputils
        - ip addr add 192.168.1.10/24 dev eth1 && ip link set eth1 up
        - ip route add default via 192.168.1.1
    h2:
      kind: linux
      image: alpine:3.20
      exec:
        - apk add --no-cache iproute2 iputils
        - ip addr add 192.168.3.10/24 dev eth1 && ip link set eth1 up
        - ip route add default via 192.168.3.1

  links:
    - endpoints: ["r1:eth1", "r2:eth1"]
    - endpoints: ["r2:eth2", "r3:eth1"]
    - endpoints: ["h1:eth1", "r1:eth2"]
    - endpoints: ["h2:eth1", "r3:eth2"]

FRR configs

r1 (area 1)

hostname r1
!
interface lo
 ip address 1.1.1.1/32
 ip ospf area 1
!
interface eth1
 ip address 10.0.12.1/24
 ip ospf area 1
!
interface eth2
 ip address 192.168.1.1/24
 ip ospf area 1
!
router ospf
 ospf router-id 1.1.1.1
 passive-interface eth2
!
line vty

r3 (area 2)

Mirror with 3.3.3.3, 10.0.23.2/24 area 2, LAN 192.168.3.1/24 area 2.

r2 (ABR)

hostname r2
!
interface lo
 ip address 2.2.2.2/32
 ip ospf area 0
!
interface eth1
 ip address 10.0.12.2/24
 ip ospf area 1
!
interface eth2
 ip address 10.0.23.1/24
 ip ospf area 2
!
router ospf
 ospf router-id 2.2.2.2
 area 1 range 192.168.0.0/16
 area 2 range 192.168.0.0/16
!
line vty

Careful: broad 192.168.0.0/16 summary is a teaching weapon—it can hide holes. Prefer tight ranges:

 area 1 range 192.168.1.0/24
 area 2 range 192.168.3.0/24

Or summarize only when you own contiguous blocks.

Deploy and baseline

sudo containerlab deploy -t ospf-ma.clab.yml

docker exec clab-ospf-ma-r2 vtysh -c 'show ip ospf neighbor'
docker exec clab-ospf-ma-r2 vtysh -c 'show ip ospf border-routers'
docker exec clab-ospf-ma-r1 vtysh -c 'show ip ospf database'
docker exec clab-ospf-ma-r1 vtysh -c 'show ip route'
docker exec clab-ospf-ma-h1 ping -c 3 192.168.3.10

Predict

  • r2 has neighbors in area 1 and 2
  • r1 sees inter-area path to 192.168.3.0/24 via r2
  • Database on r1 does not contain full area 2 topology detail (summary only)

Observe

Compare show ip ospf database on r1 vs r2. r2 should show more topology.

Drill 1 — Summarization blackhole

On r2:

area 1 range 192.168.0.0/16

Do not put a real 192.168.99.0/24 anywhere, but inject a static on r1 into OSPF… or simpler: summarize too wide then withdraw a component.

Teaching sequence:

  1. Advertise 192.168.1.0/24 only.
  2. Add area 1 range 192.168.0.0/16.
  3. On r3, install a static to 192.168.99.1 via null or missing next hop and redistribute—or ping 192.168.99.1 from r3 side expecting blackhole from r1 if summary exists without component.

Simpler blackhole lab:

# r2 summarizes 192.168.0.0/16 from area 1 while only .1.0/24 exists
# from r3 ping 192.168.1.10 works; ping 192.168.50.10 fails (good)
# If r3 thinks 192.168.50.0 is under summary toward area1, traffic blackholes at ABR

Predict

Summaries without covering specifics attract traffic to ABR then drop.

Fix

Tight ranges; discard routes; or don’t summarize.

Drill 2 — ABR failure

docker stop clab-ospf-ma-r2
docker exec clab-ospf-ma-h1 ping -c 5 192.168.3.10

Predict

Total partition—single ABR is SPOF.
### Design lesson

Redundant ABRs for real campus; dual attachment to area 0.

Drill 3 — Area mismatch

Put r1 eth1 in area 0 by mistake:

interface eth1
 ip ospf area 0

Predict

Adjacency fails or forms wrong; routes missing.
### Observe

show ip ospf neighbor empty/wrong.
### Fix

Restore area 1 both sides.

Stub area ideas (awareness)

Stub/totally stubby/NSSA reduce external LSAs into an area. FRR supports variants—use when external flood is noisy. For this chapter, know why (less type-5 in area) more than every flag combo.

router ospf
 area 1 stub

Retest default injection behavior when you try it.

Multi-area vs fabric BGP

Multi-area OSPF Clos eBGP underlay
Campus/WAN hierarchy DC scale-out
ABR summarization Prefix + policy at leaves
Flooding domains AS boundary policy

Do not force multi-area OSPF onto a leaf-spine if eBGP underlay is the house style.

Verification checklist

Check Command
Neighbors per area show ip ospf neighbor
ABR role show ip ospf border-routers
DB scope show ip ospf database
Inter-area routes show ip route IA flags
Data plane ping h1↔︎h2

Common mistakes

Mistake Symptom
Discontiguous area 0 Weird inter-area failures
Summary too broad Blackholes
Expecting full topology remote area Confusion reading DB
Redistribute without filters Loops/externals everywhere
Single ABR production Outage on maintenance

Summary

  • Multi-area OSPF bounds flooding and enables ABR summarization
  • Area 0 backbone rules still matter in greenfield design
  • Always verify database scope and inter-area routes, not only neighbors
  • Summaries can blackhole—tight ranges and drills
  • Prefer BGP fabrics for Clos; multi-area OSPF for hierarchical campus/WAN

Next: fabric with FRR—package a tighter leaf-spine implementation path and verification kit.