BGP - aggregate-address with a single subnet

When implementing the aggregate-address feature of BGP, if you issue the aggregate-address command on a Cisco router for an address range that contains only a single subnet, then the results might be different than what you expect. They are however consistently.

Topology

The examples below will use the following topology:

bgp-aggregate-topology-lab.png

Notice that R2 has the 172.16.2.0/25 prefix, and R3 has the 172.16.3.3/32 prefix, and these are advertised to R1 using eBGP with all settings at their defaults.

aggregate address contains no subnets

If you create an aggregate address at R1 using the following command:

R1(config-router)#aggregate-address 172.16.2.0 255.255.255.192

It encompasses none of the advertised routes from either R2, or R3. Indeed, it is a smaller subnet than the one advertised by R2. The result is that R1 does not place this at all in its BGP table, thus it is not advertised to R4 at all.

aggregate address contains a single subnet

If you create an aggregate address at R1 using the following command:

R1(config-router)#aggregate-address 172.16.2.0 255.255.255.128

This aggregate address is the same as the prefix advertised by R2, which is 172.16.2.0/25. When this is issued, we see the same behavior as the previous case. This aggregate address is not installed in the BGP table of R1 and is thus not advertised to R4.

aggregate address contains a single host

If you create an aggregate address at R1 using the following command:

R1(config-router)#aggregate-address 172.16.3.3 255.255.255.255

This aggregate address is the same as the prefix advertised by R3, which is a single host: 172.16.3.3/32. When this is issued, we see the same behavior as the previous cases. This aggregate address is not installed in the BGP table of R1 and is thus not advertised to R4.

aggregate address is larger than but contains a single subnet

If you create an aggregate address at R1 using the following command:

R1(config-router)#aggregate-address 172.16.2.0 255.255.255.0

This aggregate address is larger than the prefix advertised by R2, which is: 172.16.2.0/25. When this is issued, we see that the aggregate address is installed in the BGP table of R1 and is thus advertised to R4, even though it contains only a single subnet. The BGP table in R4 looks like this:

     Network          Next Hop            Metric LocPrf Weight Path
 *>   172.16.2.0/25    192.168.14.1                           0 1 2 i
 *>   172.16.2.0/24    192.168.14.1             0             0 1 i
 *>   172.16.3.3/32    192.168.14.1                           0 1 3 i

You can see both the aggregate prefix (with the AS Path information removed, as well as the prefix of the loopback interface of R2.

Conclusion

We can draw some conclusions from the above-observed behavior. First of all, if the aggregate-address is equal to or smaller than a subnet that is already in the BGP table and is advertised, the aggregate-address command is ignored.

If the aggregate-address is larger than one of the advertised prefixes, and only one prefix is contained within that aggregate address, then it is installed normally, and it behaves as expected.

Creating an aggregate address command from a single host address or identical to an already existing prefix is generally not meaningful and would not have the intended effect of route aggregation. The purpose of the aggregate-address command is to summarize multiple specific routes into a single, larger network address in BGP advertisements. It's used to reduce the number of routes advertised, simplifying the BGP routing table and improving efficiency.

https://networklessons.com/cisco/ccie-routing-switching-written/bgp-aggregate-as-set/

Links to this page: