BGP Aggregate-Address

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

Let’s 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 summary-only 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, let’s have a look at R2’s BGP table now we have configured the aggregate-address.
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 R3’s 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             0             0 10 i
*> 206.25.128.0/17 195.26.10.10             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 isn’t 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 AS’s that were used in the path to reach the destination.
  • AS_SET.  This is an unordered list of AS’s that were used in the path to reach the destination.
When a BGP speaker aggregates multiple AS_PATH’s, 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 AS’s 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 see’s his AS in any of these attributes, he can be confident a loop has occurred.  Let’s 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 AS’s to both of these networks is AS20 & 30.  These AS’s 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.