BGP Aggregate Addresses

 

Routes that are advertised through BGP are usually aggregated to minimize the number of routes that are used and reduce the size of global routing tables. However, common route aggregation can obscure more specific routing information that is more accurate but not necessary to forward packets to their destinations.

​

With BGP you have two different ways to create aggregate Routes:

 

• Aggregate addresses with static routes

• The command aggregate-address

 

The whole document will be using the following configuration:

 

The examples will mainly use the loopback addresses from R1

 

 

This example shows how an aggregate address can be created with the use of a static route:

 

 

London-R1

router bgp 1

 no synchronization

 bgp log-neighbor-changes

 network 172.30.0.0 mask 255.255.254.0

 neighbor 116.1.12.2 remote-as 2

 no auto-summary

 !

 ip route 172.30.0.0 255.255.254.0 Null0

 

 

A static summary route is configured on R1 which includes both loopback interfaces an is then included into BGP with the network command. Since the static summary route itself is no real destination, the next hop for the static route has to be set to the interface null0. If either R2 or R3 got packets which match the aggregate route from R1 it will be sent to R1. R1 itself matches the packet with its more-specific route entries in the routing table and forwards it accordingly or drops it if it doesnt find a match with a more-specific route.

The following output shows R3’s BGP Table:

 

 

Milan-R3#sh ip bgp

 

BGP table version is 6, local router ID is 10.0.1.3

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

*>10.0.0.0/24       0.0.0.0                  0         32768 i

*> 10.0.1.0/24       0.0.0.0                  0         32768 i

*> 172.30.0.0/23   144.1.23.2                             0 2 1 i

*> 192.168.0.0       144.1.23.2               0             0 2 i*

> 192.168.1.0           144.1.23.2              0             0 2 i

 

 

Route Aggregation: aggregate-address command

​

R1 will now advertise its summary address to R2 with the aggregate-address command. At least one route from the summary address’ IP block has to be in the BGP table to get BGP to advertise the aggregate-addresses. You can either do this via redistribution from an IGP or with the network statement.

 

 

London-R1

router bgp 1

 no synchronization

 bgp log-neighbor-changes

 network 172.30.0.0 mask 255.255.255.0

 network 172.30.1.0 mask 255.255.255.0

 aggregate-address 172.30.0.0 255.255.254.0

 neighbor 116.1.12.2 remote-as 2

no auto-summary

 

 

London-R1 is now advertising the aggregate-address itself and all more-specific routes which can be found in its BGP table:

 

 

Newyork-R2#sh ip bgp

BGP table version is 10, local router ID is 192.168.1.2

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

*> 10.0.0.0/24        144.1.23.3               0             0 3 i

*> 10.0.1.0/24        144.1.23.3               0             0 3 i

*> 172.30.0.0/24    116.1.12.1               0             0 1 i

*> 172.30.0.0/23    116.1.12.1               0             0 1 i

*> 172.30.1.0/24    116.1.12.1               0             0 1 i

*> 192.168.0.0        0.0.0.0                  0         32768 i

*> 192.168.1.0        0.0.0.0                  0         32768 i

 

 

The aggregate-address can be filtered out if not every peer should receive the aggregate-address. R2 is now filtering out the aggregate-address towards R3 with a ip prefix-list and a route-map.

 

 

router bgp 2

 no synchronization

 bgp log-neighbor-changes

 network 192.168.0.0

 network 192.168.1.0

 neighbor 116.1.12.1 remote-as 1

 neighbor 144.1.23.3 remote-as 3

 neighbor 144.1.23.3 route-map To-R3 out

 no auto-summary

!

ip prefix-list AGGREGATE seq 5 permit 172.30.0.0/23

!

route-map To-R3 deny 10

 match ip address prefix-list AGGREGATE

!

route-map To-R3 permit 20

 

Milan-R3#sh ip bgpBGP table version is 47, local router ID is 10.0.1.3

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

*> 10.0.0.0/24      0.0.0.0                  0         32768 i

*> 10.0.1.0/24      0.0.0.0                  0         32768 i

*> 172.30.0.0/24    144.1.23.2                             0 2 1 i

*> 172.30.1.0/24    144.1.23.2                             0 2 1 i

*> 192.168.0.0      144.1.23.2               0             0 2 i

*> 192.168.1.0      144.1.23.2               0             0 2 i

 

Suppressing more-specific routes

​

The keyword summary-only filters all more-specific routes which belong to the aggregate-address and only the summary will be advertised.

 

 

