In the previous article on BGP route aggregation, we looked at three different variations of aggregating routes including sending an aggregate route only, sending an aggregate route with more specific routes and sending an aggregate route with a subset of the specific routes.

In this article, we will look at three more variations using the network diagram below:

R5 is not running BGP; it is only running OSPF with R2. R2 in turn is advertising the 192.168.20.0/24 network into BGP.

Variation #4: Send an aggregate route with the AS_SET

One of the issues that may occur when sending aggregates is loss of information. In our network diagram, R1 is receiving the 192.168.20.0/24 route from AS2 and the 192.168.30.0/24 route from AS3.

R1 is also sending these routes to its neighbor in AS4 – R4.

Notice that the AS_PATH shows that the routes were originated from AS2 and AS3 respectively. Now, we will configure R1 to send only an aggregate route of 192.168.0.0/16 to its neighbors using the following configuration: aggregate-address 192.168.0.0 255.255.0.0 summary-only. When we check the BGP table of R4 after this configuration on R1, we see only the aggregate route:

Note the Path column in the output above: the aggregate route shows only “1” in the AS_PATH, meaning that the aggregate route has lost the information of AS2 and AS3.

Let me show you one of the issues that can result to loss of information like this. In the BGP table of R2, we also see the aggregate route sent by R1. R2 accepted this route because it didn’t see its AS number in the AS_PATH.

Now, I will shut down the link between R2 and R5. This means that R2 will stop receiving the 192.168.20.0/24 route and thus stop advertising that route into BGP.

The only problem is, since the aggregate route from R1 is still in R2’s BGP table, if it wants to reach the 192.168.20.0/24 network, it will use that aggregate route and send the traffic towards R1. R1, not having that route in its routing table anymore, will drop the traffic.

Note: Perhaps this example is not the best because the aggregate route is still useful to R2 for accessing the 192.168.10.0/24 network but it illustrates the problem of loss of information. Moreover, we could use a suppress-map to allow the more specific 192.168.10.0/24 route to be advertised to R2.

To work around the loss of information problem, we could instruct R1 to send the AS_SET along with the aggregate route. The AS_SET is an unordered list of ASNs through which the route has traversed and it is used to avoid routing loops. In the case of aggregation, it lists the AS numbers of the routes that make up the aggregated route. To add the AS_SET, simply include the “as-set” option in the aggregate-address command, for example:

router bgp 1
aggregate-address 192.168.0.0 255.255.0.0 summary-only as-set

Note: I have not been able to replicate a routing loop that may occur when the AS_SET is not used. However, as you saw above, I was able to create a black hole.

When we check R4’s BGP table now, we see that the AS numbers (ASNs) are now included in {}.

Note: If there is only one ASN (i.e. all specific routes that form the aggregate route come from the same AS), there will be no braces – it will look like a normal AS_PATH, e.g. “1 2”. In fact, the AS_SEQUENCE segment is used instead of the AS_SET.

Another thing we see is that R2 (or R3) does not have the aggregate route in its BGP table. This is because it sees its ASN in the AS_PATH attribute (contained in the AS_SET segment) and drops that UPDATE.

Caution: When using the as-set option, if one of the specific routes that makes up an aggregate route changes, the aggregate route will also be updated. This can cause issues when routes are flapping, for example.

Variation #5: Tweaking the attributes of an aggregate route

By including the “as-set” option, an aggregate route inherits the attributes of the more specific routes such as the community attribute. One requirement may be to change the attribute of the aggregate route irrespective of the inherited attributes.

Note: I don’t have a list of the attributes that an aggregate route inherits from the more specific routes but I know it inherits the community attributes. I also know it does not inherit metric or origin.

A common example used to describe this scenario is when a more specific route has the no-export community. When an aggregate route is formed from more specific routes including this route, it will inherit the no-export community and thus, not be advertised to neighboring ASs.

To see this in action, I will configure R2 to set the no-export community for the 192.168.20.0/24 route sent to R1.

ip prefix-list MATCH_LOCAL seq 5 permit 192.168.20.0/24
!
route-map SET_COMMUNITY permit 10
match ip address MATCH_LOCAL
set community no-export
!
route-map SET_COMMUNITY permit 20
!
router bgp 2
neighbor 192.168.12.1 send-community
neighbor 192.168.12.1 route-map SET_COMMUNITY out

When we check the BGP table of R1 for the 192.168.20.0/24 route, we see that it now has the no-export community set.

However, we will also see that the aggregate route has inherited the no-export community, meaning this aggregate route will not be sent to R4.

The output below shows that R4’s BGP table is empty because the aggregate route is not advertised to it.

To change the attribute of the aggregate route, we can use an attribute map, which is a type of route-map. I will create a route-map that sets the community to “none” and then apply that route-map as an attribute-map under the aggregate-address command. The configuration on R1 is as follows:

route-map CHANGE_COMMUNITY permit 10
set community none
!
router bgp 1
aggregate-address 192.168.0.0 255.255.0.0 summary-only as-set attribute-map CHANGE_COMMUNITY

When we check the aggregate route on R1, we see that it does not have the no-export community anymore even though the 192.168.20.0/24 still does.

We can confirm that this works by checking the BGP table of R4 for the aggregate route:

Variation #6: Form an aggregate route from a subset of specific routes

This is different from variation #3 where we sent an aggregate route along with a subset of more specific routes. In this instance, we are forming the aggregate route from a subset of more specific routes, e.g. only the 192.168.30.0/24 route.

This is done using yet another form of route-map called advertise map. In the configuration below, I will use only the 192.168.30.0/24 route to form the aggregate route:

ip prefix-list FORM_AGGR permit 192.168.30.0/24
!
route-map FORM_AGGR_MAP permit 10
match ip address prefix-list FORM_AGGR
!
router bgp 1
aggregate-address 192.168.0.0 255.255.0.0 summary-only as-set advertise-map FORM_AGGR_MAP

If we check the BGP table of R4, we will see that the aggregate route does not have “2” in the AS_PATH, letting us know that the 192.168.20.0/24 route is not part of the aggregate route.

Summary

There are various forms of aggregating routes in BGP and we will now summarize them including the commands with which they are achieved:

  • Send only the aggregate route: aggregate-address <prefix> <mask> summary-only
  • Send the aggregate route with ALL the more specific routes: aggregate-address <prefix> <mask>
  • Send the aggregate route with a subset of the more specific routes. We use a suppress map to achieve this: aggregate-address <prefix> <mask> suppress-map <route_map_name>
  • Prevent loss of information using AS_SET: aggregate-address <prefix> <mask> as-set
  • Change attribute of the aggregate route. We use an attribute map to achieve this: aggregate-address <prefix> <mask> attribute-map <route_map_name>
  • Form aggregate from a subset of the more specific routes. We use an advertise map to achieve this: aggregate-address <prefix> <mask> advertise-map <route_map_name>

I hope you have found this article informative and I look forward to the next article in the series.

References and further reading

  1. Internet Routing Architecture, 2nd edition by Sam Halabi