BGP Aggregate Addresses

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

Route aggregation with static routes

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

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:

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 with the 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.

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

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

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.

R2
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

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.

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>):

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:

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 and 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:

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:

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

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.

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

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

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

R2
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

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.

About these ads

8 comments

  1. Ramkumar

    good work my friend , I can see your efforts to explain the concepts in lucid manner still expecting more such outputs in future.

    • pashtuk

      Hi Ramkumar
      Thank you for your feedback. Im trying to write more articles but work keeps me busy at the moment. Hope it settles down in a few weeks so I got more time and spirit to write more stuff again.
      Best regards

      Michel

    • kuldeep singh

      Good work, infact i got cleared that concept today only..looking forward for such a simple way to make the concept clear..hats of boss..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s