BGP Route Aggregation: Summary-Only Mode

Introduction

In my previous post on BGP Route Aggregation, I demonstrated how the aggregate-address command creates a summary route while continuing to advertise the more-specific component routes alongside it. I also showed how to use prefix lists to selectively control which neighbors see the aggregate versus the specifics.

But there’s a simpler, more direct approach when you want only the summary route advertised to everyone: the summary-only keyword.

This post focuses specifically on this option, what it does under the hood, and how it compares to IGP summarization behavior.

Default BGP Aggregation vs IGP Summarization

This is a key concept worth understanding before diving into the lab.

In IGP protocols like OSPF and EIGRP, when you configure route summarization at a boundary (area border router or distribution point), the summarization is exclusive by default: only the summary route is advertised outward, and the more-specific routes are suppressed. This is the behavior most engineers intuitively expect from summarization.

BGP behaves differently by default. When you configure aggregate-address, BGP:

Creates and advertises the aggregate route
Continues advertising all the more-specific component routes as well

This means both the summary AND the specifics are advertised to all neighbors simultaneously, which is not always desirable and can actually increase routing table size at the receiving end.

The summary-only keyword restores the IGP-like behavior: only the aggregate is advertised, and all component routes are suppressed.

Lab Topology

Same multi-AS topology used throughout this BGP series:

AS 100: R-1
AS 200: R-2, R-3, R-4 (iBGP full mesh)
AS 500: R-5 (eBGP peer with R-3)
AS 600: R-6 (eBGP peer with R-4)

In this scenario, R-3 in AS 200 has four loopback interfaces simulating networks in the 103.1.20.0/22 range:

R-3#sh ip int brief
Loopback101  103.1.20.1  255.255.255.0
Loopback102  103.1.21.1  255.255.255.0
Loopback103  103.1.22.1  255.255.255.0
Loopback104  103.1.23.1  255.255.255.0

These four contiguous /24 networks aggregate cleanly into a single /22:

103.1.20.0/24  ┐
103.1.21.0/24  ├──► 103.1.20.0/22
103.1.22.0/24  │
103.1.23.0/24  ┘

Configuration

Step 1: Advertise the Component Networks

First, advertise the four specific /24 networks into BGP using network statements:

R-3(config)#router bgp 200
R-3(config-router)#network 103.1.20.0 mask 255.255.255.0
R-3(config-router)#network 103.1.21.0 mask 255.255.255.0
R-3(config-router)#network 103.1.22.0 mask 255.255.255.0
R-3(config-router)#network 103.1.23.0 mask 255.255.255.0

Step 2: Configure Aggregation with summary-only

Add the aggregate address with the summary-only keyword:

R-3(config-router)#aggregate-address 103.1.20.0 255.255.252.0 summary-only

That single line does all the work:

Creates the 103.1.20.0/22 aggregate in the BGP table
Suppresses advertisement of all four /24 component routes
Advertises only the /22 summary to all neighbors (both iBGP and eBGP)

Understanding the Output: The “s” Flag

After applying the configuration, check R-3’s BGP table:

R-3#sh ip bgp | i 103.1.
 s>   103.1.20.0/24    0.0.0.0                  0         32768 i
 *>   103.1.20.0/22    0.0.0.0                            32768 i
 s>   103.1.21.0/24    0.0.0.0                  0         32768 i
 s>   103.1.22.0/24    0.0.0.0                  0         32768 i
 s>   103.1.23.0/24    0.0.0.0                  0         32768 i

The s flag in the status column is the key here. Looking at the BGP status codes:

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

s> on the /24 routes = suppressed and best path. The routes exist locally in the BGP table (R-3 still knows about them for its own forwarding), but they are not advertised to any neighbor.
*> on the /22 = valid and best. This is the only route being advertised outward.

This is an important distinction: summary-only does not delete the component routes from R-3’s own BGP table. They remain locally for R-3’s use, but are withheld from all BGP advertisements.

Verification on Neighbors

eBGP Neighbor (R-5 in AS 500)

R-5#sh ip bgp | i 103.1.
 *>   103.1.20.0/22    192.1.35.3               0             0 200 i

R-5 receives only the /22 aggregate. None of the four /24 specifics appear. The AS-Path shows 200, confirming it arrived via eBGP from AS 200.

iBGP Neighbor (R-2 in AS 200)

R-2#sh ip bgp | i 103.1.
 *>i  103.1.20.0/22    10.3.3.3                 0    100      0 i

R-2 also receives only the /22 aggregate via iBGP (note the i flag indicating iBGP, with next-hop 10.3.3.3 which is R-3’s loopback). No /24 routes are present.

This is a critical point: summary-only suppresses the component routes to ALL neighbors equally – both iBGP and eBGP peers. There is no distinction made between neighbor types.

If you need different behavior for iBGP versus eBGP (e.g., send specifics internally but only the aggregate externally), you need the prefix-list approach covered in the previous post.

summary-only vs Default Aggregation: A Visual Comparison

Default `aggregate-address` (no summary-only)

R-3 BGP Table:                  Advertised to neighbors:
  *> 103.1.20.0/22               *> 103.1.20.0/22
  *> 103.1.20.0/24               *> 103.1.20.0/24
  *> 103.1.21.0/24               *> 103.1.21.0/24
  *> 103.1.22.0/24               *> 103.1.22.0/24
  *> 103.1.23.0/24               *> 103.1.23.0/24
                                 ← 5 routes advertised

`aggregate-address ... summary-only`

R-3 BGP Table:                  Advertised to neighbors:
  *> 103.1.20.0/22               *> 103.1.20.0/22
  s> 103.1.20.0/24
  s> 103.1.21.0/24               ← 1 route advertised
  s> 103.1.22.0/24
  s> 103.1.23.0/24

The reduction is clear: from 5 routes down to 1 for every neighbor.