Multi-area design — two-tier hierarchy, hub-and-spoke, scalability limits

OSPF areas exist for two operational reasons: to bound the LSDB size on each router and to bound the cost of an SPF recalculation. A single backbone that carries every LSA in the routing domain works for a small estate, but it does not scale: a backbone with 10,000 LSAs has a non-trivial SPF cost, a large LSDB footprint, and a flooding scope that crosses every router in the domain. The area hierarchy is the answer.

This lesson walks through the design patterns that decide where to put an area boundary and what type the area should be. xx-01 covered the catalogue of area types. xx-02 covered the stub / NSSA mechanism. xx-03 covered summarisation. xx-04 covered the virtual-link escape hatch. This lesson is the design glue that ties them together.

The two-tier hierarchy

OSPF enforces a two-tier hierarchy. The backbone (area 0) is the top tier; every other area is the bottom tier. An area is either the backbone or it is connected to the backbone through an ABR. There is no “level 2” or “level 3” tier in OSPF — the protocol’s loop-free inter-area routing relies on every inter-area path going through area 0.

flowchart TB
  subgraph "Tier 1 — Backbone area 0"
    ABR1[ABR-1]
    ABR2[ABR-2]
    ABR3[ABR-3]
    ABR4[ABR-4]
    ABR1 --- ABR2
    ABR2 --- ABR3
    ABR3 --- ABR4
    ABR4 --- ABR1
  end
  subgraph "Tier 2 — Area 10"
    ABR1
    R10A[R-10A]
    R10B[R-10B]
    ABR1 --- R10A
    R10A --- R10B
  end
  subgraph "Tier 2 — Area 20"
    ABR2
    R20A[R-20A]
    ABR2 --- R20A
  end
  subgraph "Tier 2 — Area 30"
    ABR3
    R30A[R-30A]
    ABR3 --- R30A
  end
  subgraph "Tier 2 — Area 40"
    ABR4
    R40A[R-40A]
    ABR4 --- R40A
  end

In the diagram, the backbone is the hub and each non-backbone area is a spoke. Every spoke connects to the hub through exactly one ABR. This is the strict two-tier model.

The strict model is the textbook. In practice, an area can have multiple ABRs to the backbone — a redundant pair for high availability. The loop-freedom argument still holds because every inter-area path still goes through the backbone, but the operator must be careful about Type 3 LSA generation: each ABR independently generates Type 3 LSAs for the prefixes it knows, and the downstream routers see multiple Type 3s for the same prefix (one per ABR). The downstream router picks the lowest-cost Type 3 as the best path.

flowchart LR
  subgraph "Backbone area 0"
    ABR1[ABR-1]
    ABR2[ABR-2]
    ABR1 --- ABR2
  end
  subgraph "Area 10 (dual-ABR)"
    ABR1
    ABR2
    R10A[R-10A]
    ABR1 --- R10A
    ABR2 --- R10A
  end
  R10A -. "Type 3 LSA via ABR-1" .-> ABR1
  R10A -. "Type 3 LSA via ABR-2" .-> ABR2

In the redundant case, the downstream routers see the same prefix twice (once per ABR) and pick the lowest-cost path. The choice is deterministic but it does change the traffic distribution: a backup ABR can carry traffic during a primary failure.

Why operators distribute areas

Three operational reasons:

1. LSDB size. A router’s LSDB contains every LSA in its area. The memory cost is roughly O(LSAs * LSA_size). A backbone with 50,000 LSAs consumes more memory per router than a 1,000-LSA area. In a large estate, distributing areas is the difference between fitting in a router’s RAM and overflowing it.
2. SPF cost. Every LSA change in an area triggers an SPF recalculation in that area. A small area with 100 LSAs recalculates quickly; a large area with 50,000 LSAs recalculates slowly. The CPU cost is roughly O(LSAs * log(LSAs)) for a sparse topology and worse for dense topologies. Bounding the area size bounds the SPF cost.
3. Summarisation. A multi-area estate lets the operator summarise at the area boundary (xx-03). The downstream routers see summaries, not individual prefixes. The summarisation reduces the LSDB size on the downstream routers and bounds the SPF cost.

