OSPF areas — backbone, stub, NSSA, ABR, and area range aggregation

A single OSPF area has a strict scale ceiling: every router holds the same LSDB and runs Dijkstra against it. At 100 routers, that is manageable. At 1000 routers, every link-state change forces every router to recompute the SPF tree. OSPF areas are the protocol’s answer to scale: partition the OSPF domain into smaller LSDBs, with a special “backbone” area (area 0) holding them together.

The trade-off is that areas do not inter-operate transparently. Type 1 and Type 2 LSAs never cross area boundaries; only Type 3 and Type 4 do, and they are summaries, not detail. Every area design decision is a trade-off between scalability, summarisability, and the cost of routing sub-optimality across the boundary.

The area hierarchy

flowchart TB
  subgraph Backbone["Area 0 (Backbone)"]
    ABR1["ABR-1 (also in Area 1)"]
    ABR2["ABR-2 (also in Area 1)"]
    ABR3["ABR-3 (also in Area 2)"]
    ASBR["ASBR (Type 5 origin)"]
  end
  subgraph Area1["Area 1"]
    R1["R1"]
    R2["R2"]
    ABR1
    ABR2
  end
  subgraph Area2["Area 2 (NSSA)"]
    N1["N1"]
    N2["N2 (ASBR inside the NSSA)"]
    ABR3
  end
  ASBR -. "Type 5 into area 0" .- ABR1
  ABR1 -. "Type 3 into area 1" .- R1
  ABR3 -. "Type 3 into area 2" .- N1
  N2 -. "Type 7 to the NSSA ABR" .- ABR3
  ABR3 -. "Type 7 translated to Type 5" .- Backbone

The canonical rules:

• Every area must have at least one connection to area 0. A non-zero area that has no connection to area 0 produces an isolated topology that other areas cannot reach.
• Every ABR must have at least one interface in area 0 AND one in another area. A router with interfaces in two non-zero areas is not a valid ABR — it is an internal router in each.
• Inter-area routing is hub-and-spoke through area 0. Two non-zero areas do not exchange Type 3 LSAs directly; they exchange Type 3 through area 0.

The command that confirms the area topology is show ip ospf border-routers. It enumerates every router the local router knows to be an ABR or an ASBR, the area the path to it runs through, its cost, and — for ABRs — the ABR flag on the entry. What you are checking is not the numbers but the shape: one entry per ABR you designed, each reachable through the area you expect.

vyos@r-abr1:~$ show ip ospf border-routers

============ OSPF router routing table =============
R    2.2.2.2               [10] area: 0.0.0.0, ABR
via 10.0.0.2, eth0
R    3.3.3.3               [20] area: 0.0.0.0, ABR, ASBR
via 10.0.0.4, eth0

An entry that is missing, or an entry whose area: field names an area you did not expect the path to run through, is the finding. show ip ospf complements this with the per-area view on the local router — how many interfaces it has in each area, how many of its neighbours in that area are Full, and whether the area is flagged as a stub or NSSA.

Area types and their LSA-flooding scope

Opaque LSAs follow the same scoping logic. Type 9 is link-local and Type 10 is area-local, so both exist inside any area type. Type 11 is AS-scoped and therefore follows the Type 5 rule: it does not enter a stub or an NSSA. Opaque LSAs are only present at all when opaque capability is enabled (set protocols ospf parameters opaque-lsa).

The trade-offs:

• Standard — full Type 3/4/5 visibility; the heaviest LSDB.
• Stub — no Type 5 and no Type 4, plus a default route injected by the ABR; saves LSDB size by removing externals.
• Totally-stubby — no Type 5, no Type 4, and no Type 3 inter-area summaries either (just the default); the smallest LSDB.
• NSSA — supports an ASBR inside the area via Type 7, which the NSSA ABR translates into Type 5 on the way into the backbone. This is the area type for “this branch has its own external routes, but the rest of the domain should not see the branch’s raw externals”.

The ABR — what it actually does

The ABR is the router that has at least one interface in area 0 AND at least one interface in another area. Its responsibilities:

1. Translate the intra-area topology of one area into Type 3 summaries in the other. The Type 3’s metric is the ABR’s own cost to reach the destination inside the source area.
2. Originate Type 4 for any ASBR in its attached areas, so routers in other areas can compute a path to the ASBR.
3. Hold the LSDB of every area it participates in. The ABR’s LSDB is the union of the per-area LSDBs; it carries the most memory pressure in a large OSPF domain.
4. Apply area-range aggregation (area X range) and enforce the area type of every area it borders.

