Day 11 — BGP Aggregation: Summary Routes, ATOMIC_AGGREGATE, AGGREGATOR and the End of AS_SET

at

Learning objective

Create and verify a BGP aggregate from contributing routes, explain the purpose of ATOMIC_AGGREGATE and AGGREGATOR, use summary-only safely, and avoid legacy AS_SET origination that is prohibited by RFC 9774.


BGP Aggregation: Summary Routes, ATOMIC_AGGREGATE, AGGREGATOR and the End of AS_SET
BGP Aggregation: Summary Routes, ATOMIC_AGGREGATE, AGGREGATOR and the End of AS_SET


1. Opening — aggregation reduces detail, and that loss of detail is the point

BGP aggregation takes several more-specific routes and represents them with a less-specific prefix.

That can reduce routing-table scale and hide unnecessary internal detail, but it also changes what downstream routers know. A summary route may remain advertised even when one of its component prefixes disappears. Path information can become less precise. Route-origin security becomes harder when an aggregate's origin semantics are ambiguous.

For years, many BGP tutorials taught aggregate-address ... as-set as a normal method to preserve contributing AS information. That guidance is no longer current.

In May 2025, RFC 9774 updated BGP standards and prohibited the origination of AS_SET and AS_CONFED_SET path segments. This is a major curriculum correction that a current BGP series must make explicit.

Day 11 therefore teaches both:

  • how Cisco aggregation works;
  • how current standards constrain which legacy aggregation techniques should no longer be used.

2. Aggregation versus origination

Day 10 covered network and redistribution as ways to originate local reachability.

Aggregation is different.

Cisco IOS XE documentation describes aggregate-address as creating an aggregate when at least one more-specific contributing route exists in the BGP table.

Conceptually:

203.0.113.0/25
203.0.113.128/25
        |
        +---- aggregate ----> 203.0.113.0/24

The aggregate does not prove both component routes are healthy forever. It proves that the conditions for generating the aggregate are currently met.

That distinction creates both operational value and risk.

3. The aggregate-address control

A basic Cisco aggregation command uses the form:

aggregate-address 203.0.113.0 255.255.255.0

Cisco documentation states that aggregation applies to routes that exist in the BGP table and that the aggregate is generated when at least one more-specific route in the range exists.

Without additional suppression, more-specific component routes can continue to be advertised alongside the aggregate.

This is useful when you want:

  • a stable summary;
  • plus specific routes for traffic engineering or failure visibility.

4. summary-only suppresses the contributing specifics from advertisement

Adding:

aggregate-address 203.0.113.0 255.255.255.0 summary-only

instructs Cisco BGP to advertise the aggregate while suppressing more-specific routes covered by it toward neighbors, subject to other policy and implementation behavior.

This can dramatically reduce downstream routing detail.

But the consequence must be understood:

> Once only the summary is visible, a remote network can no longer distinguish which components are currently backed by more-specific reachability inside the aggregating AS.

This is not automatically bad; it is exactly what summarization is intended to do. It simply means the aggregating AS now owns responsibility for forwarding every destination represented by the summary.

5. ATOMIC_AGGREGATE — a warning that path detail was lost

RFC 4271 defines ATOMIC_AGGREGATE as a well-known discretionary attribute.

Its purpose is informational: the aggregate may not preserve all AS-path detail of its contributing routes. RFC 4271 warns that the actual path to destinations represented by the aggregate may not be exactly the path expressed in the aggregate's AS_PATH.

Cisco IOS XE documentation for traditional aggregation describes ATOMIC_AGGREGATE behavior with aggregate-address when path information is summarized rather than represented as an AS_SET.

Do not interpret ATOMIC_AGGREGATE as a preference value. It is not a “make this route atomic/better” knob.

6. AGGREGATOR — identifying the aggregation point

RFC 4271 defines AGGREGATOR as an optional transitive attribute.

A BGP speaker that performs aggregation may include information identifying:

  • the AS that performed the aggregation;
  • the BGP speaker/identifier associated with that aggregation.

This helps operators understand where an aggregate was formed.

However, attribute visibility in actual CLI output must be verified on the selected platform/release and route. Do not fabricate an AGGREGATOR field in expected output merely because the standard allows it.

7. Critical current standard: RFC 9774 prohibits new AS_SET origination

Older BGP standards and many vendor examples described an AS_SET as a way to place the unordered set of contributing AS numbers into an aggregate's AS_PATH.

RFC 6472 first recommended against that practice.

RFC 9774, published in May 2025, advances the guidance to a standards requirement. It updates RFC 4271 and RFC 5065 and prohibits originating BGP routes containing AS_SET or AS_CONFED_SET path segments.

Why?

