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.
Comments
This happens because the RIB already has a better entry for those routes (via the directly connected interfaces). Cisco's BGP FAQ has some good info on this. You actually don't need to include the 10.0.0.x/30 networks in BGP at all, so the RIB failure in this case shouldn't hurt anything.
The rib failure is for the 10.0.0.0/24 networks. They are not involved in the aggregation in the first place. Also, these networks are directly connected to R3. i.e the local RIB.
Hi Strech,
Nice writeup, I am really impressed with your articles. I am intrigued though, do you use actual devices to recreate all those scenario's. Probably not. I would assume you use either dynamips or GNS3 to emulate it. But you look like a linux user, so dynamips should be the one.
Next, I am most impressed by the capture's that you post. I am again curious to know how to you take those capture do you actually take them from a PC running a sniffer, I would think against. I think you use either the 'capture' command on dynamips or something similar.
I would appreciate if you can discuss the techniques that you use for these writeups, it would be interesting & educating.
@Tarun,
I use GNS3 (on Linux) for most of my labs, and I use "real" hardware where necessary (typically when advanced switching is involved). I generate most of the packet captures using GNS3's capture ability, which dumps traffic between the virtual devices to a PCAP file, which I then tidy up with Wireshark.
I might do a post on how I go about labbing out and writing up the content for an article in the future, so keep an eye out.
If GNS3 is the only simulator you use for most of your labs, I must say you have done a commendable job. The ease with which you demonstrate even complex scenario's is simply awesome.
But you did not mention about what do you use for this beautiful web layout, is it wordpress, or do you have an independent hosting provider using something else? You look like a professional with hosting web content, is it?
Again, I would be very much interested in reading that post, would be waiting for it eagerly.
Hi Stretch,
I have just GNS3'd this setup. I got "RIB-failure" on R3 after the "aggregate-address" command:
R3#show ip bgp BGP table version is 8, local router ID is 10.0.0.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 r> 10.0.0.0/30 10.0.0.1 0 0 10 ? r> 10.0.0.4/30 10.0.0.5 0 0 20 ? *> 172.16.0.0/22 10.0.0.1 0 0 10 ? *> 172.16.0.0/21 0.0.0.0 32768 i *> 172.16.4.0/22 10.0.0.5 0 0 20 ?Any ideas?
Thanks,
Paul