flowchart LR
  A0["Area 0 LSDB<br/>Type 1, 2, 3, 4, 5"] --> ABR
  A1["Area 1 LSDB<br/>Type 1, 2 (no Type 5 if stub)"] --> ABR
  ABR --> A0Type3["Area 0 view of Area 1:<br/>Type 3 summaries"]
  ABR --> A1Type3["Area 1 view of Area 0:<br/>Type 3 summaries"]
  ABR --> A0Type4["Area 0 view of the ASBR:<br/>Type 4"]

VyOS offers two ways to place an interface in an area, and they are alternatives — pick one per router and stay consistent:

# Form A - the interface names its area (VyOS 1.4 onward, and the
# form the VyOS documentation leads with)
set interfaces ethernet eth0 address 10.0.0.1/24
set interfaces ethernet eth1 address 10.1.0.1/24
set protocols ospf interface eth0 area 0
set protocols ospf interface eth1 area 1

# Form B - the area names a network, and every interface whose
# address falls inside it joins that area
set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 1 network 10.1.0.0/24

Either way, a router with an interface in area 0 and an interface in area 1 is an ABR. There is no command that declares the role; FRR derives it from the area bindings. show ip ospf on that router reports “This router is an ABR”.

Form A is easier to reason about because the mapping is explicit per interface. Form B is the older idiom and still works, but a readdressed interface can silently change areas — its new address may fall inside a different network statement — which is a genuinely unpleasant failure to debug.

Virtual links

The rule “every area connects to area 0” has an exception. A virtual link tunnels an area-0 adjacency across a transit area so that an area with no physical backbone connection can still be joined to the backbone.

# On ABR1, whose peer across area 1 has router-id 4.4.4.4
set protocols ospf area 1 virtual-link 4.4.4.4

Read that command carefully, because the argument order is the part everyone gets wrong: area 1 is the transit area the link crosses, not the area being rescued, and 4.4.4.4 is the router-id of the far-end ABR, not an interface address.

The constraints RFC 2328 section 15 places on a virtual link are worth memorising, because three of them are the cause of almost every virtual link that will not come up:

• Both endpoints must be ABRs of the transit area.
• The transit area must not be the backbone.
• The transit area must not be a stub or an NSSA. A virtual link across an area configured area-type stub will never establish.
• The command must be configured on both endpoints, each naming the other’s router-id.

Optional sub-options mirror the interface timers, and both ends must agree on them:

set protocols ospf area 1 virtual-link 4.4.4.4 hello-interval 10
set protocols ospf area 1 virtual-link 4.4.4.4 dead-interval 40
set protocols ospf area 1 virtual-link 4.4.4.4 retransmit-interval 5
set protocols ospf area 1 virtual-link 4.4.4.4 transmit-delay 1

flowchart LR
  Area0["Area 0"]
  Area1["Area 1 (transit)"]
  Area2["Area 2 (no area-0 connection)"]
  ABR1["ABR1 (area 0 + area 1)"]
  ABR2["ABR2 (area 1 + area 2)"]
  Area0 --- ABR1
  ABR1 --- Area1
  Area1 --- ABR2
  ABR2 --- Area2
  ABR1 -. "Virtual link<br/>(logical area-0 adjacency across area 1)" .-> ABR2

Virtual links are a remediation, not a design. They are appropriate while a new area is being merged into an existing domain and the topology cannot yet be rearranged, and they should be removed once it can. The reasons:

• Every Type 3 and Type 4 destined for the stranded area passes through the transit area, whose LSDB and CPU carry the load.
• The virtual adjacency depends on intra-area routing across the transit area. Any instability there is instability on an area-0 adjacency.
• A virtual link cannot be summarised or filtered the way a real backbone attachment can.

Area range aggregation

The ABR can summarise the intra-area routes it advertises into other areas. This is the area X range primitive:

# Advertise one Type 3 for 192.168.0.0/22 instead of four /24s
set protocols ospf area 1 range 192.168.0.0/22

The mechanism: any intra-area route that falls inside the range is suppressed from the Type 3 summaries the ABR originates; in its place the ABR originates a single Type 3 for the range itself. Note what is not affected — routers inside area 1 still see every /24 in full detail via Type 1 and Type 2. Aggregation only changes what leaves the area.

RFC 2328 section 12.4.3 specifies the metric of that summary as the largest cost among the component routes. VyOS lets you override it, and offers two further modifiers:

# Pin the advertised metric instead of tracking the worst component
set protocols ospf area 1 range 192.168.0.0/22 cost 100

# Suppress the range entirely - components hidden, nothing advertised
set protocols ospf area 1 range 192.168.4.0/22 not-advertise

# Advertise a different prefix in place of the range
set protocols ospf area 1 range 192.168.8.0/22 substitute 10.20.0.0/16

vyos@abr1:~$ show ip ospf database summary

       OSPF Router with ID (1.1.1.1)

