Latest Cisco, PMP, AWS, CompTIA, Microsoft Materials on SALE Get Now Get Now

BGP Route Aggregation: A Claim About Address Space, Not About Destinations

Network Infrastructure ｜ Configuration ｜ Advanced ｜ 20 min read

Aggregating routes in BGP has one property that makes it different from summarising in an IGP: the aggregate is advertised whether or not the destinations behind it are reachable. An OSPF area range disappears when its last component disappears. A BGP aggregate-address keeps being advertised as long as one contributing prefix remains in the table, and a network statement pointed at a Null0 static keeps being advertised unconditionally. That asymmetry is deliberate — an aggregate that flapped every time a component flapped would defeat the purpose — and it means that aggregation trades stability for the risk of advertising reachability you do not have.

There are two ways to originate an aggregate and they behave differently in exactly that respect. aggregate-address is conditional: it generates the summary only while at least one more-specific prefix exists in the BGP table, so it disappears if everything behind it goes away. A network statement paired with a static route to Null0 is unconditional: the static route always exists, so the prefix is always originated regardless of what is reachable. The first is safer and slightly less stable; the second is perfectly stable and will happily black-hole traffic for a network that is entirely down.

This article covers both and the options that shape them. Section one compares the two origination methods and the conditions each requires. Section two dissects aggregate-address — what it generates, the Null0 discard route it installs, and the suppression behaviour of summary-only. Section three covers selective control: suppress-map, unsuppress-map, and advertise-map. Section four covers what happens to attributes, including AS_SET, ATOMIC_AGGREGATE, and why as-set makes an aggregate unstable. Section five is the failure catalogue, starting with the black hole.

Blog ClaimA BGP aggregate advertises reachability for address space rather than for destinations, which means every aggregation decision is a decision to accept a black hole in exchange for a smaller table — and the only question is whether the trade was made deliberately.
Two origination methods with opposite stability properties, the option set that shapes an aggregate-address, and the Null0 discard route that keeps a black hole from becoming a loop.

What Are the Two Ways to Originate an Aggregate?

Which one should I use?

aggregate-address when the aggregate should reflect whether anything behind it exists, which is the normal case inside a network you control. The network plus Null0 static approach when the prefix must be advertised unconditionally — typically at the internet edge, where withdrawing your own allocation because of an internal failure would be worse than advertising it while part of it is unreachable. The two differ in exactly one respect that matters: aggregate-address requires at least one contributing more-specific in the BGP table, and the static-route method requires nothing at all.

A Deeper Dive into the Two Methods

The conditional method

! Requires at least one more-specific in the BGP table
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0 summary-only
 exit-address-family
