Day 11 — BGP Aggregation: Summary Routes, ATOMIC_AGGREGATE, AGGREGATOR and the End of AS_SET
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 |
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/24The 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.0Cisco 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-onlyinstructs 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 |
203.0.113.0/25 ------\
>--- R1 AS65010 --- eBGP --- R2 AS65020
203.0.113.128/25 ----/ |
203.0.113.0/24 aggregateStandards 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-familyR2
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-family11. 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-routesR2
show ip bgp
show ip bgp 203.0.113.0 255.255.255.0Expected 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
endUse 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
endExpected 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
- Confirm the remote peer still sees the
/24aggregate. - Check whether the missing service maps to a specific component prefix.
- On R1, inspect the BGP table for both
/25components. - Inspect the local RIB for both component source routes.
- Confirm
summary-onlyis suppressing remote visibility of specifics. - Determine whether the aggregate remains because another component still exists.
- Test forwarding to addresses in the healthy component and the failed component separately.
- Restore the missing component only if its underlying service/reachability is actually valid.
- Re-verify aggregate and component state.
- 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.128In 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.0On R2:
show ip bgp 203.0.113.0 255.255.255.0If 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.0Do 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
- RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — aggregation, ATOMIC_AGGREGATE, AGGREGATOR and route aggregation behavior.
- 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.
- Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x: BGP 4 / Configuring a Basic BGP Network* —
aggregate-address,summary-onlyand legacyas-setCLI behavior. - Cisco — *Understand Route Aggregation in BGP* — aggregation examples and attribute-loss considerations.
Accessed: 2026-08-11.