Summary Link States (Area 0.0.0.0)

LS age: 600
Options: 0x2  : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: summary-LSA
Link State ID: 192.168.0.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000002
Length: 28
Network Mask: /22
TOS: 0  Metric: 10

What you are confirming in that output is a negative as much as a positive: the range prefix is present, and the component prefixes are not. A Type 3 for 192.168.1.0/24 sitting next to the /22 means the range is not matching what you think it is matching.

Aggregation has two operational consequences:

1. LSDB size reduction. Every other router in area 0 holds one Type 3 instead of four. Across a large area this is the difference between thousands of summary LSAs and a handful, and it is the entire reason multi-area OSPF exists.
2. Routing sub-optimality. Routers outside the area now see one metric for the whole range. If two destinations inside the range have genuinely different best exits, that difference is no longer visible and some traffic takes the worse one.

A two-ABR area whose ABRs are configured with different ranges produces the classic asymmetry: one ABR advertises the /22 while the other still advertises the component /24s, and longest-prefix match sends every packet to the second ABR regardless of which is closer. For consistency, the ABRs of an area must produce the same Type 3 set.

Stub and NSSA — when to choose

Use a stub area when:

• The area does not need to know about external routes.
• All external traffic can leave through the default route.
• The operator wants to reduce the LSDB size.
• There is no ASBR inside the area — and there cannot be. A stub area may not originate Type 5, so redistribution into OSPF from a router inside a stub area has nowhere to go.

Use a totally-stubby area (area-type stub no-summary) when:

• Same as stub, plus the area does not need inter-area detail either — everything that is not local leaves via the ABR.

Use NSSA when:

• The area must accept external routes from an ASBR inside it, which a stub area forbids.
• Those externals should reach the rest of the domain, but the area itself should still be spared the domain’s Type 5 flood.

Never designate an area as stub if any router inside requires full external visibility. The classic mistake: an operator re-designates a standard area as stub, and a downstream monitoring system loses access to an external resource; the diagnostic is “the route used to work, now it doesn’t, but the change should not have affected it.”

Configuration examples

# Backbone plus a sibling area, interface-form bindings
set protocols ospf interface eth0 area 0
set protocols ospf interface eth1 area 0
set protocols ospf interface eth2 area 1

# Stub area (on every router in area 1, ABR included)
set protocols ospf area 1 area-type stub

# Totally-stubby: add no-summary on the ABR only
set protocols ospf area 1 area-type stub no-summary
set protocols ospf area 1 area-type stub default-cost 10

# NSSA (on every router in area 3, ABR included)
set protocols ospf area 3 area-type nssa

# Totally-NSSA: no-summary on the ABR only. This is also how the
# NSSA gets a default route on VyOS 1.5.
set protocols ospf area 3 area-type nssa no-summary

# Force this ABR to be the Type 7 to Type 5 translator rather
# than letting the election pick the highest router-id
set protocols ospf area 3 area-type nssa translate always

# Area range aggregation on an ABR
set protocols ospf area 1 range 192.168.0.0/22

# Virtual link across transit area 1 to the ABR with router-id
# 4.4.4.4 - configure the mirror image on that router too
set protocols ospf area 1 virtual-link 4.4.4.4

A reasonable practice is to label each area with an intent statement in the configuration description or the change record: “area 1 is totally stubby, default-cost 10; area 3 is NSSA with one ASBR; area 0 is the backbone”.

Operational commands

# Local router's per-area view: interface counts, neighbour
# counts, stub/NSSA flags, ABR/ASBR role, virtual adjacencies
show ip ospf

# Every ABR and ASBR this router can reach, and through which area
show ip ospf border-routers

# Type 3 (summary) LSDB entries
show ip ospf database summary

# Type 1 LSAs this router originated - one per area it is in
show ip ospf database router self-originate

# Type 5 externals. On a router inside a stub or NSSA this must
# be empty; anything here means the area type is not being
# honoured somewhere.
show ip ospf database external

# Type 7. The inverse test: present inside an NSSA, absent
# everywhere else.
show ip ospf database nssa-external

# Which interface is in which area, and its state
show ip ospf interface

# The routes OSPF computed, and what actually reached the RIB
show ip ospf route
show ip route ospf

FRR’s show ip ospf database takes an LSA type keyword (router, network, summary, asbr-summary, external, nssa-external, opaque-link, opaque-area, opaque-as) and optionally a Link State ID and self-originate or adv-router A.B.C.D. It does not take an area id as a filter, so show ip ospf database 0.0.0.1 is not a command. The database output is already grouped by area under headings such as “Summary Link States (Area 0.0.0.0)”; read the headings rather than trying to filter.