Key reasons include:

  • ambiguous route-origin semantics;
  • complications for RPKI-based security;
  • inconsistent or unstable AS_PATH origin interpretation;
  • implementation complexity;
  • limited real-world value.

Therefore this series will not use aggregate-address ... as-set as a recommended production configuration.

Cisco syntax caveat

Cisco documentation may still expose or describe an as-set keyword because implementation documentation can outlive evolving protocol standards.

If the selected IOS XE image accepts the command, that does not make new AS_SET origination appropriate under current IETF standards.

This is exactly why the project separates:

  • standards behavior;
  • vendor CLI availability;
  • recommended production practice.

8. Scenario — Summit Aggregate Boundary

Illustrative lab — not a real incident.

Objective

R1 originates two /25 component prefixes and generates a /24 aggregate toward R2. We first advertise the aggregate plus specifics. Then we enable summary-only. Finally, we remove one component route while leaving the other present to demonstrate that the aggregate can continue to exist even though part of the summarized space has lost its contributing route.

Topology

BGP Aggregation: Summary Routes, ATOMIC_AGGREGATE, AGGREGATOR and the End of AS_SET
BGP Aggregation: Summary Routes, ATOMIC_AGGREGATE, AGGREGATOR and the End of AS_SET


BGP Route Origination: Network Statements, Redistribution and Safe Export Boundaries
203.0.113.0/25 ------\
                       >--- R1 AS65010 --- eBGP --- R2 AS65020
203.0.113.128/25 ----/          |
                         203.0.113.0/24 aggregate

Standards rule

No AS_SET is generated in this lab.

9. Prerequisites

  • Two IOS XE-capable nodes.
  • IOS XE 17.18.x documentation baseline.
  • Console access.
  • Two local component prefixes backed by static routes.
  • Independent management path.

10. Baseline configuration

R1

hostname R1
!
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.252
 no shutdown
!
ip route 203.0.113.0 255.255.255.128 Null0
ip route 203.0.113.128 255.255.255.128 Null0
!
router bgp 65010
 bgp router-id 10.10.10.1
 neighbor 192.0.2.2 remote-as 65020
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.128
  network 203.0.113.128 mask 255.255.255.128
  aggregate-address 203.0.113.0 255.255.255.0
  neighbor 192.0.2.2 activate
 exit-address-family

R2

hostname R2
!
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 no shutdown
!
router bgp 65020
 bgp router-id 10.20.20.2
 neighbor 192.0.2.1 remote-as 65010
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
 exit-address-family

11. Verification before modification

R1

show ip bgp 203.0.113.0 255.255.255.0
show ip bgp 203.0.113.0 255.255.255.128
show ip bgp 203.0.113.128 255.255.255.128
show ip bgp neighbors 192.0.2.2 advertised-routes

R2

show ip bgp
show ip bgp 203.0.113.0 255.255.255.0

Expected logical state:

  • aggregate exists;
  • both components exist;
  • without summary-only, the components remain eligible to be advertised alongside the aggregate, subject to policy.

12. Controlled modification — suppress the specifics

On R1:

configure terminal
router bgp 65010
 address-family ipv4 unicast
  no aggregate-address 203.0.113.0 255.255.255.0
  aggregate-address 203.0.113.0 255.255.255.0 summary-only
 end

Use the least disruptive route re-advertisement method required by the platform if immediate policy propagation is needed.

Expected control-plane result

R2 should retain the /24 aggregate while the two /25 specifics are suppressed from advertisement by the aggregate's summary-only behavior.

13. Fault injection — lose one component but keep the summary

Illustrative lab — not a real incident.

Lab name

Summit Aggregate Boundary — Hidden Component Loss

Fault

On R1, remove one component route and its network statement:

configure terminal
no ip route 203.0.113.128 255.255.255.128 Null0
router bgp 65010
 address-family ipv4 unicast
  no network 203.0.113.128 mask 255.255.255.128
 end

Expected control-plane observation

Because 203.0.113.0/25 still contributes to the aggregate, the /24 can remain generated and advertised.

Operational implication

R2 still sees the summary and cannot infer from that summary alone that one component disappeared.

The actual forwarding result for destinations in the missing component depends on R1's remaining RIB/FIB and network design. Validate it rather than claiming a blackhole automatically.

14. Troubleshooting workflow

  1. Confirm the remote peer still sees the /24 aggregate.
  2. Check whether the missing service maps to a specific component prefix.
  3. On R1, inspect the BGP table for both /25 components.
  4. Inspect the local RIB for both component source routes.
  5. Confirm summary-only is suppressing remote visibility of specifics.
  6. Determine whether the aggregate remains because another component still exists.
  7. Test forwarding to addresses in the healthy component and the failed component separately.
  8. Restore the missing component only if its underlying service/reachability is actually valid.
  9. Re-verify aggregate and component state.
  10. Decide whether the design requires conditional aggregation or additional monitoring to avoid masking this failure class.

