BGP route aggregation - part 2

By stretch | Saturday, September 20, 2008 at 7:56 a.m. UTC

Suppressing Routes

Continuing from our previous lab on BGP route aggregation, let's assume we want to advertise an aggregate route for 172.16.0.0/21 from R3 to R4, but also advertise certain more-specific routes.

BGP_aggregation_lab.png

To refresh, we can create an aggregate route on R3 using the aggregate-address command. The as-set keyword is appended here to ensure the AS numbers of the summarized routes are included in the aggregate's AS path.

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

R4 has installed the aggregate route as expected:

R4# show ip bgp
BGP table version is 12, 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.0.0/21    10.0.0.9                 0             0 30 {10,20} ?
*> 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 we didn't append the summary-only keyword, all of the aggregate's more-specific routes are still advertised independently. Let's assume we want to advertise only the 172.16.0.4.0/24 and 172.16.5.0/24 subnets from AS20 as specific-routes, and rely on the aggregate for routing to the remaining subnets. We can use a suppress map on R3 to suppress the six routes we don't want to advertise independently. First we create a route-map to match the routes to be suppressed, then reference it from the aggregate-address statement.

R3(config)# ip access-list standard Suppressed_Routes
R3(config-std-nacl)# permit 172.16.0.0 0.0.3.255
R3(config-std-nacl)# permit 172.16.6.0 0.0.1.255
R3(config)# route-map MySuppressMap
R3(config-route-map)# match ip address Suppressed_Routes
R3(config-router)# aggregate-address 172.16.0.0 255.255.248.0 as-set suppress-map
 MySuppressMap

On R4, we can verify that R3 is now only advertising the aggregate route and the two /24 routes not matched by our suppress map:

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} ?
*> 172.16.4.0/24    10.0.0.9                               0 30 20 ?
*> 172.16.5.0/24    10.0.0.9                               0 30 20 ?

We've accomplished what we wanted on R4, but R1 and R2 are now facing a serious problem: since their AS numbers are included in the aggregate route (we've appended as-set to the command), neither AS 10 or 20 will accept the aggregate route. R1 knows only of its own routes and the two AS 20 routes we didn't suppress into the aggregate:

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 ?
*> 172.16.4.0/24    10.0.0.2                               0 30 20 ?
*> 172.16.5.0/24    10.0.0.2                               0 30 20 ?

R2 knows only its own routes, since all routes from AS 10 were suppressed.

R2# show ip bgp

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.4.0/24    0.0.0.0                  0         32768 ?
*> 172.16.5.0/24    0.0.0.0                  0         32768 ?
*> 172.16.6.0/24    0.0.0.0                  0         32768 ?
*> 172.16.7.0/24    0.0.0.0                  0         32768 ?

One way to remedy this is to apply an unsuppress map to each of these neighbors on R3. As you might expect, an unsuppress map acts opposite of a suppress map, extracting and advertising more-specific routes from an aggregate. We can create route-maps to match routes from AS 10 and 20, and propagate those routes between the two autonomous systems.

! Match routes based on origin AS
R3(config)# ip as-path access-list 10 permit 10
R3(config)# ip as-path access-list 20 permit 20
R3(config)# route-map AS10_Routes
R3(config-route-map)# match as-path 10
R3(config)# route-map AS20_Routes
R3(config-route-map)# match as-path 20
! Unsuppress AS 20 routes to AS 10 and vice versa
R3(config)# router bgp 30
R3(config-router)# neighbor 10.0.0.1 unsuppress-map AS20_Routes
R3(config-router)# neighbor 10.0.0.5 unsuppress-map AS10_Routes

After completing this configuration, we reset the BGP adjacencies (clear ip bgp * on R3) and inspect the BGP tables of R1 and R2. We can see now they both know of all /24 routes.

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 ?
*> 172.16.4.0/24    10.0.0.2                               0 30 20 ?
*> 172.16.5.0/24    10.0.0.2                               0 30 20 ?
*> 172.16.6.0/24    10.0.0.2                               0 30 20 ?
*> 172.16.7.0/24    10.0.0.2                               0 30 20 ?
R2# show ip bgp

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/24    10.0.0.6                               0 30 10 ?
*> 172.16.1.0/24    10.0.0.6                               0 30 10 ?
*> 172.16.2.0/24    10.0.0.6                               0 30 10 ?
*> 172.16.3.0/24    10.0.0.6                               0 30 10 ?
*> 172.16.4.0/24    0.0.0.0                  0         32768 ?
*> 172.16.5.0/24    0.0.0.0                  0         32768 ?
*> 172.16.6.0/24    0.0.0.0                  0         32768 ?
*> 172.16.7.0/24    0.0.0.0                  0         32768 ?