The trade-off is operational complexity. A multi-area estate requires the operator to design the area hierarchy, choose area types, configure ABRs, and monitor the area boundaries. A single-area estate is operationally simpler but does not scale.

Hub-and-spoke for remote sites

The most common multi-area design is hub-and-spoke. The backbone is the hub; each remote site is a spoke. The spoke can be a standard area, a stub area, or a totally stubby / totally NSSA area depending on the site’s traffic pattern.

flowchart TB
  subgraph "Hub — Backbone area 0"
    CORE1[Core-1]
    CORE2[Core-2]
    EDGE1[Edge-1]
    EDGE2[Edge-2]
    CORE1 --- EDGE1
    CORE1 --- EDGE2
    CORE2 --- EDGE1
    CORE2 --- EDGE2
  end
  subgraph "Spoke 1 — Area 10 (standard)"
    EDGE1
    R10A[R-10A]
    R10B[R-10B]
    EDGE1 --- R10A
    R10A --- R10B
  end
  subgraph "Spoke 2 — Area 20 (stub)"
    EDGE1
    R20A[R-20A]
    R20B[R-20B]
    EDGE1 --- R20A
    R20A --- R20B
  end
  subgraph "Spoke 3 — Area 30 (totally stubby)"
    EDGE2
    R30A[R-30A]
    EDGE2 --- R30A
  end

In the diagram, the hub runs the backbone and the spokes are remote sites. The site at spoke 1 needs inter-area visibility (standard area), the site at spoke 2 only needs a default route (stub), and the site at spoke 3 has a single uplink and only needs a default (totally stubby).

The hub-and-spoke pattern is what most service-provider networks and many enterprise networks converge on. The rationale:

• The hub has the most routers and the most state. A backbone with 50 routers can carry the routing protocol state for 10 spokes each with 5 routers. The backbone’s LSDB is bounded.
• The spokes have minimal state. A spoke with a totally stubby area has only its own Type 1 / Type 2 LSAs and a single default route. The spoke’s router can be a small-form-factor device.
• The summarisation is natural. Each spoke has its own address space (e.g. 10.10.0.0/16 for spoke 1, 10.20.0.0/16 for spoke 2). The ABR at the hub summarises each spoke into the backbone with a single Type 3 LSA.

Why not distribute more aggressively

A common anti-pattern is to over-distribute. Operators who learned the design pattern sometimes apply it everywhere: every site gets its own area, every site is a totally stubby area, every ABR has a summary. The cost:

• Operational complexity. Every ABR has to be configured, every area boundary has to be monitored, every summary has to be tracked. The number of configuration objects grows with the number of areas.
• Limited benefit at small scale. A 5-router estate in a single area is operationally simpler than a 5-router estate in 3 areas. The area boundary has not bought anything.
• Inter-area routing visibility loss. A spoke that needs to see specific inter-area prefixes for monitoring or for PBR cannot be a totally stubby area. The summarisation is too aggressive.

The discipline is to introduce an area boundary only when one of the three operational reasons (LSDB size, SPF cost, summarisation) is genuinely binding. A 20-router estate in a single area is often acceptable. A 200-router estate in a single area is a problem.

Scalability limits

The hard limits every OSPF estate must respect:

• LSDB size. The router’s LSDB is held in memory. The practical limit is around 30,000-50,000 LSAs per area before memory pressure becomes a problem. Distributing areas below this threshold keeps the estate healthy.
• SPF recalculation cost. Every LSA change triggers SPF. The cost scales with the number of routers and links in the area. A 1,000-router area has a high SPF cost on every change. Distributing areas reduces the cost per change.
• Flooding scope. Every LSA in an area is flooded to every router in the area. A 5,000-router area has a high flooding load on every change. Distributing areas reduces the flooding load.
• Adjacency count. Every router maintains adjacencies with every neighbour. The limit is around 200-400 adjacencies per router before the Hello / LSA processing becomes a bottleneck. The area distribution does not directly bound the adjacency count, but a well-distributed estate naturally has fewer adjacencies per router.

The Cisco OSPF Design Guide (a legacy but still canonical reference) gives rough numbers:

