Route summarisation concept — aggregation, prefix length, route-map filtering

A route summary is a single prefix that the routing table treats as a destination for a whole block of more-specific prefixes. The operator who advertises 198.51.100.0/22 is asserting “the packets for 198.51.100.0/24, 198.51.101.0/24, 198.51.102.0/24, and 198.51.103.0/24 all flow through me”. The neighbour does not need to know each component; one entry is enough to keep forwarding correct and the control plane quiet.

This lesson is the conceptual reference for the part: why a production routing estate summarises, what summarisation changes about forwarding and control plane, and the route-map primitive that decides what leaks past the aggregate.

What summarisation is for

A routing estate that does not summarise grows linearly with the number of prefixes. A regional ISP with 10000 customer prefixes and 200 peers advertises 10000 routes to every peer and absorbs 10000 routes from every peer. The FIB (Forwarding Information Base) on every edge router carries the full table. The control plane (BGP UPDATE messages, OSPF LSA floods, RIPv2 responses) is saturated by the constant refresh of routes that did not actually change.

Summarisation collapses many prefixes into one:

flowchart LR
  subgraph "Without summarisation"
    A1["198.51.100.0/24"]
    A2["198.51.101.0/24"]
    A3["198.51.102.0/24"]
    A4["198.51.103.0/24"]
    P1["Peer"]
    A1 --> P1
    A2 --> P1
    A3 --> P1
    A4 --> P1
  end

  subgraph "With summarisation"
    A5["198.51.100.0/22"]
    P2["Peer"]
    A5 --> P2
  end

The peer sees one entry instead of four. The local router carries four (or more) components in its own table plus the aggregate, but the advertised surface is one. The savings scale with peer count: with 200 peers, the saving is 200 * (4-1) = 600 fewer UPDATEs sent, 600 fewer entries installed in the peer’s Adj-RIB.

Three reasons a production network engineer reaches for summarisation:

1. Control-plane overhead. Every UPDATE consumes CPU on the sender and the receiver. The peer must parse, validate, run best-path, install in Adj-RIB, and propagate. Summarisation drops the per-prefix cost.
2. Route-flap propagation. A flapping more-specific causes constant UPDATE churn. If the flapping component is inside an aggregate, the peer only sees the aggregate; the flap is hidden.
3. Forwarding table size. Longest-prefix-match still applies; the local router needs the more-specifics to forward correctly. But the advertised table is smaller, and the peer’s FIB is smaller.

Summary vs specific

The two routes look the same to a router that does not have more information, but they are different objects in the operator’s inventory:

• Summary (aggregate). A prefix that covers a block of more-specifics. In BGP it is a route this router originates: it appears in the BGP table as a locally-generated entry with next hop 0.0.0.0, and it is not a forwarding entry — nothing in the FIB changes because you configured an aggregate. In OSPF the equivalent is the Type-3 LSA an ABR generates for an area range.
• Specific (more-specific). A prefix that is covered by a summary. The specific is a routable destination in its own right (it has an outgoing interface or next-hop).

flowchart TB
  SUM["198.51.100.0/22 (summary)"]
  S1["198.51.100.0/24 (specific)"]
  S2["198.51.101.0/24 (specific)"]
  S3["198.51.102.0/24 (specific)"]
  S4["198.51.103.0/24 (specific)"]
  SUM --- S1
  SUM --- S2
  SUM --- S3
  SUM --- S4

The longest-prefix-match rule still applies. If a peer receives both 198.51.100.0/22 and 198.51.100.0/24, the /24 wins for traffic to 198.51.100.0/24. The summary is the fallback for any destination inside the block that does not have a more-specific.

The production discipline is to make the choice intentional:

• Advertise only the summary. The peer sees the summary and nothing else. The peer’s forwarding for any specific inside the block uses the summary. This is the BGP summary-only model.
• Advertise summary and specifics. The peer sees both. The peer’s forwarding for an advertised specific uses the specific; for an unadvertised specific, the summary. This is the BGP default behaviour (no summary-only).

Prefix-length arithmetic

A prefix and a prefix length are not two independent choices. A /N is only a network if its address has zeroes in the last 32 - N bits; write anything else and you have named a host inside a network rather than the network. The arithmetic that decides this is one division, and it is worth being able to do it without a calculator.

For a /N whose boundary falls inside the third octet, the block size in third-octet units is 2^(24 - N):

