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.
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.
Comments
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?
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.
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?
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"
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.
May 18, 2016 at 4:09 p.m. UTC
Awesome article. Very well-written. Thanks!
May 20, 2016 at 11:19 a.m. UTC
Very useful and clear article! Thank you Jeremy!