R4, in contrast, still knows only the aggregate route and the two /24 routes not matched by our suppress map:

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} ?
*> 172.16.4.0/24    10.0.0.9                               0 30 20 ?
*> 172.16.5.0/24    10.0.0.9                               0 30 20 ?

Modifying Attributes of the Aggregate

For a final tweak, let's change the origin of the aggregate route from unknown ("?" in the BGP table listing) to IGP. To do, this we'll need to specify an attribute map and reference it from the aggregate-address command:

R3(config)# route-map SetAttributes
R3(config-route-map)# set origin igp
R3(config)# router bgp 30
R3(config-router)# aggregate-address 172.16.0.0 255.255.248.0 as-set suppress-map
 MySuppressMap attribute-map SetAttributes

After applying the attribute map, we can see that the aggregate route is now advertised with an origin of IGP ("i"):

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} i
*> 172.16.4.0/24    10.0.0.9                               0 30 20 ?
*> 172.16.5.0/24    10.0.0.9                               0 30 20 ?

Quick Review

To review, here's a quick run-down of the aggregate-address tweaks covered by the two parts of this article:

  • summary-only - Prevents more-specific routes from being advertised.
  • as-set - Includes AS numbers from summarized routes in an AS set in the aggregate's AS path.
  • advertise-map <route-map> - Determines which routes will have their attributes (like AS path and communities) included in the aggregate.
  • suppress-map <route-map> - Matches routes which will be suppressed when the aggregate is advertised. Routes not matched are still advertised in parallel to the aggregate.
  • attribute-map <route-map> - Sets attributes of the aggregate route.

We also covered a neighbor parameter:

  • unsuppress-map <route-map> - Matching routes will be unsuppressed from an aggregate and advertised independently to the neighbor.

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


Spikes (guest)
September 20, 2008 at 1:20 p.m. UTC

I have never really felt the need to use aggregation yet in the real world. What's your comment?


sal (guest)
September 22, 2008 at 6:11 p.m. UTC

Spikes, Aggregation is really handy when advertising local routes to your provider. Providers have strict rules about the routes you can send them in order to minimize the size of the routing table, so instead of sending them a bunch of /30s and /29s, etc. you can just send them ONE aggregate route.


PK (guest)
September 26, 2008 at 7:41 p.m. UTC

So when exactly would you want to advertise an aggregate route, but then also advertise some of the smaller routes if they are all coming from one direction?


sidd (guest)
November 13, 2013 at 8:18 a.m. UTC

Great Article- I read your post on TCP sequence and ACK numbers and its very good- thank you

Small correction in the above article- Seems like you fat fingered and added a zero in the second paragraph- 172.16.0.4.0/24---172.16.4.0/24

"Since we didn't append the summary-only keyword, all of the aggregate's more-specific routes are still advertised independently. Let's assume we want to advertise only the 172.16.0.4.0/24 and 172.16.5.0/24 subnets from AS20 as specific-routes"


Bill (guest)
October 15, 2015 at 7:52 p.m. UTC

@ PK

A great example would be when you have a single data center connecting to an MPLS network using dual routers and dual circuits. In my case, I have one router being used as a SIP gateway over a 100Mbps connection from my VoIP provider. The other is a 2.5 Gbps connection from the same carrier for all of my facilities to connect to my data center. I need to advertise only voice subnets across the 100Mbps with the 2.5Gbps as a backup and then all subnets out of the 2.5Gbps connection but to suppress the voice subnets so they only use the 100Mbps link. This is the PERFECT solution for such a need as it will allow failover without AS-Prepend.

Excellent article, Jeremy.


BitRaptor (guest)
May 18, 2016 at 4:09 p.m. UTC

Awesome article. Very well-written. Thanks!


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

Very useful and clear article! Thank you Jeremy!

Comments have closed for this article due to its age.