A robust area-design verification:

# 1. Is every area attached to area 0?
show ip ospf border-routers
# One row per designed ABR. A missing row is a stranded area.

# 2. Are the ABRs where you think they are?
show ip ospf interface
# Each ABR shows interfaces in area 0 and in the non-zero area.

# 3. Is summarisation doing what you configured?
show ip ospf database summary
# The range prefix present, the component prefixes absent.

# 4. Is the stub boundary being honoured?
show ip ospf database external
# On any router inside the stub: empty.

# 5. Is NSSA translation happening?
show ip ospf database nssa-external   # inside the NSSA: Type 7
show ip ospf database external        # in area 0: the Type 5 the ABR made

How it fails — production area failure modes

The stub adjacency that never forms

You add area-type stub on the ABR during a maintenance window and the whole area drops off. The internal routers were never reconfigured, so their Hellos still carry E set while the ABR’s carry E clear, and RFC 2328 section 10.5 makes each side discard the other’s Hello.

Diagnostic: show ip ospf neighbor on the ABR is empty or shows the neighbour stuck below 2-Way, while the link itself is perfectly healthy — the interface is up and pings across it succeed. show ip ospf interface shows the area on each side and show ip ospf reports the stub flag on one side only.

Fix: an area type is an all-or-nothing property of the area. Configure area-type stub on every router with an interface in that area, not just the ABR.

Routing asymmetry between two ABRs of one area

Symptoms: traffic to a prefix inside area 1 leaves through the far ABR even though the near one is closer, and return traffic comes back the other way.

Cause: the two ABRs do not advertise the same Type 3 set. Either one has an area X range the other lacks — so longest-prefix match sends everything to the one still advertising components — or they advertise the same prefix with different metrics.

Diagnostic: show ip ospf database summary on a router in area 0 and compare the advertising routers for the prefix. Two different prefix lengths for the same address space from two ABRs of the same area is the finding.

Fix: make the area X range configuration identical on every ABR of the area, including the cost if one is set.

Stuck virtual link

The virtual adjacency stays at Exstart, or never appears at all.

The cause is one of the RFC 2328 section 15 constraints. In rough order of how often each is the culprit: the transit area is a stub or NSSA; the far end has not been configured with the mirror command; the router-id argument is an interface address rather than the peer’s router-id; or an MTU mismatch on the transit path holds the adjacency at Exstart the same way it would on a physical link.

Diagnostic: show ip ospf neighbor for a neighbour reached over the VIRTUALLINK pseudo-interface and its state; show ip ospf on the transit area for the count of full virtual adjacencies going through it; show ip ospf interface to confirm the pseudo-interface exists at all. If it does not exist, the local configuration is the problem, not the path.

Fix the immediate constraint, then design the virtual link out.

Area-range aggregation hiding an outage

The downstream router has used a summarised /22 for months; one of the /24s behind it goes down. The downstream router does not notice: the /22 still has an active path because its other components are up, and the failed /24 is invisible.

This is not a bug — it is what aggregation is. The discipline is to design the range so that its components share a fate and a path, and to monitor the components inside the area rather than relying on the summary to tell you about them.

Rollback

# In configuration mode: load the previous commit into the
# candidate, apply it, and persist it
rollback 1
commit
save

An area-type change is the one case where the configuration rollback may not be the whole rollback: adjacencies torn down by an E-bit mismatch re-form on their own once the configuration agrees again, but the LSDB needs to re-converge. If it does not settle, bounce the OSPF process on the affected router:

vtysh -c 'clear ip ospf process'

That is FRR’s command, reached through vtysh; it is not a VyOS operational-mode command in its own right. It drops every adjacency on that router, so it is a maintenance-window action, not a diagnostic.

A reasonable discipline: before any area-type change, capture show ip ospf, show ip ospf neighbor and show ip ospf database summary on every router in the area. After the change, compare — every router must agree on the area boundary.

Production discipline

Cross-course references

• Part XVII (XVII-VyOS-RoutingFund) lesson 6 covers routing protocol metrics, which frame the SPF metric derived from cost; areas use cost as the tie-breaker.
• Part XIX (XIX-VyOS-OSPFConfig) covers the per-area configuration (router-id, networks, authentication) in depth.
• Part XX (XX-VyOS-OSPFAreas) is the dedicated treatment of OSPF area design — if this lesson is the introduction, Part XX is the reference.
• Part XXIII (XXIII-VyOS-BGPFund) covers how BGP and OSPF areas interact when the autonomous-system boundary sits at an OSPF ABR.
• RFC 2328 section 3 (areas), section 12 (summary LSAs and their metrics) and section 15 (virtual links); RFC 3101 for NSSA and the P bit.

Quiz