• Single area: up to 100-200 routers, 5,000-10,000 LSAs.
• Multi-area with stub: 200-500 routers per area.
• Multi-area with totally stubby: 500+ routers per area, but the spoke routers are very lightweight.

These numbers are not absolute. Modern hardware can do more, and the operator’s specific traffic pattern matters. But the orders of magnitude are right.

How to choose the area type

The choice of area type is a function of the site’s traffic pattern:

The principle is to use the most restrictive area type that fits the site’s traffic pattern. A site that does not need external prefixes should not pay the cost of carrying them; a site that needs external prefixes should pay the cost of carrying them.

Configuration on VyOS 1.5 LTS

A hub-and-spoke design on VyOS 1.5 LTS:

# Backbone
set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 0 network 10.0.1.0/24

# Spoke 1 — standard area
set protocols ospf area 10 network 10.10.0.0/24

# Spoke 2 — stub area
set protocols ospf area 20 network 10.20.0.0/24
set protocols ospf area 20 area-type stub

# Spoke 3 — totally stubby area (ABR side)
set protocols ospf area 30 network 10.30.0.0/24
set protocols ospf area 30 area-type stub no-summary

# Summarisation at the ABR
set protocols ospf area 10 range 10.10.0.0/16
set protocols ospf area 20 range 10.20.0.0/16
set protocols ospf area 30 range 10.30.0.0/16

The pattern: each spoke has a single area declaration, the area type is set on every router in the spoke, and the ABR summarises the spoke’s address space into a single Type 3 LSA.

How the result is validated

show ip ospf
show ip ospf database
show ip ospf border-routers
show ip ospf statistics
show ip route ospf
vtysh -c 'show ip ospf'
vtysh -c 'show ip ospf database'

What the operator looks for:

• show ip ospf lists every area the router is a member of with the area-type flag (Stub / NSSA) and the number of LSAs in the area.
• show ip ospf border-routers lists the ABRs visible from the area. A spoke sees the hub’s ABRs; the hub sees the ABRs of every spoke.
• show ip ospf statistics shows the SPF recalculation count and the LSA flooding rate. A high rate indicates a flapping interface or a misconfigured area boundary.

How it fails

The production failure modes:

• Over-distribution. The estate has too many areas, each too small. The operational cost outweighs the LSDB / SPF benefit. The fix is to consolidate areas.
• Under-distribution. The estate has too few areas, each too large. The LSDB is overgrown and the SPF cost is high. The fix is to distribute areas where the boundary matters.
• Mismatched summarisation. The ABR summarises a range that spans two areas. The downstream domain sees the summary but cannot tell which area the prefix is in. The fix is to align the summary with the area boundary.
• Stub area used as transit. An area was designed as stub but a later change made it the transit area for a virtual link. The fix is to convert the transit area to standard or to choose a different transit area.
• Area-type mismatch. One router in an area has the wrong area-type. The adjacency fails and the area fragments. The fix is to align the area-type across every router in the area.

Rollback

# Capture the running configuration before the change
show configuration commands | save /tmp/ospf-design-$(date +%s).txt

# Compare
compare

# Commit with a short confirm window
commit-confirm 5

The rollback for a multi-area design change is rollback N and commit. Multi-area design changes are typically planned and applied during a maintenance window.

Production discipline

Cross-course references

• The OSPF fundamentals part covers the LSA types (vyos-xviii-03-lsa-types), the area concept (vyos-xviii-04-areas), and the basic OSPF configuration (vyos-xix-03-ospf-area-config).
• The previous lessons cover the area types (vyos-xx-01-area-types), the stub / NSSA mechanism (vyos-xx-02-stub-nssa), summarisation (vyos-xx-03-summarisation), and virtual links (vyos-xx-04-virtual-links). This lesson is the design glue that ties them together.
• The multi-WAN part (vyos-xxxix-01-multi-wan-concept) covers a related design pattern: how to integrate multiple uplinks into an OSPF estate.
• The ECMP part (vyos-xxxvi-01-ecmp-concept) covers how OSPF interacts with equal-cost paths. Multi-area estates often have ECMP paths between the hub and the spokes.

Quiz