BGP Aggregate-Address

The BGP aggregate-address can be used to summarise a set of networks into a single prefix. In the
diagram below, Im going to use R2 to summarise prefixes inside AS20 & AS30, then send the summary
to R3.

Lets hop onto R2 and set this up.

R2(config)#router bgp 10
R2(config-router)#aggregate-address 206.25.128.0 255.255.128.0 summary-only
We configure the summary using the aggregate-address command. The significance of the summaryonly statement is there to ensure that longer-prefixes inside of the aggregate address are suppressed
before sending BGP updates out to R3. Without it, longer prefixes are advertised as well as the
aggregate-address.
The only rule for advertising an aggregate-address is that we must have at least one of the longer
prefixes inside of our BGP table. Obviously, we meet this because R1 & R4 are advertising the specific
prefixes to R2. Anyhow, lets have a look at R2s BGP table now we have configured the aggregateaddress.
R2#sh ip bgp
BGP table version is 8, local router ID is 195.26.10.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric LocPrf Weight Path
*> 195.26.10.0/30 0.0.0.0
0
32768 i
*> 195.26.10.4/30 0.0.0.0
0
32768 i
*> 195.26.10.8/30 0.0.0.0
0
32768 i
*> 206.25.128.0/17 0.0.0.0
32768 i
s> 206.25.160.0/19 195.26.10.5
0
0 20 i
s> 206.25.224.0/19 195.26.10.1
0
0 30 i
The output also shows an s> by two of the networks; and from using the status codes at the top we can
see this means these routes have been suppressed. This is because the summary-only keyword on
the aggregate-address command forces longer prefixes to be suppressed. We can verify this by
checking R3s BGP table.
R3#sh ip bgp
BGP table version is 7, local router ID is 195.26.10.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric LocPrf Weight Path
*> 195.26.10.0/30 195.26.10.10
0
0 10 i
*> 195.26.10.4/30 195.26.10.10
0
0 10 i
*> 195.26.10.8/30 0.0.0.0
0
32768 i
*

195.26.10.10

*> 206.25.128.0/17 195.26.10.10

0 10 i
0

0 10 i

R3#sh ip bgp 206.25.128.0

BGP routing table entry for 206.25.128.0/17, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
10, (aggregated by 10 2.2.2.2)
195.26.10.10 from 195.26.10.10 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best

This output also highlights some other important points when looking at aggregation. We can now see
that we have lost some path information about our two networks from AS20 and AS30. The aggregate
shows these routes are now in AS10 (Although this sentence isnt technically correct, this is what it
looks like when first glancing at the information in the BGP table above; a technical explanation is given
later).
Because the atomic-aggregate attribute is there; it signifies that the NLRI should not be de-aggregated,
as the advertising router (2.2.2.2) has chosen to advertise a less-specific prefix for a range of networks.
It also means that some of the paths to the destination may not follow the AS_PATH that has been
advertised.
As you know, the AS_PATH is used in BGP as a loop prevention mechanism. So because this
information is now lost, we could inherit a loop. Cisco has provided a solution to this situation by
breaking down the AS_PATH attribute into two tuples (sub-components of the AS_PATH). These are
the AS_SEQUENCE and AS_SET:
AS_SEQUENCE. This is the ordered list of ASs that were used in the path to reach the destination.
AS_SET. This is an unordered list of ASs that were used in the path to reach the destination.
When a BGP speaker aggregates multiple AS_PATHs, he will select the longest, most common shared
chain of AS_SEQUENCE tuples and put this into the AS_PATH attribute for the aggregated prefix (in
our topology this is just AS10). Any ASs that are uncommon to each prefix are put into the AS_SET
attribute. The end result is that any BGP speaker will be able to detect a loop because each AS that
has been traversed, will either be in the AS_PATH or AS_SET; and if the speaker sees his AS in any
of these attributes, he can be confident a loop has occurred. Lets enable this feature now.
R2(config-router)#aggregate-address 206.25.128.0 255.255.128.0 summary-only as-set
R3#sh ip bgp
BGP table version is 8, local router ID is 195.26.10.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? incomplete

Network Next Hop Metric LocPrf Weight Path

*> 195.26.10.0/30 195.26.10.10 0 0 10 i
*> 195.26.10.4/30 195.26.10.10 0 0 10 i
*> 195.26.10.8/30 0.0.0.0 0 32768 i
* 195.26.10.10 0 0 10 i
*> 206.25.128.0/17 195.26.10.10 0 0 10 {20,30} i

R3#sh ip bgp 206.25.128.0

BGP routing table entry for 206.25.128.0/17, version 8
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Not advertised to any peer
10 {20,30}, (aggregated by 10 2.2.2.2)
195.26.10.10 from 195.26.10.10 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, external, best
On R2 the most common AS_SEQUENCE towards networks to 206.25.160.0/19 and 206.25.224.0/19
was just AS 10. So this was inserted into the AS_PATH attribute. The uncommon ASs to both of these
networks is AS20 & 30. These ASs were inserted into the AS_SET (as shown by the numbers in
the squiggly brackets). So there we go. We have loop detection with an aggregated prefix.
March 24th, 2012 in BGP | tags: aggregate, aggregate-address, as path, as
set, AS_PATH, AS_SEQUENCE, AS_SET, atomic-aggregate, bgp, bgp aggregateaddress, blog, ccie, ccie blog, ccip, ccip blog, cisco, routing and switching, summary-only