15. Root cause and correction

Root cause

One contributing /25 disappeared while another remained, so the /24 aggregate continued to satisfy the aggregate-generation condition.

Correction

Restore the missing component only when its underlying reachability is intentionally available:

ip route 203.0.113.128 255.255.255.128 Null0
router bgp 65010
 address-family ipv4 unicast
  network 203.0.113.128 mask 255.255.255.128

In a real design, do not restore a fake route merely to make BGP look healthy. The source route must represent intentional forwarding behavior.

16. Post-fix verification

On R1:

show ip route 203.0.113.128 255.255.255.128
show ip bgp 203.0.113.128 255.255.255.128
show ip bgp 203.0.113.0 255.255.255.0

On R2:

show ip bgp 203.0.113.0 255.255.255.0

If summary-only remains configured, R2 is expected to validate the summary rather than the hidden component. Component health must be monitored inside the aggregating AS.

17. Rollback

To return to aggregate-plus-specific advertisement:

router bgp 65010
 address-family ipv4 unicast
  no aggregate-address 203.0.113.0 255.255.255.0 summary-only
  aggregate-address 203.0.113.0 255.255.255.0

Do not use an as-set rollback in new designs. Current RFC 9774 requirements prohibit originating AS_SET/AS_CONFED_SET path segments.

18. Production design considerations

Summaries create ownership

If you advertise a /24, your AS is telling neighbors it can handle traffic for the entire /24, not only whichever /25 happens to be healthy today.

Monitor components internally

External visibility of the summary cannot replace internal monitoring of component reachability.

Avoid legacy AS_SET habits

Old lab manuals and remembered CLI patterns may still teach as-set. Current standards supersede that guidance.

Validate RPKI implications

Aggregation changes origin and prefix relationships. When RPKI is introduced later in the series, ROA coverage and MaxLength design must align with the prefixes actually originated.

19. Production lessons

Standards lesson

RFC 9774 is a major post-RFC-4271 update: new AS_SET and AS_CONFED_SET origination is prohibited.

Design lesson

Aggregation reduces routing detail and transfers responsibility for hidden component health to the aggregating AS.

Troubleshooting lesson

A healthy aggregate does not prove every contributing prefix is healthy.

Security lesson

Ambiguous aggregate origins complicate route-origin security; this is one reason AS_SET was deprecated and then prohibited.

Change-management lesson

summary-only changes what downstream operators can observe. Treat that as an observability change as well as a routing change.

20. Knowledge check

Q1

Can a BGP aggregate remain advertised after one component route disappears?

Answer: Yes, if the implementation's aggregate-generation condition is still satisfied by another contributing more-specific route.

Q2

Should a new production design use aggregate-address ... as-set simply because the Cisco CLI accepts it?

Answer: No. RFC 9774 prohibits originating AS_SET and AS_CONFED_SET path segments. Vendor CLI availability does not override current standards requirements.

Q3

What does summary-only change operationally?

Answer: It suppresses advertisement of the covered more-specific routes while retaining the aggregate, reducing downstream detail and increasing the importance of internal component monitoring.

21. Sources

  1. RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — aggregation, ATOMIC_AGGREGATE, AGGREGATOR and route aggregation behavior.
  2. RFC 9774 — *Deprecation of AS_SET and AS_CONFED_SET in BGP* — published May 2025; updates RFC 4271/RFC 5065 and prohibits origination of AS_SET/AS_CONFED_SET path segments.
  3. Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x: BGP 4 / Configuring a Basic BGP Network* — aggregate-address, summary-only and legacy as-set CLI behavior.
  4. Cisco — *Understand Route Aggregation in BGP* — aggregation examples and attribute-loss considerations.

Accessed: 2026-08-11.

Labels:

Featured Post

Day 41 — BGP Confederations: Sub-AS Design, External View and Migration

1. Opening Confederations are another way to scale BGP inside a large administrative domain. They divide the domain into member autonomous systems while presenting a single confederation identifier to external peers. They are powerful, but their operational model is more complex than simply 'using private ASNs inside.' The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture . 2. Concept and standards behavior RFC 5065 defines AS_CONFED_SEQUENCE and AS_CONFED_SET and how member-AS relationships are represented. Confederation external sessions have eBGP-like properties inside the confederation, while the confederation is presented externally as one AS. Modern guidance must also account for the fact that RFC 9774 prohibits new origination of AS_SET/AS_CONFED_SET in ordinary aggregation c...