London-R1

router bgp 1

 no synchronization

 bgp log-neighbor-changes

 network 172.30.0.0 mask 255.255.255.0

 network 172.30.1.0 mask 255.255.255.0

 aggregate-address 172.30.0.0 255.255.254.0 summary-only

 neighbor 116.1.12.2 remote-as 2

 no auto-summary

 

The more-specific routes are still shown in R1’s BGP table, but they are marked with as suppressed (s>):

 

 

London-R1#sh ip bgp

BGP table version is 12, local router ID is 172.30.1.1

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

*> 10.0.0.0/24      116.1.12.2                             0 2 3 i

*> 10.0.1.0/24      116.1.12.2                             0 2 3 i

s> 172.30.0.0/24    0.0.0.0                  0         32768 i

*> 172.30.0.0/23    0.0.0.0                            32768 i

s> 172.30.1.0/24    0.0.0.0                  0         32768 i

*> 192.168.0.0      116.1.12.2               0             0 2 i

*> 192.168.1.0      116.1.12.2               0             0 2 i

 

R3 and also R2 now only have the summary address left:

 

 

London-R3#sh ip bgp

BGP table version is 12, local router ID is 10.0.1.3

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

*> 10.0.0.0/24      0.0.0.0                  0         32768 i

*> 10.0.1.0/24      0.0.0.0                  0         32768 i

*> 172.30.0.0/23    144.1.23.2                             0 2 1 i

*> 192.168.0.0      144.1.23.2               0             0 2 i

*> 192.168.1.0      144.1.23.2               0             0 2 i

 

 

Advertising the aggregate-address with more-specific routes

 

 

In some cases it might be useful to not only have the aggregate-address but also the more-specific routes. Below R1 is advertising (again) the aggregate-address and both more-specific routes. While the aggregate-address is left by its default, the more-specific routes have set a community attribute:

 

 

 

London-R1

router bgp 1

 no synchronization

 bgp log-neighbor-changes

 network 172.30.0.0 mask 255.255.255.0

 network 172.30.1.0 mask 255.255.255.0

 aggregate-address 172.30.0.0 255.255.254.0

 neighbor 116.1.12.2 remote-as 2

 neighbor 116.1.12.2 send-community

 neighbor 116.1.12.2 route-map To-R2 out

 no auto-summary

!

access-list 101 permit ip host 172.30.0.0 host 255.255.254.0

!

route-map To-R2 permit 10

 match ip address 101

 set community none

!

route-map To-R2 permit 20

 set community no-export

 

 

 

The summary-only keyword has been deleted so R1 will advertise its more-specific routes again. The route-map To-R2 sequence 10 now matches the aggregate-address and leaves it to its defaults while all other advertised routes (only the two more-specific routes in this case) have the community attribute no-export. The community attribute no-export means that the receiving AS is not allowed to advertise those routes to another eBGP Peer, the routes still will be advertised to iBGP Peers. Something to also have a look into is the ACL 101 with its special use, instead of using a source and destination address, the IP prefix is used as the source host and the prefix mask is used as the destination host. This ACL will only match on the prefix 173.30.0.0/23, while a standard ACL like permit 172.30.0.0 0.0.1.255 would match on the aggregate and on both more-specific prefixes. Remember a 0 in a wildcard mask means match this bit while a 1 means dont care about this bit. So having a wildcard like 0.0.1.255 means that do not care about the last bit in the third octet that also means that bit could be a 0 or a 1 which leads do a decimal 0 or 1 (172.30.0.0 and 172.30.1.0). An ip prefix-list could have been used instead of an ACL to match the aggregate address. The BGP Tables on R2 and R3 now look like this:

 

 

Newyork-R2#sh ip bgp

BGP table version is 16, local router ID is 192.168.1.2

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

*> 10.0.0.0/24        144.1.23.3               0             0 3 i

*> 10.0.1.0/24        144.1.23.3               0             0 3 i

*> 172.30.0.0/24    116.1.12.1               0             0 1 i

*> 172.30.0.0/23    116.1.12.1               0             0 1 i

*> 172.30.1.0/24    116.1.12.1               0             0 1 i

*> 192.168.0.0       0.0.0.0                     0         32768 i

*> 192.168.1.0       0.0.0.0                     0         32768 i

 

Milan-R3#sh ip bgp

BGP table version is 16, local router ID is 10.0.1.3

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

*> 10.0.0.0/24      0.0.0.0                  0         32768 i

