Skip to main content
RunBook Academy

VyOSXXXV · Route SummarisationSummarisation

OSPF summarisation — area range, ABR summarisation, totally-stubby area

Advanced⏱ ~24 minshow ip ospf database summaryshow ip ospf database routershow ip ospf border-routersshow ip routeshow ip ospf interfaceconfigurecomparecommitsaverollbackvtysh

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

Not yet marked complete on this device.

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:

  1. 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.
  2. 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 range only fires when at least one component is in the area’s LSDB.
  • The area range configuration 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 range prefix does not cover the components. The range 10.1.0.0/16 does not summarise 10.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

  1. Q1. An operator wants to summarise intra-area routes inside a non-backbone area without crossing the ABR. Which configuration achieves this?

  2. Q2. In a totally-stubby area, the ABR generates a default route and Type-3 LSAs from other areas are flooded into the area.

  3. 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.

  4. 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.