BGP route aggregation - part 1

Route aggregation (or summarization) with BGP is extremely flexible. Unfortunately, this flexibility leads to difficulty remembering all the different tweaks which can be used to manipulate aggregate routes. In this article we'll look at all of the aggregation configuration parameters and how each can be used to influence the advertisement of an aggregate route.

First let's have a look at our sample lab:

Routers one and two each advertise four /24 routes to their respective networks. These routes are advertised to R3, which in turn advertises them to R4. Inspecting the BGP table on R4, we can see four routes each from AS 10 and 20.

R4# show ip bgp
BGP table version is 9, local router ID is 10.0.0.10
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
*> 172.16.0.0/24    10.0.0.9                               0 30 10 ?
*> 172.16.1.0/24    10.0.0.9                               0 30 10 ?
*> 172.16.2.0/24    10.0.0.9                               0 30 10 ?
*> 172.16.3.0/24    10.0.0.9                               0 30 10 ?
*> 172.16.4.0/24    10.0.0.9                               0 30 20 ?
*> 172.16.5.0/24    10.0.0.9                               0 30 20 ?
*> 172.16.6.0/24    10.0.0.9                               0 30 20 ?
*> 172.16.7.0/24    10.0.0.9                               0 30 20 ?

Since R4 has only a single path to all of these subnets, maintaining eight independent routes is unnecessary. We can implement aggregation at R3 to optimize the BGP table on R4.

Creating an Aggregate Route

The aggregate-address command can be used to generate a summary route on R3. We'll create a 172.16.0.0/21 summary to include all more-specific routes while not leaving any overlap.

R3(config-router)# aggregate-address 172.16.0.0 255.255.248.0

Let's verify that R4 sees the new aggregate route:

R4# show ip bgp

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/24    10.0.0.9                               0 30 10 ?
*> 172.16.0.0/21    10.0.0.9                 0             0 30 i
*> 172.16.1.0/24    10.0.0.9                               0 30 10 ?
*> 172.16.2.0/24    10.0.0.9                               0 30 10 ?
*> 172.16.3.0/24    10.0.0.9                               0 30 10 ?
*> 172.16.4.0/24    10.0.0.9                               0 30 20 ?
*> 172.16.5.0/24    10.0.0.9                               0 30 20 ?
*> 172.16.6.0/24    10.0.0.9                               0 30 20 ?
*> 172.16.7.0/24    10.0.0.9                               0 30 20 ?

BGP route aggregation differs from IGP summarization in that the default behavior is to continue advertising all the more-specific routes of summarized by an aggregate. As we can see here, the aggregate was injected without affecting any of the more-specific routes. We can suppress all the summarized routes by recreating the aggregate route, this time appending the summary-only keyword.

R3(config-router)# aggregate-address 172.16.0.0 255.255.248.0 summary-only

Checking on R4 again, we can see all the more-specific routes have been withdrawn, leaving only the aggregate:

R4# show ip bgp

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/21    10.0.0.9                 0             0 30 i

Preserving AS Numbers

What's dangerous about the aggregate route advertised by R3? Notice that the route, having originated in AS 30, includes only AS 30 in it's AS path. Also remember that R4 is not the only router receiving the aggregate route; R1 and R2 receive it as well. These routers, not seeing their own AS in the route's AS path, happily install the route in their own BGP tables.

R1# show ip bgp

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/24    0.0.0.0                  0         32768 ?
*> 172.16.0.0/21    10.0.0.2                 0             0 30 i
*> 172.16.1.0/24    0.0.0.0                  0         32768 ?
*> 172.16.2.0/24    0.0.0.0                  0         32768 ?
*> 172.16.3.0/24    0.0.0.0                  0         32768 ?

Consider what would happen if one of the /24 routes in AS 10 disappeared. R1, having installed the aggregate advertised from AS 30, would see AS 30 as a less-specific but valid path to the subnet, and route traffic to R3. R3, no longer having the more-specific route back to R1, drops the traffic, creating a black hole.

We can protect against this condition by including an AS set in the AS path of the aggregate route from R3. An AS set is an unordered list of autonomous system numbers, collected from all the routes summarized by the aggregate. By including these origin AS numbers in the aggregate's AS path, we can insure the integrity of BGP's loop prevention mechanism; by default, an AS won't accept a route with an AS path listing its own AS number.

To include an AS set in our aggregate route, append the as-set keyword to the aggregate-address command:

R3(config-router)# aggregate-address 172.16.0.0 255.255.248.0 summary-only as-set

This configuration generates an aggregate route with an AS path containing the AS set of 10 and 20, since the aggregate contains routes originating from those autonomous systems. On R4 we can see how the AS path appears in the BGP table:

R4# show ip bgp

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/21    10.0.0.9                 0             0 30 {10,20} ?

With the AS set included, R1 now detects its own AS in the AS path of the aggregate route, and no longer accepts the route into its BGP table.

R1# show ip bgp

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/24    0.0.0.0                  0         32768 ?
*> 172.16.1.0/24    0.0.0.0                  0         32768 ?
*> 172.16.2.0/24    0.0.0.0                  0         32768 ?
*> 172.16.3.0/24    0.0.0.0                  0         32768 ?

Analyzing the BGP traffic on the wire, we can see R3's aggregate route update packet (packet 15 in the provided capture) has an AS path composed of both an AS sequence (30) and an AS set ({10, 20}). Also of interest here is the Aggregator attribute, which identifies R3 in AS 30 as the creator of the aggregate route.

There may be instances where you want to include only certain AS numbers in the aggregate's AS set; an advertise map can be used to achieve this. (This is sort of an odd name for such a tool; try to think of it as specifying the routes whose attributes should be "advertised" via the aggregate.) The advertise-map parameter is appended to the aggregate-address command to specify a route-map used to match subnets. Only attributes (like AS paths and communities) from the matched routes will be included in the aggregate.

For example, let's say we only wanted to include AS 10 in the aggregate route's AS path and omit AS 20. To do this, we create a route-map to match only AS 10 subnets, and reference it from the aggregate-address statement.

R3(config)# ip access-list standard AS10_subnets
R3(config-std-nacl)# permit 172.16.0.0 0.0.3.255

R3(config)# route-map AS10
R3(config-route-map)# match ip add AS10_subnets

R3(config-router)# aggregate-address 172.16.0.0 255.255.248.0 summary-only as-set
 advertise-map AS10

As our advertise map only matches routes from AS 10, only AS 10 is included in the aggregate's AS path, as we can see on R4:

R4# show ip bgp

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/21    10.0.0.9                 0             0 30 10 ?

In part two, we'll look at "leaking" more-specific subnets from the aggregate route while hiding others using suppress maps, and modifying the aggregate's attributes with an attribute map.