*> 10.0.1.0/24      0.0.0.0                  0         32768 i

*> 172.30.0.0/23    144.1.23.2                             0 2 1 i

*> 192.168.0.0      144.1.23.2               0             0 2 i

*> 192.168.1.0      144.1.23.2               0             0 2 i

 

 

If we have a look at the more-specific routes on R3, we’ll see that R1 advertises them with a community:

 

 

R2#sh ip bgp 172.30.1.0

BGP routing table entry for 172.30.1.0/24, version 15

Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)

 Not advertised to any peer

 1

 116.1.12.1 from 116.1.12.1 (172.30.1.1)

 Origin IGP, metric 0, localpref 100, valid, external, best      Community: no-export

 

 

Advertising aggregate an selected more-specific routes

​

In case your own AS is connected with more than one peer to one or more ISPs, you can select over which peers traffic should be delivered for your different prefixes if you only advertise those prefix over the desired peer. With an additional advertisement of an aggregate-address you can also have a redundancy in case one of those peers loses its session. The selective advertisement of more-specific routes can be defined over a so called suppress-map in which the routes are defined that should not be advertised to the other AS. The following example shows a configuration for one peer on the router to see how the suppress-map works.

 

 

London-R1

router bgp 1

 no synchronization

 bgp log-neighbor-changes

 network 172.30.0.0 mask 255.255.255.0

 network 172.30.1.0 mask 255.255.255.0

 aggregate-address 172.30.0.0 255.255.254.0 suppress-map SUP

 neighbor 116.1.12.2 remote-as 2

 no auto-summary

!

ip prefix-list SUP seq 5 permit 172.30.0.0/24

!

route-map SUP permit 10 match ip address prefix-list SUP

 

London-R1#sh ip bgp

BGP table version is 15, local router ID is 172.30.1.1

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

*> 10.0.0.0/24      116.1.12.2                             0 2 3 i

*> 10.0.1.0/24      116.1.12.2                             0 2 3 i

s> 172.30.0.0/24    0.0.0.0                  0         32768 i

*> 172.30.0.0/23    0.0.0.0                            32768 i

*> 172.30.1.0/24    0.0.0.0                  0         32768 i

*> 192.168.0.0      116.1.12.2               0             0 2 i

*> 192.168.1.0      116.1.12.2               0             0 2 i

 

 

AS_Set

 

The as-set keyword within an aggregate-address will set all AS which the more-specific routes have passed to the point where the aggregate-address has been configured. Without this keyword, the aggregate address would only show the passed AS’ from the point where the aggregate-route has been configured. R2 is now creating an aggregate-address for both loopback interfaces of R1 with the summary-only keyword only. The BGP Table of R3 shows the aggregate address as originated from AS2

 

 

Milan-R3#sh ip bgp

BGP table version is 24, local router ID is 10.0.1.3

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

*> 10.0.0.0/24        0.0.0.0                  0         32768 i

*> 10.0.1.0/24        0.0.0.0                  0         32768 i

*> 172.30.0.0/23    144.1.23.2             0             0 2 i

*> 192.168.0.0        144.1.23.2            0             0 2 i

*> 192.168.1.0        144.1.23.2            0             0 2 i

 

 

If the keyword as-set is used on R2, the path information in R3 BGP table shows now that its originally coming from R1

 

 

NewyorkR2

router bgp 2

 no synchronization

 bgp log-neighbor-changes

 network 192.168.0.0

 network 192.168.1.0

 aggregate-address 172.30.0.0 255.255.254.0 as-set summary-only

 neighbor 116.1.12.1 remote-as 1

 neighbor 144.1.23.3 remote-as 3

 no auto-summary

 

Milan-R3#sh ip bgp

BGP table version is 25, local router ID is 10.0.1.3

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

*> 10.0.0.0/24        0.0.0.0                  0         32768 i

*> 10.0.1.0/24        0.0.0.0                  0         32768 i

*> 172.30.0.0/23    144.1.23.2            0             0 2 1 i

*> 192.168.0.0        144.1.23.2           0             0 2 i

*> 192.168.1.0        144.1.23.2            0             0 2 i

 

 

Important to know is that if as-set is used the aggregate-route inherits all attributes of its more-specific routes. Furthermore if the paths of the more-specific routes do not match, the unsorted AS List (AS_Set) will be used and shown in the BGP Table instead of the sorted one (AS_Sequence) . R1 will drop this summary route due to the BGP loop prevention mechanism since the aggregate-address now contains all path informations, including AS 1.