VyOSXXXV · Route SummarisationSummarisation
OSPF summarisation — area range, ABR summarisation, totally-stubby area
What you'll learn
- Configure `area <x> range <prefix>` on the ABR to summarise inter-area routes
- Distinguish intra-area summarisation (not supported) from inter-area summarisation (ABR)
- Apply `not-advertise` to suppress a specific inter-area route
- Configure summarisation across stub, totally-stubby, and NSSA areas
- Diagnose missing summaries, downstream blackholes, and LSA translation issues
Prerequisites
Verified against VyOS 1.5.x LTS (circinus) · VyOS 1.4.x (sagitta) — legacy · FRRouting 10.x (VyOS 1.5) · Linux kernel 6.6 LTS (VyOS 1.5 base) · strongSwan 5.9.x (IPsec) · WireGuard 1.0.x (kernel module + userspace tooling) · 2026-08-15
OSPF summarisation is structurally different from BGP summarisation. OSPF does not summarise inside an area — every intra-area route is a Type-1 (router) or Type-2 (network) LSA with full prefix detail. Summarisation happens between areas, at the Area Border Router (ABR). The ABR generates a Type-3 summary LSA that covers a range of more-specifics and injects it into the backbone.
This lesson is the operator’s reference for the OSPF area range
configuration: where it applies, where it does not, the
interaction with stub and totally-stubby areas, and the
production failure modes that arise when the summary is missing
or wrong.
Where summarisation happens in OSPF
OSPF has a strict hierarchy: Area 0 (the backbone) connects all other areas through ABRs. Intra-area LSAs (Type-1 and Type-2) are flooded within an area only. The ABR translates Type-1 and Type-2 LSAs into Type-3 (summary) LSAs and injects them into the backbone.
flowchart LR
subgraph "Area 1"
N1["10.1.1.0/24"]
N2["10.1.2.0/24"]
N3["10.1.3.0/24"]
N4["10.1.4.0/24"]
end
ABR["ABR<br/>(10.0.0.1 / 10.0.0.2)"]
subgraph "Area 0 (backbone)"
BACKBONE["Backbone routers<br/>see Type-3 summary"]
end
ABR2["ABR2"]
subgraph "Area 2"
N5["10.2.1.0/24"]
end
N1 --> ABR
N2 --> ABR
N3 --> ABR
N4 --> ABR
ABR -- "Type-3 LSA<br/>10.1.0.0/16 (range)" --> BACKBONE
BACKBONE -- "Type-3 LSA<br/>10.2.0.0/16 (range)" --> ABR2
ABR2 --> N5
The summarisation point is the ABR. The ABR generates a single Type-3 LSA covering a range of prefixes; without summarisation, the ABR generates one Type-3 LSA per intra-area prefix.
Two key facts:
- Summarisation is per-ABR, per-area, per-direction. The ABR summarises Type-3 LSAs leaving an area; it does not summarise Type-1 and Type-2 LSAs inside the area.
- Summarisation applies to inter-area routes. The ABR summarises prefixes from the area it serves into the backbone. The ABR does not summarise prefixes from another area (those are passed through unchanged).
The area range configuration
The VyOS configuration:
set protocols ospf area 1 range 10.1.0.0/16
set protocols ospf area 1 range 10.1.0.0/16 cost 10
This tells the ABR: “summarise all intra-area prefixes in area
1 that are covered by 10.1.0.0/16 into a single Type-3 LSA
with cost 10”.
The validation:
vyos@abr:~$ show ip ospf database summary
Summary LSAs (area 0)
LS age: 200
Options: 0x2 : *|--|-|-|--|0|--|--|--|
LS Type: Summary-LSA
LS Id: 10.1.0.0
Advertising Router: 10.0.0.1
LS Seq Number: 80000001
Checksum: 0x...
Length: 28
Network Mask: /16
Metric: 10
The Type-3 LSA has the summary’s network mask (/16) and the configured cost (10). The more-specifics (10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, 10.1.4.0/24) are no longer visible as individual Type-3 LSAs; they are absorbed by the range.
not-advertise — hiding a specific inter-area route
The not-advertise keyword suppresses a specific Type-3 LSA:
set protocols ospf area 1 range 10.1.5.0/24 not-advertise
This tells the ABR: “do not advertise 10.1.5.0/24 into the
backbone at all”. The /24 is reachable from the ABR but is not
visible to any router outside area 1.
Common use case: a route that the operator wants to keep inside the area (e.g., a management network that should not be routed across the backbone).
Summarisation in stub and totally-stubby areas
The interaction between area range and stub area types is a
production-grade subtlety.
Standard area
The ABR generates Type-3 LSAs from intra-area prefixes. The
operator can apply area range to summarise them.
Stub area
The ABR does not flood external (Type-5) LSAs into the stub area. The ABR generates a default route (0.0.0.0/0) as a Type-3 LSA into the stub area.
The area range works inside the stub area: the ABR summarises
intra-area Type-1 and Type-2 prefixes into Type-3 LSAs, which
are then flooded inside the stub area and into the backbone.
Totally-stubby area (stub no-summary)
The ABR does not flood Type-3 LSAs into the totally-stubby area. The ABR generates a default route only.
The area range inside the totally-stubby area still works
(the ABR summarises intra-area prefixes into Type-3 LSAs that
go into the backbone), but the ABR does not flood Type-3
LSAs from other areas into the totally-stubby area. From the
perspective of routers inside the totally-stubby area, the
only inter-area route is the default route.
flowchart TB
subgraph "Area 1 (totally-stubby)"
N1["10.1.1.0/24"]
N2["10.1.2.0/24"]
end
ABR["ABR"]
subgraph "Area 0 (backbone)"
BACKBONE["Backbone routers"]
end
N1 --> ABR
N2 --> ABR
ABR -- "Type-3 LSA<br/>10.1.0.0/16 (range)" --> BACKBONE
ABR -- "default route<br/>0.0.0.0/0 only" --> N1
ABR -- "default route<br/>0.0.0.0/0 only" --> N2
NSSA area
The NSSA (Not-So-Stubby Area) allows external routes to be redistributed as Type-7 LSAs inside the NSSA; the ABR translates Type-7 to Type-5 for flooding into the backbone.
The area range inside the NSSA summarises both Type-1/Type-2
(intra-area) and Type-7 (NSSA-external) prefixes. This is a
subtle production trap: the range absorbs both kinds, and the
operator may not realise that Type-7 prefixes are being
summarised.
Cost manipulation on the summary
The area range accepts a cost parameter:
set protocols ospf area 1 range 10.1.0.0/16 cost 10
The cost overrides the default cost calculation. The default
cost of a Type-3 LSA is the cost of the intra-area route being
summarised (the highest cost component if multiple); setting
cost 10 overrides this to 10.
The cost is the metric that downstream routers use to choose between summaries. With multiple ranges, the operator uses cost to traffic-engineer the path selection:
set protocols ospf area 1 range 10.1.0.0/16 cost 10
set protocols ospf area 2 range 10.2.0.0/16 cost 20
Routers in area 0 see two Type-3 LSAs (10.1.0.0/16 cost 10, 10.2.0.0/16 cost 20); traffic to 10.1.x prefers the area 1 path.
Validation
# 1. The summary LSA exists in the backbone
show ip ospf database summary
# 2. The components are not advertised as separate Type-3 LSAs
show ip ospf database summary | include 10.1
# Should show only 10.1.0.0/16, not 10.1.1.0/24, 10.1.2.0/24, etc.
# 3. The summary is in the routing table on the downstream router
show ip route 10.1.0.0/16
# 4. The cost is as configured
show ip ospf database summary 10.1.0.0/16
# Look at the Metric field
# 5. The summary is reachable from outside the area
show ip route 10.1.0.0/16
# Should show the next-hop via the ABR
A common validation gap: the operator sees the summary in the LSDB but the downstream router’s routing table does not have the route. The cause is usually the cost calculation: the summary’s cost is too high relative to the default route, and the downstream router prefers the default.
Production failure modes
Missing summary
show ip ospf database summary does not include the summary.
The most likely causes:
- The components do not exist in the area (no Type-1 or
Type-2 LSAs to summarise). The
area rangeonly fires when at least one component is in the area’s LSDB. - The
area rangeconfiguration is on the wrong ABR. The operator configured the range on a router that is not an ABR for the area (it has no interfaces in area 1). - The
area rangeprefix does not cover the components. The range10.1.0.0/16does not summarise10.2.0.0/16.
Downstream blackhole
The summary is in the LSDB but traffic to the summary’s destination is blackholed. The cause is usually a missing specific inside the area: the area has some but not all of the range’s components, and the ABR summarises whatever is there but does not advertise the missing ones. Traffic for the missing specifics is forwarded to the ABR (which has the summary) but the ABR’s intra-area forwarding for the missing specific fails (no Type-1 or Type-2 LSA for it).
The fix is to ensure the operator’s inventory matches the components actually inside the area. If the operator intends the summary to cover blocks the area does not have, install a blackhole for the summary.
Inter-area LSA translation issues
In multi-vendor OSPF estates, the ABR’s Type-3 LSA generation must match the downstream router’s expectations. Some vendors generate a Type-3 LSA per prefix (the default); others summarise at the ABR automatically. The result of a mismatched summarisation model is asymmetric routing: traffic flows one direction via the summary, the return path via a specific (or vice versa).
The fix is to test with traceroute from both directions and
audit the LSDB on both ends. If the LSA sets disagree, the
operator must align the vendor configurations.
LSA flapping after summarisation
When the operator adds an area range to a live network, the
ABR generates a new Type-3 LSA and withdraws the individual
Type-3 LSAs. The downstream routers must re-run SPF. The
process is fast but visible in CPU spikes.
The discipline: schedule summarisation changes for maintenance windows. The CPU spike is brief but the operator should not be caught by surprise.
Rollback
# Capture the running configuration
show configuration commands | save /tmp/ospf-range-$(date +%s).txt
# Compare
compare
# Remove the range (specifics reappear)
delete protocols ospf area 1 range 10.1.0.0/16
commit
The rollback re-generates one Type-3 LSA per component. The downstream routers re-run SPF and install the specifics. CPU spike; brief convergence.
The disciplined rollback uses commit-confirm:
commit-confirm 5
# If the network does not converge to the expected state in 5 minutes,
# the auto-rollback fires and the previous configuration is restored.
Production discipline
Cross-course references
- Part XVIII-04 (
XVIII-VyOS-OSPFFund/ areas) covers the area hierarchy and the ABR’s role. - Part XIX-02 (
XIX-VyOS-OSPFConfig/ interface config) covers the interface-level OSPF configuration. - Part XX-01 (
XX-VyOS-OSPFAreas/ area types) covers the stub, totally-stubby, NSSA, and other area types. - Part XXXV-05 (
XXXV-VyOS-Summarisation/ null0) covers the blackhole route that protects against missing components. - Part XXXV-06 (
XXXV-VyOS-Summarisation/ troubleshoot) covers the diagnostic method for missing summaries.
Quiz
Knowledge check · 4 questions
Q1. An operator wants to summarise intra-area routes inside a non-backbone area without crossing the ABR. Which configuration achieves this?
Q2. In a totally-stubby area, the ABR generates a default route and Type-3 LSAs from other areas are flooded into the area.
Q3. An ABR has `area 1 range 10.1.0.0/16` configured. Area 1 contains 10.1.1.0/24 and 10.1.2.0/24, but not 10.1.100.0/24 (which is also inside the /16). Traffic from area 0 destined for 10.1.100.99 is forwarded to the ABR but the ABR has no specific for 10.1.100.0/24. What happens?
R-ABR has `area 1 range 10.1.0.0/16` configured. Area 1 contains 10.1.1.0/24 and 10.1.2.0/24. Traffic from area 0 destined for 10.1.100.99 reaches R-ABR (via the /16 summary). R-ABR's intra-area LSDB has no specific for 10.1.100.0/24. R-ABR does not have a blackhole route for the /16.
Q4. An operator has area 1 configured as totally-stubby (`area 1 stub no-summary`). They add `area 1 range 10.1.0.0/16`. The downstream router in area 1 loses connectivity to 10.2.0.0/16 (in area 2). What is the cause?
Area 0 has area 1 (totally-stubby) and area 2 (standard). The ABR has `area 1 stub no-summary` configured. The operator adds `area 1 range 10.1.0.0/16`. After commit, the downstream router in area 1 (which had been using the default route to reach area 2 destinations) loses connectivity to 10.2.0.0/16. The downstream router's routing table no longer has the default route.
Passing score: 75%. Answers are checked in this browser.