BGP Route Aggregation: summary-only and suppress-map

Aggregating routes is one of the few ways to shrink the internet routing table, and it is also one of the easiest ways to break your own forwarding. An aggregate is only advertised under specific conditions, it silently suppresses the more-specifics it summarises unless you tell it otherwise, and if it is built from prefixes with different AS paths it can hand a downstream router a path that loops. This article covers the mechanics of aggregate-address and the four knobs that decide its behaviour.

The aggregate only exists while a component is in the table

IOS will not advertise 10.0.0.0/8 just because you asked it to. An aggregate is generated only if at least one more-specific route that it covers is present in the BGP table. Withdraw the last component and the aggregate disappears too — which is the correct behaviour, and the reason a summarising router does not blackhole traffic for prefixes it cannot reach.

router bgp 65001
 aggregate-address 10.0.0.0 255.0.0.0 summary-only
 aggregate-address 172.16.0.0 255.240.0.0 as-set summary-only
 aggregate-address 192.168.0.0 255.255.0.0 suppress-map KEEP-SOME

summary-only and what it does to the more-specifics

show ip bgp 10.0.0.0
! BGP routing table entry for 10.0.0.0/8
!  Paths: (1 available, best #1, table default, not advertised to any peer)
!    Local, (aggregated by 65001 10.0.0.1)
!      from 0.0.0.0 (10.0.0.1)

Without summary-only, the aggregate and every contributing more-specific are all advertised — which defeats the purpose but preserves the most specific path. With it, the components are suppressed and only the aggregate leaves.

The trap is inside your own AS: suppression applies to outbound advertisements, so internal routers still see the more-specifics they already had. But a downstream eBGP neighbour loses the ability to route around a failure inside the summarised block, because it no longer has the detail.

as-set and the loop-prevention rule

An aggregate inherits no AS_PATH information by default: the aggregated route is advertised as if your AS originated it. If the components came from several different transit providers, as-set makes the aggregate carry an unordered set of the contributing AS numbers instead.

show ip bgp 172.16.0.0
! AS path: {65010,65020,65030} i        <- AS_SET from as-set
! AS path: 65001 i                      <- without as-set

When a receiver runs loop detection, an AS_SET counts as one hop but each AS in the set is checked. Without as-set, a neighbour that appears in the components' paths will happily accept the aggregate, send traffic back, and create a loop. Any aggregate that spans multiple upstream AS numbers should carry as-set.

suppress-map: exception-based aggregation

Sometimes you want to aggregate most components but keep a handful visible. suppress-map takes a route-map; prefixes matched by the map are the ones suppressed.

ip prefix-list MORE-SPECIFIC permit 192.168.1.0/24
ip prefix-list MORE-SPECIFIC permit 192.168.2.0/24
!
route-map KEEP-SOME permit 10
 match ip address prefix-list MORE-SPECIFIC
!
router bgp 65001
 aggregate-address 192.168.0.0 255.255.0.0 suppress-map KEEP-SOME

Note the inverted intuition: the prefixes matched by the map are the ones removed from the advertisement. Everything else covered by the aggregate is still advertised alongside it, so this is a surgical tool rather than a blanket suppression.

Cisco IOS also supports advertise-map (which components must exist for the aggregate to be generated) and attribute-map (to set attributes on the aggregate itself, for example a community that marks it as a summary).

Verification checklist

show ip bgp 10.0.0.0                  ! aggregate present, atomic-aggregate attribute
show ip bgp neighbors 10.0.0.5 advertised-routes
show ip bgp regexp ^$ | include 10\.   ! spot check for leaked components
show ip bgp summary                    ! table size before and after

Always verify from the neighbour's perspective with advertised-routes: suppression, as-set and the atomic-aggregate attribute are all outbound behaviours, and the local table will look identical whether or not any of them are working.

Common mistakes

• Aggregating across AS_PATHs without as-set, then wondering why a customer's traffic never returns.
• Using summary-only on an aggregate that is used internally for traffic engineering — internal routers keep the more-specifics, external ones lose them.
• Expecting the aggregate to be advertised when no component is present.
• Forgetting that a suppressed component is suppressed for all neighbours, because suppression is a property of the aggregate, not of a neighbour.

For the path-selection consequences of the attributes you copy onto an aggregate, see the 13-step BGP best-path algorithm; for the community-based tagging that pairs well with aggregation, see BGP communities explained.

原文链接：https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-16/irg-xe-16-book/bgp-route-aggregation.html