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.
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.
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:
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 iThe 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, bestThis 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.
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, bestOn 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.