In this article, we are going to discuss route aggregation in BGP and see the different variations of aggregate routes versus specific routes that we can have.
For this article, we will be using the network diagram shown below:
We will be focusing on the 192.168.10-40.0 networks connected behind R1 and R2.
The default configurations on the devices include BGP peering sessions already configured. R1 is advertising the 192.168.10.0/24 and 192.168.20.0/24 networks into BGP, while R2 is advertising the 192.168.30.0/24 and 192.168.40.0/24 networks into BGP. Therefore, if I check the BGP table of R3 for example, I should see those networks there as shown below:
Variation #1: Send only aggregate route
The first variation we will consider is sending only an aggregate route of 192.168.0.0/16 to AS2 instead of the individual specific routes. In BGP, this is done using the aggregate-address summary-only command. Therefore, we will enter the following command on both R1 and R2:
router bgp 1 aggregate-address 192.168.0.0 255.255.0.0 summary-only
Let’s take a look at the BGP table of one of the routers performing aggregation:
Notice the “s” next to the 192.168.10.0 and 192.168.20.0 routes? This means that the routes are being suppressed. We also see our aggregate route there, one originated by R1 and the other by R2.
Now when we take a look at the BGP tables of the routers in AS2, we will not see the more specific routes anymore, only the aggregate route.
As you can see, R3 has picked R1 (192.168.13.1) as the best path to reach the aggregate route while R4 has chosen R2 (192.168.24.2) as its own best path.
Let’s take a quick look into the UPDATE message that contains the aggregate route. There are two attributes that we are concerned with here: ATOMIC_AGGREGATE and AGGREGATOR.
The ATOMIC_AGGREGATE attribute indicates that the route is an aggregate and that some AS numbers may have been excluded to form the aggregate. The AGGREGATOR attribute contains the AS number and BGP ID of the BGP router that originated the aggregate route. We can also see this information by looking at the BGP table on R3:
Variation #2: Send aggregate route along with all the specific routes
In the first variation that we just considered, R4 will send all traffic for the 192.168.0.0/16 aggregate route via R2. However, you may want control over where traffic to your AS comes through. Therefore, another variation is one in which we send an aggregate route along with the more specific routes to our neighboring AS. This will help the neighbor AS to make more optimal decisions on how to forward traffic.
To do this, we will just remove the summary-only option from the aggregate-address command. Therefore, the configuration on R1 and R2 is as follows:
router bgp 1 aggregate-address 192.168.0.0 255.255.0.0
When we check the BGP table of R1 for example, we see that all those locally (AS) originated routes are now back in there along with the aggregate route. Also notice that the “s” is not there anymore, meaning these routes are not suppressed.
Going to R3 which is in AS2, we see the aggregate route along with the more specific routes.
You may have observed that the best path for all these networks on R3 is still through R1; so what is the point of sending the aggregate route? Well, one way to control the entry path of traffic into AS1 is by having the routers in AS1 set the MED on the relevant routes. Another way is to set local preference on the routers in AS2.
These solutions could still have been done without sending the aggregate route. The reason we send the aggregate route is if we want to control how far the specific routes are advertised. For example, AS1 can instruct AS2 to send only the aggregate route to its neighbors and not send the specific routes. This can be done using communities. Therefore, AS1 will set the no-export community on the specific routes while sending the aggregate route without any community.
Hint: The no-export community instructs the receiver not to export the route outside the receiving AS, i.e. do not advertise that route to its neighboring ASs. We will discuss communities more in another article.
A sample configuration on R1 could be as follows:
ip prefix-list LOCAL_ROUTES seq 5 permit 192.168.10.0/24 ip prefix-list LOCAL_ROUTES seq 10 permit 192.168.20.0/24 ! ip prefix-list AGGR_ROUTE seq 5 permit 192.168.0.0/16 ! route-map SET_ATTRIBS permit 10 match ip address prefix-list AGGR_ROUTE ! route-map SET_ATTRIBS permit 20 match ip address prefix-list LOCAL_ROUTES set community no-export set metric 50 ! route-map SET_ATTRIBS permit 30 set metric 100 set community no-export ! router bgp 1 neighbor 192.168.13.3 send-community neighbor 192.168.13.3 route-map SET_ATTRIBS out
In the configuration above, R1 uses a route-map for the following:
It does not set any attribute on the aggregate route.
It sets a community of no-export and a metric of 50 for its local routes (192.168.10.0 and 192.168.20.0).
Finally, it sets a higher metric of 100 for all other routes (i.e. 192.168.30.0 and 192.168.40.0) and also a community of no-export.
This route-map is then applied to neighbor 192.168.13.3 (R3) for outbound updates. Also notice the send-community configuration for neighbor R3 – this is because communities are not propagated to BGP (EBGP or IBGP) peers by default.
What this configuration achieves is that AS2 will prefer the path through R1 to reach networks 192.168.10.0/24 and 192.168.20.0/24 because of their lower MED (metric) values of 50. Also, AS2 will not export the specific routes to its neighboring ASs because of the community no-export.
Hint: The configuration for R2 is similar except that the LOCAL_ROUTES prefix-list will match 192.168.30.0/24 and 192.168.40.0/24.
After this configuration, notice that R3 uses R1 as the best path for 192.168.10.0/24 and 192.168.20.0/24 while it uses R2 as the best path for 192.168.30.0/24 and 192.168.40.0/24.
Also, if we check any of the more specific routes, we see the community of no-export applied to them:
Variation #3: Send aggregate route along with a subset of more specific routes
The configuration we have done in the previous variation works, but what if there was a way to control which specific routes are sent along with the aggregate route? That means we can configure R1 to send the aggregate route along with 192.168.10.0/24 and 192.168.20.0/24 while we configure R2 to send the aggregate route along with 192.168.30.0/24 and 192.168.40.0/24. This way, AS2 will send all traffic for 192.168.10.0/24 and 192.168.20.0/24 via R1, and the traffic for 192.168.30.0/24 and 192.168.40.0/24 via R2.
This can be achieved using a form of route-map called suppress-map. First, I will remove the route-map configuration we did in the previous variation on both R1 and R2. Second, we need to understand the logic behind a suppress-map. We will use ACLs for our explanation:
* If you match routes in an ACL using permit statements and your suppress-map route-map is also a permit statement, those routes will be suppressed and not advertised.
* If you match routes in an ACL using deny statement and your suppress-map route-map is a permit statement, those routes will not be suppressed.
You can extend the logic to prefix lists. Therefore on R1 and R2, we will match our LOCAL_ROUTES prefix list in deny statements of the route maps and then permit every other thing as follows:
ip prefix-list LOCAL_ROUTES seq 5 permit 192.168.10.0/24 ip prefix-list LOCAL_ROUTES seq 10 permit 192.168.20.0/24 ! route-map SUPPRESS deny 10 match ip address prefix-list LOCAL_ROUTES ! route-map SUPPRESS permit 20 ! router bgp 1 aggregate-address 192.168.0.0 255.255.0.0 suppress-map SUPPRESS !
When we check the BGP table of R1, we see that the 192.168.30.0/24 and 192.168.40.0/24 routes are the only ones suppressed while 192.168.10.0/24 and 192.168.20.0/24 are the routes suppressed in R2’s BGP table.
When we check the BGP table of R3, we see that it meets our requirement: 192.168.10.0/24 and 192.168.20.0/24 via R1 and 192.168.30.0/24 and 192.168.40.0/24 via R2.
The effect is also the same on R4. I think this is a much better approach than using MEDs as we did in variation #2.
Let’s stop here for now. We will talk about more variations in the next article.
In this article, we have configured aggregation in BGP. We have looked at three variations: send only an aggregate route, send an aggregate route along with all the specific routes and then send an aggregate route along with a subset of the specific routes. We used a suppress-map to achieve the last variation.
I hope you have enjoyed this article and I look forward to the next article in the series.
References and further reading
Internet Routing Architecture, 2nd edition by Sam Halabi.
Understanding Route Aggregation in BGP: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5441-aggregation.html
RFC 4271: Path Attributes: http://tools.ietf.org/html/rfc4271#page-23