So, for the block in this lesson — 198.51.100.0/24 through 198.51.103.0/24:

• /22 is the right length. Four /24s need a block of four, and 100 ÷ 4 = 25 exactly, so 198.51.100.0 is a legal /22 network. It covers third octets 100, 101, 102, 103 — precisely the four components and nothing else.
• /23 is too small. 198.51.100.0/23 covers only 100 and 101; 102 and 103 would still have to be advertised separately, which is not aggregation so much as a partial one.
• /21 is too large, and not in the way you would guess. 100 ÷ 8 = 12.5, so 198.51.100.0 is not a legal /21 network. The /21 that contains it starts at 198.51.96.0 and covers third octets 96 through 103 — so the aggregate would additionally claim 198.51.96.0/24 through 198.51.99.0/24, four blocks the operator does not own.

The rule, stated once: the summary is the shortest prefix that contains every component and whose own address is a legal network for that length. Both halves matter, and the second is the one that gets skipped.

The VyOS configuration for the aligned aggregate, on the 1.5 tree where origination lives under the address family:

set protocols bgp system-as 64512
set protocols bgp address-family ipv4-unicast aggregate-address '198.51.100.0/22'

Route-map filtering

The operator who has a summary and wants to filter the more-specifics that escape it uses a route-map. This is the BGP configuration that decides “what leaves the router”:

set policy prefix-list SUMMARY rule 10 action 'permit'
set policy prefix-list SUMMARY rule 10 prefix '198.51.100.0/22'

set policy route-map TO-UPSTREAM rule 10 action 'permit'
set policy route-map TO-UPSTREAM rule 10 description 'the aggregate, and only the aggregate'
set policy route-map TO-UPSTREAM rule 10 match ip address prefix-list 'SUMMARY'

set protocols bgp neighbor 10.0.0.2 address-family ipv4-unicast route-map export 'TO-UPSTREAM'

Two levers exist and they are not interchangeable.

summary-only on the aggregate node suppresses the more-specifics everywhere — it is a property of the aggregate, not of a session, so it applies to every peer, iBGP included. That is what you want when the components are an implementation detail nobody outside should see.

A route-map export on a neighbour is per-session. It is the tool when different peers should see different things: the aggregate to the upstream, the components internally. Note the deliberate absence of a terminating permit rule above — this map advertises the aggregate and withdraws everything else to that peer, which is the intent here and a serious accident anywhere else.

flowchart LR
  LOC["Loc-RIB<br/>(198.51.100.0/22 summary)<br/>(198.51.100.0/24 specific)<br/>(198.51.101.0/24 specific)"]
  OUTMAP["route-map OUTBOUND-POLICY<br/>on peer 10.0.0.2"]
  PEER["Peer 10.0.0.2"]
  LOC --> OUTMAP
  OUTMAP -- "summary-only / suppress specific" --> PEER
  OUTMAP -- "permit summary and specific" --> PEER

The OSPF analogue is the area range configuration on the ABR, which controls the Type-3 LSA that the ABR generates. The RIPv2 analogue is the automatic summarisation on classful boundaries.

The aggregation spectrum

Summarisation is not binary. The operator has a spectrum:

1. No summary. Every specific is advertised. The peer’s table is large. The control plane is busy. Route flaps propagate.
2. Summary and specifics. The summary appears; the specifics remain. The peer’s table is larger; the summary offers no savings. Common when the operator wants the summary as a “guarantee of reachability” but specific routes still need to be visible for traffic engineering.
3. Summary only. The summary appears; the specifics are suppressed. The peer’s table is small. The control plane is quiet. Route flaps inside the summary are hidden.
4. Summary only with discard. A blackhole (or null0) route for the summary covers the case where the operator advertises the summary but does not have every specific locally — the missing specifics are discarded, not forwarded to a default route.

Validation

The validation commands:

# The aggregate is in the BGP table, and the prefix reads back
# exactly as written - if it does not, the normaliser changed it
show ip bgp 198.51.100.0/22

# The components are present and forwarding
show ip route 198.51.100.0/24
show ip route 198.51.101.0/24
show ip route 198.51.102.0/24
show ip route 198.51.103.0/24

# What the peer actually receives - count the prefixes, do not skim
show ip bgp neighbors 10.0.0.2 advertised-routes

