BGP route aggregation - part 1

By stretch | Friday, September 19, 2008 at 6:14 a.m. UTC

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:

BGP_aggregation_lab.png

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.

wireshark_path_attributes.png

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.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Design, Routing

Comments


Paul (guest)
September 19, 2008 at 11:06 a.m. UTC

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


stretch
September 19, 2008 at 11:31 a.m. UTC

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.


Spikes (guest)
September 19, 2008 at 11:39 a.m. UTC

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.


Tarun (guest)
September 22, 2008 at 8:27 a.m. UTC

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.


stretch
September 22, 2008 at 9:01 a.m. UTC

@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.


Tarun (guest)
September 24, 2008 at 8:57 a.m. UTC

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.


sunil sharma (guest)
January 31, 2011 at 4:38 a.m. UTC

this very good artical but igp give only summrized route while bgp do not remove unsummurized route.why?


Suresh_Krish
November 26, 2012 at 2:03 p.m. UTC

Hi Stretch,
I liked it. Simple easy elegant examples to understand BGP Aggregation, AS_SET and Loop Avoidance.
Regards
Suresh Krish


Joshua (guest)
May 17, 2013 at 3:52 p.m. UTC

I'm currently doing an exam on BGP in university, I must say your writes up are generally amazing and explaining how everything works. its a shame I pay for an education which can't simple explain what you have written in such few words.

Thank you

Kind Regards


koolj
August 20, 2013 at 5:18 a.m. UTC

Hi Jeremy!

I noticed a difference in the way R4 sees the AS path attribute before and after the advertise map is applied -

Before -

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} ?

After advertise-map is applied -

R4# show ip bgp

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


Since the goal of our advertise map was only to allow AS 10 to be permitted to be advertised by R3, shouldn't R4 still see the AS 10 as a part of the AS_SET attribute? The above AFTER output indicates that R4 might start seeing this as another AS SEQ attribute.

In this particular scenario it doesnt really matter since 10 is a single ASN

But, lets assume that the AS-SET attributre consisted of a large set of ASNs, for example - {10,20,200,300,400,500}

Now, if I used an advertise map to only allow R3 to advertise 200, 300, 400 and 500, since these are a part of the AS-SET I would ideally want R4 to see them as {200, 300, 400, 500} and not as 200 300 400 500 since when enclosed in { } the BGP best path calculation will consider the entire AS-SET as ONE ASN while it will consider the "200 300 400 500" as 4 individual ASN hops....

Am I over-thinking this? :)

Going to lab it up soon though...


Rado (guest)
September 8, 2013 at 6:12 p.m. UTC

Thank you once again. One of the best networking sites on the web!


Noob (guest)
May 21, 2014 at 12:23 p.m. UTC

Well done, nice explaination.


korman (guest)
January 29, 2015 at 12:21 a.m. UTC

Great post.... We have are doing similar at work and have dual CE routers with same AS doing BGP / IBGP ( each other) at the branch and a L3 switch doing OSPF with both routers

We are having a debate about advertising the /16 in the CE routers to the carriers or having a network statement for each of the individual /24 subnets. A colleague wants to not advertise the /16 for control reasons? I think we can do both and use the /16 as a catch all and add a more specific /24 advertisement when the control is needed.

Example We have a 10.20x.0.0/16 reserved for each site Site 1 - 10.201.0.0/16 10.201.1.0/24 - Users 10.201.2.0/24 - Servers 10.201.3.0/24 - Iphones Site 2 - 10.202.0.0/16 10.202.1.0/24 - Users 10.202.2.0/24 - Servers 10.202.3.0/24 - Iphones Site 3 - 10.203.0.0/16 10.203.1.0/24 - Users 10.203.2.0/24 - Servers 10.203.3.0/24 - Iphones Thoughts?


Z0om (guest)
May 20, 2016 at 11:24 a.m. UTC

This explanation much more better than a Cisco article about it! Thanks!


Danny (guest)
May 30, 2016 at 3:18 p.m. UTC

Hello. Indeed this article is very well written and quite useful.

I have a similar scenario for BGP route aggregation but the peer that aggregates is in the same ASN as the BGP prefixes part of the summarized network, as if R1 and R3 were both in AS 10. I want the summary (aggregate) to be sent out to R4 (EBGP) but not to R1 (IBGP). Not sure if I should use attribute-map and 'set as-path prepend 10' so that it is not sent to R1 (already in AS 10), or if I should use as-set advertise-map and match a prefix from R1 that will populate the aggregated prefix' attributes (that prefix is from R1, an IBGP neighbor, and its as-path is currently empty as it was originated on R1).

Any idea?

thank you

Comments have closed for this article due to its age.