!
! Confirm it was generated and see what it looks like
R1# show ip bgp 10.0.0.0/8
BGP routing table entry for 10.0.0.0/8, version 42
Paths: (1 available, best #1, table default)
  Advertised to update-groups: 2
  Local, (aggregated by 65000 10.0.0.1)
    0.0.0.0 from 0.0.0.0 (10.0.0.1)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best
      atomic-aggregate

The unconditional method

! The static route is what makes the network statement fire
ip route 10.0.0.0 255.0.0.0 Null0
!
router bgp 65000
 address-family ipv4 unicast
  network 10.0.0.0 mask 255.0.0.0
 exit-address-family
!
! No atomic-aggregate, and the next hop is the local router
R1# show ip bgp 10.0.0.0/8 | include Origin|Local
  Local
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
! ^ 'sourced' rather than 'aggregated'. This is an origination,
!   not an aggregation, as far as BGP is concerned.

The two compared

Property aggregate-address network + Null0 static
Condition to advertise At least one more-specific in the BGP table None — the static always exists
Withdrawn when everything behind fails Yes No
Stability Good, but not absolute Absolute
Black-hole risk Only while a component survives Always present
ATOMIC_AGGREGATE set Yes, unless as-set is used No
AGGREGATOR set Yes No
Suppresses more-specifics With summary-only No — needs separate filtering
Typical placement Inside your own network, at aggregation points Internet edge, for your own allocation

Why the internet edge usually wants the unconditional form

An operator advertising their own allocation to the internet generally wants that advertisement to be constant. If an internal failure removes every more-specific from the local BGP table, a conditional aggregate is withdrawn — and the entire allocation becomes unreachable from outside, including the parts that a second border router could still have served. An unconditional origination keeps the prefix visible and lets internal routing sort out reachability, which is nearly always the better failure mode at the edge.

! At the internet edge - originate unconditionally on BOTH borders
! BR-1 and BR-2 both run:
ip route 203.0.113.0 255.255.255.0 Null0 250
!
router bgp 65000
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
 exit-address-family
! ^ AD 250 on the static keeps it from beating a real IGP route
!   for the same prefix if one exists.

How this differs from IGP summarisation

An OSPF area range or an EIGRP summary-address withdraws automatically when its last component disappears, because both protocols compute the summary from the components on every SPF or DUAL run. BGP does not work that way: the aggregate is a separately originated path with its own lifetime, and the only linkage to the components is the existence test performed when aggregate-address is used. That difference is why an IGP summary is close to risk-free and a BGP aggregate is not.

The second difference is scope. An IGP summary is withdrawn from a limited area and the failure is contained inside your network. A BGP aggregate is advertised to the internet, and the consequences of getting its boundaries wrong are visible to everyone. Applying IGP habits to BGP aggregation — configuring it at every layer because it seemed harmless in OSPF — produces summaries at points that have no authority over the address space they are claiming.

Property OSPF area range EIGRP summary-address BGP aggregate-address
Withdrawn when components vanish Yes, automatically Yes, automatically Yes, but only aggregate-address
Discard route installed Yes, to Null0 Yes, to Null0 Yes, to Null0
Scope of the advertisement One area boundary One interface Every eBGP peer
Blast radius of a wrong boundary Internal Internal Global
Suppresses components Always Always, on that interface Only with summary-only
Pitfall: aggregating at every layer out of IGP habit Symptom: an aggregate appears in the internet routing table covering address space your organisation does not hold, or covering a range that includes another operator's allocation, and you receive an abuse report or a route-leak notification. Cause: aggregation was configured at an internal distribution layer with boundaries chosen for convenience, and that aggregate propagated to eBGP because no outbound filter distinguished it from a legitimate origination. Confirm: show ip bgp neighbors <peer> advertised-routes and compare every prefix against your allocation records. Fix: aggregate only at points that are authoritative for the space, and back it with an outbound filter listing exactly what your autonomous system may originate — the aggregate should have to pass that filter like anything else.
Originate on both borders, not oneWhichever method you choose, configure it identically on every router that faces an external peer. An allocation originated on one border only disappears from the internet when that router does, which converts a single-device failure into a full outage for the entire prefix. Two borders both originating gives the internet two paths and lets ordinary best-path selection choose between them.
The floating static is deliberateA Null0 static with the default administrative distance of 1 beats every dynamic route for the same prefix, which is harmless when the aggregate is strictly larger than anything in the IGP and harmful when it is not. Adding a high distance — 250 is conventional — means the static exists for the network statement to reference but loses to any real route, which is what you want.
Use both methods in one networkThey are not alternatives to choose between globally. Use the unconditional form at the edge for your own allocations, where constant advertisement is the requirement, and the conditional form at internal aggregation points, where an aggregate that outlives everything behind it is a black hole nobody asked for.
Sub claimThe only meaningful difference between the two methods is whether the advertisement is conditional on something existing — and that single property is what makes one appropriate at the edge and the other appropriate inside.

How Does aggregate-address Actually Work?

What does the command generate?

Three things. A new BGP path for the aggregate prefix, originated locally with a next hop of 0.0.0.0 and a weight of 32768, marked aggregated in the table. A discard route to Null0 in the local RIB, which exists so that traffic arriving for an unreachable part of the aggregated space is dropped locally rather than following a default route back out. And two attributes on the advertised path: ATOMIC_AGGREGATE, recording that AS_PATH detail was discarded, and AGGREGATOR, recording which AS and which router ID performed the aggregation. Without summary-only, the more-specifics continue to be advertised alongside the aggregate.

A Deeper Dive into the Mechanism

The contributing-route requirement

An aggregate is generated only while at least one prefix that falls inside it is present in the BGP table and is a valid best path. A prefix in the RIB but not in BGP does not count, which is the most common reason an aggregate fails to appear — the components are learned by an IGP and were never redistributed or originated into BGP.

! No aggregate appears despite the command being present
R1# show ip bgp 10.0.0.0/8
% Network not in table
!
! Because nothing inside it is in the BGP table
R1# show ip bgp 10.0.0.0/8 longer-prefixes
! (empty)
!
R1# show ip route 10.1.0.0
  Known via "ospf 1", distance 110, metric 20
! ^ It is in the RIB via OSPF but not in BGP. Redistribute it,
!   or originate it with a network statement, and the aggregate appears.
!
router bgp 65000
 address-family ipv4 unicast
  network 10.1.0.0 mask 255.255.0.0
  aggregate-address 10.0.0.0 255.0.0.0 summary-only

The Null0 discard route

Aggregating creates a local route to Null0 for the aggregate prefix. Its purpose is loop prevention rather than filtering. Consider a router advertising 10.0.0.0/8 while only 10.1.0.0/16 is reachable behind it. A packet for 10.9.9.9 arrives, finds no more-specific match, and without the discard route would match a default route pointing back upstream — creating a loop between this router and its upstream that persists until TTL expiry, for every such packet. The Null0 route drops it at the first hop instead.

! The discard route the aggregate installs
R1# show ip route 10.0.0.0 255.0.0.0
Routing entry for 10.0.0.0/8
  Known via "bgp 65000", distance 200, metric 0, type locally generated
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1
!
! Confirm packets for unreachable space are dropped here
R1# show ip cef 10.9.9.9
10.0.0.0/8
  attached to Null0

What summary-only does and does not do

summary-only suppresses the more-specific prefixes so that only the aggregate is advertised. Suppression is per prefix and is visible in the table as an s flag; the suppressed routes remain in the BGP table and remain usable locally, they are simply not advertised to any neighbour. Without the keyword, the aggregate is advertised in addition to every specific, which increases table size rather than reducing it and is almost never the intent.

! With summary-only - specifics are suppressed, marked 's'
R1# show ip bgp
   Network          Next Hop     Metric LocPrf Weight Path
 *> 10.0.0.0/8       0.0.0.0                    32768 i
 s> 10.1.0.0/16      0.0.0.0           0        32768 i
 s> 10.2.0.0/16      0.0.0.0           0        32768 i
 s> 10.3.0.0/16      0.0.0.0           0        32768 i
! 's' = suppressed. Present locally, not advertised.
!
! Verify only the aggregate leaves
R1# show ip bgp neighbors 192.0.2.2 advertised-routes
   Network          Next Hop     Metric LocPrf Weight Path
 *> 10.0.0.0/8       192.0.2.1                  32768 i
! ^ One prefix instead of four. That is the point.

Aggregation happens per router, not per network

An aggregate is generated by the router where the command is configured, using that router's BGP table. Two border routers both need the command, and each generates its own aggregate from whatever it can see. A router that has lost its internal path to every component stops generating the aggregate even though the other border still can — which is correct behaviour and is why the edge case for unconditional origination exists.

! Both borders configure it independently
! BR-1:
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0 summary-only
!
! BR-2: identical
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0 summary-only
!
! Each generates from its own table - verify both
BR-2# show ip bgp 10.0.0.0/8 | include aggregated
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best

Aggregation and iBGP

An aggregate generated on one router is an ordinary locally originated path as far as iBGP is concerned, so it propagates to internal peers normally and the suppressed components do not. That has a consequence people find surprising: internal routers behind the aggregating router lose visibility of the specifics too, and their forwarding for those destinations follows the aggregate — which resolves at the aggregating router, and from there to Null0 for anything unreachable.

Where internal routers need the specifics — and they usually do, because internal forwarding decisions depend on them — either aggregate only on the border routers facing eBGP, or use suppress-map so suppression applies to what leaves the autonomous system rather than to the internal table. Aggregating at a route reflector is a particularly effective way to make an entire cluster lose visibility at once.

! Aggregate on the border only, not in the core
! BR-1 (faces eBGP):
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0 summary-only
!
! Internal routers keep the specifics because they peer with the RR,
! not with the border's eBGP session.
R-CORE# show ip bgp 10.0.0.0/8 longer-prefixes | include Total
Total number of prefixes 4
!
! ...but on the aggregating router itself they are suppressed
BR-1# show ip bgp | include ^s
 s> 10.1.0.0/16      0.0.0.0     0    32768 i
 s> 10.2.0.0/16      0.0.0.0     0    32768 i
! ^ Suppressed for advertisement, still installed locally.
Pitfall: an aggregate that never appears Symptom: aggregate-address is configured, the syntax is accepted, and the aggregate is absent from the BGP table and from every neighbour's view. Cause: no prefix inside the aggregate range exists in the BGP table as a valid best path — usually because the components live in the RIB via an IGP and were never redistributed or originated into BGP. Confirm: show ip bgp 10.0.0.0/8 longer-prefixes returns nothing. Fix: originate at least one component with a network statement or redistribute the IGP into BGP. Verify with the same longer-prefixes command before concluding the aggregation itself is wrong.
Sub claimThe Null0 route an aggregate installs is loop prevention rather than filtering — without it, every packet for unreachable space inside the aggregate would follow the default route straight back to the router that advertised it.

How Do I Control Which Components Contribute and Which Are Suppressed?

What are the three maps for?

suppress-map replaces the all-or-nothing behaviour of summary-only with a selective one: prefixes the map permits are suppressed and everything else is still advertised. advertise-map selects which contributing prefixes' attributes are used to build the aggregate, which matters mainly when as-set is in use and you want the AS_SET built from a subset. attribute-map sets attributes on the generated aggregate itself, which is how an aggregate gets a community tag. A fourth, neighbor unsuppress-map, works in the opposite direction — it re-advertises specific suppressed prefixes to one particular neighbour.

A Deeper Dive into Selective Control

suppress-map for partial suppression

The common requirement is to advertise the aggregate plus one or two specifics — a more-specific that must remain visible for traffic engineering, while the rest of the range collapses into the summary. suppress-map expresses that by naming the prefixes to hide rather than hiding everything.

! Suppress everything except 10.5.0.0/16, which stays visible
ip prefix-list HIDE-THESE seq 5 permit 10.0.0.0/8 ge 16 le 16
ip prefix-list HIDE-THESE seq 10 deny 10.5.0.0/16
!
! Careful: a prefix-list is evaluated in order. Deny first.
ip prefix-list HIDE-THESE-2 seq 5 deny 10.5.0.0/16
ip prefix-list HIDE-THESE-2 seq 10 permit 10.0.0.0/8 ge 16 le 16
!
route-map SUPPRESS-MOST permit 10
 match ip address prefix-list HIDE-THESE-2
!
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0 suppress-map SUPPRESS-MOST
 exit-address-family
!
R1# show ip bgp | include 10\.
 *> 10.0.0.0/8       0.0.0.0        32768 i
 s> 10.1.0.0/16      0.0.0.0    0   32768 i
 *> 10.5.0.0/16      0.0.0.0    0   32768 i
 s> 10.6.0.0/16      0.0.0.0    0   32768 i
! ^ 10.5.0.0/16 is not suppressed. Everything else is.

unsuppress-map for per-neighbour exceptions

Where summary-only has already suppressed everything, neighbor unsuppress-map re-enables specific prefixes toward one neighbour only. This is the standard tool for inbound traffic engineering across two providers: advertise the aggregate to both, and un-suppress a more-specific toward the provider you want that traffic to arrive on.

! Aggregate suppresses everything globally...
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0 summary-only
!
! ...but this one neighbour also gets a specific
ip prefix-list TE-SPECIFIC seq 5 permit 10.5.0.0/16
route-map UNSUPPRESS-TRANSIT-A permit 10
 match ip address prefix-list TE-SPECIFIC
!
router bgp 65000
 address-family ipv4 unicast
  neighbor 192.0.2.2 unsuppress-map UNSUPPRESS-TRANSIT-A
 exit-address-family
!
! Verify the difference between the two neighbours
R1# show ip bgp neighbors 192.0.2.2 advertised-routes | include 10\.
 *> 10.0.0.0/8       192.0.2.1    32768 i
 *> 10.5.0.0/16      192.0.2.1    32768 i
R1# show ip bgp neighbors 192.0.2.6 advertised-routes | include 10\.
 *> 10.0.0.0/8       192.0.2.5    32768 i
! ^ Only transit A sees the specific, so traffic for it arrives there.

attribute-map for tagging the aggregate

The generated aggregate is a new path with default attributes, which means it carries no community and will be rejected by any egress policy that matches a class community. Tagging it is a routine requirement and attribute-map is how it is done.

! The aggregate needs the same origination tag a network statement gets
route-map TAG-AGGREGATE permit 10
 set community 65000:1900 additive
 set origin igp
!
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0 summary-only attribute-map TAG-AGGREGATE
 exit-address-family
!
R1# show ip bgp 10.0.0.0/8 | include Community
      Community: 65000:1900

The same commands for IPv6

Everything in this article applies unchanged to IPv6, with the syntax adjusted for prefix-length notation rather than a dotted mask. The one difference worth noting is that IPv6 allocations are usually large and sparsely used, so the gap between "address space I hold" and "destinations that exist" is far wider — which makes the black-hole property more pronounced, not less. An IPv6 aggregate covering a /32 with a handful of /48s deployed behind it is discarding an enormous range into Null0, and that is the intended behaviour.

! IPv6 aggregation - same semantics, prefix-length syntax
router bgp 65000
 address-family ipv6 unicast
  aggregate-address 2001:db8::/32 summary-only
  network 2001:db8:1::/48
  network 2001:db8:2::/48
 exit-address-family
!
! The unconditional form, for the edge
ipv6 route 2001:db8::/32 Null0 250
!
router bgp 65000
 address-family ipv6 unicast
  network 2001:db8::/32
 exit-address-family
!
! Verify separately - IPv4 policy does not apply here
R1# show bgp ipv6 unicast 2001:db8::/32 | include aggregated|atomic
R1# show bgp ipv6 unicast neighbors 2001:db8:ffff::2 advertised-routes | include Total

The three maps compared

Map Applies to Effect of a permit Typical use
suppress-map Contributing more-specifics That prefix is suppressed Advertise the aggregate plus a few specifics
advertise-map Contributing more-specifics That prefix contributes attributes Controlling which paths build the AS_SET
attribute-map The generated aggregate Attributes are set on the aggregate Tagging with a community; setting origin
unsuppress-map Suppressed prefixes, per neighbour That prefix is advertised to this peer Inbound traffic engineering
Un-suppressing a specific is inbound traffic engineering that worksUnlike prepending, which a provider can override with local preference, a more-specific prefix wins on longest match and cannot be overruled by policy. Advertising the aggregate everywhere and one specific toward a single provider is therefore the most reliable inbound traffic-engineering tool available — at the cost of adding a prefix to the global table, which is why it should be used sparingly and only where the aggregate alone has failed.
Prefer unsuppress-map to a second aggregateWhen one more-specific must reach one provider, un-suppressing it toward that neighbour is one line and leaves the global policy intact. Building a second, narrower aggregate to achieve the same visibility changes what everyone sees and is much harder to reason about six months later.
Sub claimSuppression is global and un-suppression is per neighbour, which makes summary-only plus unsuppress-map the natural pairing for any design where one provider needs to see more than the others.

What Happens to the Attributes of an Aggregate?

Which attributes does an aggregate carry?

By default it carries none of its contributors' attributes. The aggregate is a new path originated by the aggregating router, with an empty AS_PATH, an origin of IGP, and a next hop of 0.0.0.0 — the contributors' AS paths, communities, and MEDs are all discarded. Two attributes record that this happened: ATOMIC_AGGREGATE marks that path information was lost and instructs downstream routers not to de-aggregate, and AGGREGATOR names the AS and router ID that performed the aggregation. The as-set keyword changes this by constructing an AS_SET from the contributors' paths, which preserves loop protection at the cost of stability.

A Deeper Dive into Aggregate Attributes

What is lost, and why it matters

Discarding the contributors' AS paths means the aggregate appears to originate in your autonomous system even when the components came from customers with their own AS numbers. Downstream, nobody can tell that AS 65100's address space is inside your 10.0.0.0/8 advertisement, which breaks their ability to filter on origin AS and removes the loop protection AS_PATH would have provided for those prefixes. ATOMIC_AGGREGATE is the flag that says this happened; it does not restore anything.

! Without as-set: the aggregate has an empty path
R-PEER# show ip bgp 10.0.0.0/8
  65000
    198.51.0.5 from 198.51.0.5 (10.0.0.1)
      Origin IGP, localpref 100, valid, external, best
      atomic-aggregate, Aggregator 65000 10.0.0.1
! ^ The customer ASes behind this are invisible.
!
! With as-set: contributor ASes are preserved in braces
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0 summary-only as-set
!
R-PEER# show ip bgp 10.0.0.0/8
  65000 {65100,65200,65300}
    198.51.0.5 from 198.51.0.5 (10.0.0.1)
      Origin IGP, localpref 100, valid, external, best
      Aggregator 65000 10.0.0.1
! ^ No atomic-aggregate now: nothing was lost. AS_SET counts as
!   one hop at best-path step four regardless of its size.

Why as-set makes an aggregate unstable

The AS_SET is built from the contributors present at the moment the aggregate is computed. When a contributor is withdrawn, the AS_SET changes and the aggregate must be re-advertised with a new AS_PATH. On an aggregate covering many customers, that means every customer flap propagates a change to the entire internet — which is precisely the churn aggregation was supposed to eliminate. Most operators therefore accept ATOMIC_AGGREGATE and do not use as-set.

! One contributor withdraws, and the aggregate's path changes
%BGP-5-ADJCHANGE: neighbor 192.0.2.10 Down Interface flap
!
R1# show ip bgp 10.0.0.0/8 | include ^  65000
  65000 {65100,65200}
! ^ Was {65100,65200,65300}. Every downstream router now receives
!   an update for the aggregate because one customer flapped.
!
! Watch the churn as version numbers increment
R1# show ip bgp 10.0.0.0/8 | include version
BGP routing table entry for 10.0.0.0/8, version 1847

Origin, MED, and next hop on the aggregate

Attribute On the generated aggregate Inherited from contributors How to control it
AS_PATH Empty, or an AS_SET with as-set Only with as-set as-set, advertise-map
ORIGIN IGP No attribute-map with set origin
NEXT_HOP 0.0.0.0 locally; own address on eBGP No Normal next-hop rules
MED Not set No attribute-map with set metric
LOCAL_PREF Default, usually 100 No attribute-map
COMMUNITY None No attribute-map with set community
ATOMIC_AGGREGATE Set, unless as-set is used — Use as-set to avoid it
AGGREGATOR Set to the local AS and router ID — Not configurable

advertise-map for controlling the AS_SET

When as-set is in use, advertise-map restricts which contributors' attributes are folded into the aggregate. That reduces churn — only flaps among the selected contributors change the AS_SET — and lets you build an aggregate whose path reflects a stable subset rather than every customer behind it.

! Only these two contributors shape the aggregate's attributes
ip prefix-list STABLE-CONTRIBUTORS seq 5 permit 10.1.0.0/16
ip prefix-list STABLE-CONTRIBUTORS seq 10 permit 10.2.0.0/16
!
route-map SELECT-CONTRIBUTORS permit 10
 match ip address prefix-list STABLE-CONTRIBUTORS
!
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0 summary-only as-set advertise-map SELECT-CONTRIBUTORS
 exit-address-family
! ^ The AS_SET is built from these two only. Other contributors
!   still trigger the aggregate to exist, but do not shape its path.
Tag the aggregate the same way you tag an originationAn aggregate is a new prefix your autonomous system originates, so it needs whatever your ingress and egress policy expects an originated prefix to carry — typically a class community. Adding attribute-map at the moment you add aggregate-address, rather than discovering later that the aggregate is being filtered by your own egress policy, saves an outage that is unusually hard to diagnose because everything about the aggregate looks correct locally.
ATOMIC_AGGREGATE is an instruction, not just a markerA router receiving a path with ATOMIC_AGGREGATE set must not de-aggregate it or make assumptions about which more-specifics exist behind it, and must not remove the attribute when propagating. In practice nothing enforces this and few implementations would de-aggregate anyway, but the attribute's presence is a legitimate signal that the advertisement covers address space rather than a set of known destinations.
Sub claimas-set preserves the information ATOMIC_AGGREGATE merely admits was lost, and it costs the stability that motivated aggregating in the first place — which is why most operators choose the flag over the fix.

Which Aggregation Mistakes Cause Blackholes or Churn?

What goes wrong most often?

Five things. An aggregate advertised while the space behind it is unreachable black-holes traffic at the aggregating router. An aggregate configured without summary-only increases table size instead of reducing it. as-set on an aggregate covering many contributors turns every component flap into a global update. An aggregate is never generated because no contributor exists in the BGP table. And a Null0 static configured without a high administrative distance beats a real route for the same prefix and black-holes traffic that was reachable.

A Deeper Dive into the Failure Catalogue

The black hole

The failure everyone knows about and few plan for. You advertise 10.0.0.0/8 while only 10.1.0.0/16 is actually reachable. Every other network on the internet now believes you can reach all of 10.0.0.0/8 and sends you traffic for it, which your router discards into Null0. From the sender's perspective the destination is unreachable with no ICMP indication that anything is wrong — the packets simply vanish.

Pitfall: aggregating address space you do not fully control Symptom: destinations inside your advertised aggregate are unreachable from the internet, with no ICMP unreachable returned, while the same destinations are reachable from inside your network by a different path. Cause: the aggregate covers address space that includes parts you do not host, or parts hosted elsewhere with their own more-specific advertisements that yours competes with. Traffic that matches your aggregate but no more-specific is discarded into Null0. Confirm: show ip cef <destination> on the aggregating router shows Null0; a traceroute from outside stops at your border. Fix: aggregate only address space you are authoritative for and can reach, and verify the aggregate's boundaries against your allocation records rather than against what happens to be in the table today.

The aggregate that adds prefixes instead of removing them

! Without summary-only: the aggregate is ADDED to the specifics
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0
!
R1# show ip bgp neighbors 192.0.2.2 advertised-routes | include Total
Total number of prefixes 5
! ^ Four specifics plus the aggregate. Worse than before.
!
! With summary-only
  aggregate-address 10.0.0.0 255.0.0.0 summary-only
!
R1# show ip bgp neighbors 192.0.2.2 advertised-routes | include Total
Total number of prefixes 1

Measuring whether aggregation was worth it

Aggregation has a cost — the black-hole exposure — and it should buy something measurable. The measurement is the advertised-prefix count per external neighbour, before and after. If a four-line aggregate replaced four prefixes with one, the saving is three prefixes and the exposure is the unreachable portion of a /8; that trade is probably not worth making. If it replaced two hundred with one, it is. Running the count is one command and turns aggregation from a habit into a decision.

The same number is worth monitoring continuously, because it is also the leak detector. An advertised count that jumps by orders of magnitude means either an aggregate stopped suppressing or an outbound filter stopped filtering, and both are visible within one update cycle.

! Before configuring the aggregate
R1# show ip bgp neighbors 198.51.0.6 advertised-routes | include Total
Total number of prefixes 214
!
! ... configure aggregate-address ... summary-only ...
!
! After
R1# show ip bgp neighbors 198.51.0.6 advertised-routes | include Total
Total number of prefixes 7
! ^ 214 to 7. That is worth the exposure. A saving of three is not.
!
! Confirm what the seven actually are
R1# show ip bgp neighbors 198.51.0.6 advertised-routes

The static route with the wrong distance

! DANGEROUS - AD 1 beats every dynamic route for this prefix
ip route 10.0.0.0 255.0.0.0 Null0
!
! If a real 10.0.0.0/8 route ever exists in the IGP, it loses:
R1# show ip route 10.0.0.0 255.0.0.0
  Known via "static", distance 1, metric 0 (connected)
  * directly connected, via Null0
! ^ Traffic for the whole /8 is now discarded locally.
!
! SAFE - loses to any real route, still satisfies the network statement
ip route 10.0.0.0 255.0.0.0 Null0 250

Choosing aggregate boundaries

The boundaries should come from your allocation records, not from the shape of the current routing table. An aggregate sized to what happens to be in BGP today will be wrong the first time an allocation is returned, sub-allocated, or partly deployed elsewhere — and the error is invisible until traffic for the newly-not-yours part starts arriving. Take the boundaries from the registry object that says what you hold, aggregate to exactly those boundaries, and treat any aggregate that does not correspond to a registered allocation as a defect.

The second rule is to aggregate no further than the allocation. Two adjacent /17s that happen to combine into a /16 you do not hold in full must stay as two /17s. This sounds obvious and is the single most common source of the space-you-do-not-control failure, because combining them looks like exactly the kind of tidying aggregation is for.

! Two /17s we hold, and the /16 we do NOT hold in full
!   203.0.112.0/17  - ours
!   203.0.113.0/24  - ours, inside the above
!   203.0.128.0/17  - NOT ours
!
! WRONG - claims space we do not hold
aggregate-address 203.0.0.0 255.255.0.0 summary-only
!
! RIGHT - aggregate only to the allocation boundary
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 203.0.112.0 255.255.128.0 summary-only
 exit-address-family
!
! Audit every aggregate against the allocation list
R1# show running-config | include aggregate-address
R1# show ip bgp neighbors 198.51.0.6 advertised-routes | include Total

Verification checklist

! 1. Does the aggregate exist, and is it aggregated or sourced?
R1# show ip bgp 10.0.0.0/8 | include aggregated|sourced|atomic
!
! 2. What is contributing to it?
R1# show ip bgp 10.0.0.0/8 longer-prefixes
!
! 3. What is actually advertised, per neighbour?
R1# show ip bgp neighbors 192.0.2.2 advertised-routes | include Total
!
! 4. Is the discard route where it should be?
R1# show ip route 10.0.0.0 255.0.0.0 | include Null0
!
! 5. Is the aggregate churning?
R1# show ip bgp 10.0.0.0/8 | include version
!    A version number climbing steadily is as-set churn.
!
! 6. Does it carry the attributes downstream policy expects?
R1# show ip bgp 10.0.0.0/8 | include Community|Origin
Mistake Symptom Confirming command Fix
Aggregating unreachable space Silent black hole from outside show ip cef <dest> shows Null0 Aggregate only what you are authoritative for
Missing summary-only More prefixes advertised, not fewer advertised-routes | include Total Add the keyword
as-set on a large aggregate Global churn on every component flap Aggregate version number climbing Drop as-set, or scope with advertise-map
No contributing prefix Aggregate never appears show ip bgp <agg> longer-prefixes empty Originate or redistribute a component
Null0 static at AD 1 Real routes for the prefix are discarded show ip route shows distance 1 via Null0 Add a distance of 250
Aggregate with no community Egress policy rejects it show ip bgp <agg> has no Community line attribute-map to tag it
Conditional aggregate at the edge Whole allocation withdrawn on internal failure Prefix absent from a looking glass Use network plus a Null0 static instead
Exam contextAggregation appears in the CCIE Enterprise Infrastructure blueprint's BGP coverage as a configuration and consequence topic: a task specifies what a neighbour must see and expects the aggregate plus the right combination of summary-only, suppress-map, and unsuppress-map. The reliably tested points are that an aggregate requires a contributing more-specific in the BGP table, that summary-only is what suppresses the specifics, and the ATOMIC_AGGREGATE versus as-set distinction. ENARSI 300-410 covers the same commands with less emphasis on the maps.
Sub claimEvery aggregation failure is either a black hole created by advertising space you cannot reach or churn created by making the aggregate depend on things that move — and the two pull in opposite directions.

Conclusion

Aggregation in BGP is a claim about address space, not about destinations, and everything difficult about it follows from that. The claim is useful because it is stable: an aggregate does not change when a component behind it does, which is exactly why aggregation reduces churn across the internet. The claim is dangerous for the same reason: it stays true-looking after it has stopped being true, and traffic for the parts that have gone away is discarded at your border with no signal to the sender.

The two origination methods sit on opposite sides of that trade. aggregate-address is conditional — it withdraws when the last contributor disappears — which limits the black-hole window but means an internal failure can remove your whole allocation from the internet. A network statement over a Null0 static is unconditional, which is the right failure mode at the edge and the wrong one inside. Most networks want both, in different places, and choosing per location rather than per network is the design decision worth making explicitly.

The option that most often gets omitted is summary-only, without which an aggregate adds a prefix rather than replacing several. The option most often added unnecessarily is as-set, which restores the AS path information ATOMIC_AGGREGATE admits was discarded and, in doing so, reintroduces exactly the churn aggregation was meant to suppress. And the check most often skipped is the simplest: show ip bgp neighbors X advertised-routes | include Total before and after. If that number did not go down, the aggregation did not do its job, whatever the configuration says.

Reference Notes

  1. RFC 4271, Section 9.2.2.2 — route aggregation and the conditions under which a BGP speaker may aggregate routes.
  2. RFC 4271, Section 5.1.6 — ATOMIC_AGGREGATE indicates that path information was lost, and a receiver must not de-aggregate the route.
  3. RFC 4271, Section 5.1.7 — the AGGREGATOR attribute carries the AS number and BGP identifier of the aggregating router.
  4. RFC 4271, Section 5.1.2 — AS_SET as an AS_PATH segment type, contributing 1 to path length regardless of the number of AS numbers it contains.
  5. RFC 4632 — the CIDR aggregation model, including the requirement that an aggregate covers only address space the originator is authoritative for.
  6. RFC 7454, Section 6.1 — prefix origination practices and the risks of advertising space that is not fully reachable.
  7. Cisco, "Understanding Route Aggregation in BGP" — an aggregate is generated only while at least one more-specific route exists in the BGP table.
  8. Cisco, "Understanding Route Aggregation in BGP" — summary-only suppresses all more-specific routes; without it the aggregate is advertised in addition to them.
  9. Cisco, "Understanding Route Aggregation in BGP" — as-set generates an AS_SET from contributing paths and suppresses ATOMIC_AGGREGATE.
  10. Cisco IOS-XE BGP Configuration Guide — aggregate-address installs a discard route to Null0 in the local routing table for the aggregated prefix.
  11. Cisco IOS-XE BGP Configuration Guide — suppress-map, advertise-map, and attribute-map keywords and their respective scopes.
  12. Cisco IOS-XE BGP Configuration Guide — neighbor unsuppress-map re-advertises suppressed more-specific routes to a specific neighbour.