# The OSPF equivalent, for an ABR generating a Type-3 for the range
show ip ospf database summary

# The discard route, if the aggregate covers space this router lacks
show ip route 198.51.100.0/22

The last one is read for a specific word: the entry should name blackhole (or Null0 in FRR’s rendering of the same thing). An aggregate with a next-hop that points anywhere real is the loop this lesson warns about, not a discard.

show ip ospf database summary takes an optional link-state ID, which for a Type-3 is the network address on its own — 198.51.100.0, not a prefix with a length. Passing it a prefix is a common way to get an empty result and conclude the LSA is missing when it is not.

A clean validation: every specific is reachable from the local router, the aggregate is present and reads back with the prefix you typed, the aggregate is advertised to the peer and the components are or are not as intended, and a discard exists for any space the aggregate covers that this router cannot route.

Production failure modes

The three failure modes the operator must recognise:

Missing summary

show ip bgp neighbors 10.0.0.2 advertised-routes does not include the summary. The most likely causes:

• The summary was never configured.
• The summary was configured but no components exist in the BGP table; BGP aggregate-address is not generated without at least one component.
• The summary is filtered by outbound policy on the peer.

More-specific leaks

The operator wanted summary-only but the specifics are still in advertised-routes. The most likely cause: the summary-only keyword is missing from the aggregate-address statement, or the outbound policy permits the specifics.

Attributes that did not come from the components

The aggregate is a route this router originates. It is not one of the components with a shorter mask, and it does not inherit their attributes — no AS_PATH from the component origins, none of their communities, none of their MED. Operators are surprised by this in the direction that matters: a community-based policy that worked on the components silently stops applying once the components are suppressed behind an aggregate that carries no communities.

Do not assume what it carries; read it:

show ip bgp 198.51.100.0/22
show ip bgp neighbors 10.0.0.2 advertised-routes

Two nodes on the aggregate address this:

• route-map <name> on the aggregate sets attributes on the generated aggregate — the place to re-apply the communities your downstream policy depends on.
• as-set builds an AS_SET from the component AS_PATHs so the origin ASes are not lost. It has a real cost: an AS_SET aggregate changes whenever a component’s path changes, which re-advertises the aggregate and gives back exactly the flap-hiding that motivated the summary. Some upstreams also filter AS_SET routes. Use it when loop prevention across the aggregation boundary genuinely needs it, not by default.

Rollback

Take a snapshot before the change, from configure mode, so the reversion is a file rather than a reconstruction:

save /config/backups/pre-aggregate.boot

Then the change itself, and the two ways back:

compare

# Remove the aggregate entirely; the more-specifics reappear
delete protocols bgp address-family ipv4-unicast aggregate-address 198.51.100.0/22
commit

# Or keep the aggregate and stop suppressing; both are advertised
delete protocols bgp address-family ipv4-unicast aggregate-address 198.51.100.0/22 summary-only
commit

Note the shape: summary-only is a leaf under the aggregate, so deleting it leaves the aggregate in place. Deleting the aggregate node removes both. Getting these two the wrong way round during an incident turns “advertise more” into “advertise nothing”.

A subtle production issue: when summary-only is removed, the more-specifics are advertised to peers immediately. If the peer’s inbound filter rejects the more-specifics — a common “only-allow-the-aggregate” filter — nothing visible happens on your side and the peer’s forwarding for those blocks changes. Audit the peer’s policy before removing summary-only, and prefer commit-confirm 15 so a wrong guess reverts itself.

Prefer either delete above to rollback N, which applies the stored revision and then restarts the router — on a border router that is a full BGP re-convergence in exchange for removing one line. Where a broader revert is genuinely needed, load the snapshot, compare, and commit-confirm.

Production discipline

Cross-course references

• Part XXV-02 (XXV-VyOS-BGPAdvertise / aggregate-address) covers the BGP-specific configuration of aggregate-address, summary-only, and as-set.
• Part XX-03 (XX-VyOS-OSPFAreas / summarisation) covers the OSPF area range ABR summarisation and the interaction with stub areas.
• Part XXXIV-04 (XXXIV-VyOS-Redistribution / filtering redistributed) covers the route-map primitives used to filter what leaves the local router.
• Part XII-04 (XII-VyOS-StaticRouting / blackhole routes) covers the discard route for summary prefixes that cover blocks the local router does not have.

Quiz