Packetswitch
Sign up to Packetswitch!
Already have an account? Sign in
BGP

BGP Route Aggregation (VI)

Suresh Vina
10 min read
BGP Route Aggregation (VI)
In: BGP

In our last discussion, we looked into the concept of BGP auto-summary and how once enabled, it leads to the advertisement of classful networks without the ability to specify classless subnet masks. In this part, we will explore the mechanism of advertising custom prefix lengths through route aggregation in BGP.

Route aggregation in BGP is useful to combine multiple specific routes into a single, broader route. This technique simplifies the routing table and reduces the number of routes that need to be advertised and processed.

We will be using the following topology throughout this example where HQ-01 is in AS 1000, ENT-01 is in AS 2000, and there are two intermediary ISP routers in AS 100. These ISP routers will establish an iBGP session between each other to pass along BGP routes. HQ-01 has three connected routes which we will advertise into BGP.

#HQ-01

HQ-01#show ip interface brief | incl Loop
Loopback1              100.100.1.1     YES manual up                    up      
Loopback2              100.100.2.1     YES manual up                    up      
Loopback3              100.100.3.1     YES manual up                    up 
#HQ-01

router bgp 1000
 bgp log-neighbor-changes
 neighbor 12.12.12.2 remote-as 100

Of course, we could go and add three network statements or redistribute the connected connects to advertise those three prefixes. But, our goal here is to summarize them and advertise the prefix 100.100.0.0/22 instead. If we try to add network 100.100.0.0 255.255.252.0, it won't work because BGP needs this exact prefix and mask in the routing table.

💡
When we say BGP looks for an exact prefix match in the routing table, we're talking about how BGP decides which prefixes to advertise to its neighbours. Specifically, for BGP to advertise a network using the network command, there must be an identical network prefix already present in the router's routing table. This means the prefix, along with its subnet mask or prefix length, must match precisely an entry in the routing table that is reachable.

Method 1 - Using 'null' routes

A null route is a routing table entry that discards traffic by directing it to a "null" interface, effectively a nowhere destination.

Let's proceed with how we can advertise a more summarized route in BGP.

  • As previously discussed, if you try to add the command network 100.100.0.0 mask 255.255.252.0 within the BGP configuration on HQ-01, it won't have any effect if there isn't an exact match for this network in the routing table.
  • To create an entry in the routing table for this /22 network, we can configure a null route
  • It’s important to remember that this null route won't override any more specific connected routes because connected routes have a lower administrative distance, making them preferable. They're also considered the most specific, or the "best match," for destinations within their network.
  • Once the null route for the /22 is in place, we can then add the network 100.100.0.0 mask 255.255.252.0 statement to the BGP configuration. BGP will see the route in the routing table and will advertise the /22 to its neighbours.

This technique allows us to consolidate multiple routes into a single advertisement, reducing the size of the routing table.

#HQ-01

ip route 100.100.0.0 255.255.252.0 Null0

router bgp 1000
 bgp log-neighbor-changes
 network 100.100.0.0 mask 255.255.252.0
 neighbor 12.12.12.2 remote-as 100
HQ-01#show ip bgp 
BGP table version is 28, local router ID is 100.101.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/22   0.0.0.0                  0         32768 i

If I head over to the ENT-01 router on the far right, I should be able to receive this route via BGP. Let's check it out. 

#ENT-01

ENT-01#show ip bgp 
BGP table version is 72, local router ID is 31.31.31.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/22   31.31.31.2                             0 100 1000 i

Method 2 - BGP aggregate-address command

There is another way to achieve the same results using the aggregate-address command but with more control and flexibility. Let's look at how it works. I'm going to remove the static route and network statement we created in the previous step. As soon as you do this, the prefix will disappear from the BGP table.

#HQ-01

HQ-01(config)#no ip route 100.100.0.0 255.255.252.0 Null0

HQ-01(config)#router bgp 1000
HQ-01(config-router)#no network 100.100.0.0 mask 255.255.252.0
HQ-01#show ip bgp
HQ-01#

Now, let me go and add the aggregate command and see what happens.

#HQ-01

router bgp 1000
 bgp log-neighbor-changes
 aggregate-address 100.100.0.0 255.255.252.0
 neighbor 12.12.12.2 remote-as 100
HQ-01#show ip bgp
HQ-01#

Hmm, still nothing because you need either:

  1. A network statement with one of the prefixes that fall within the aggregated prefix
  2. One of the redistributed routes must fall within the aggregated prefix

Using network statement

So, let's go and include one of the prefixes via the network statement.

#HQ-01

router bgp 1000
 bgp log-neighbor-changes
 network 100.100.1.0 mask 255.255.255.0
 aggregate-address 100.100.0.0 255.255.252.0
 neighbor 12.12.12.2 remote-as 100
#HQ-01

HQ-01#show ip bgp                        
BGP table version is 31, local router ID is 100.101.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/22   0.0.0.0                            32768 i
 *>  100.100.1.0/24   0.0.0.0                  0         32768 i

Looks good but hang on, why am I still seeing the individual /24 prefix? What's the point of advertising both individual /24 and the aggregated /22. Well, calm down, there is a summary-only parameter you can use to advertise just the /22 aggregated prefix.

#HQ-01

router bgp 1000
 bgp log-neighbor-changes
 aggregate-address 100.100.0.0 255.255.252.0 summary-only
 neighbor 12.12.12.2 remote-as 100
#HQ-01

HQ-01#do show ip bgp                                 
BGP table version is 32, local router ID is 100.101.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/22   0.0.0.0                            32768 i
 s>  100.100.1.0/24   0.0.0.0                  0         32768 i
#ENT-01

ENT-01#show ip bgp 
BGP table version is 76, local router ID is 31.31.31.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/22   31.31.31.2                             0 100 1000 i

Looks good now and you must have noticed s> in the HQ-01 router's output. It just says I'm suppressing the route (aka not advertising to my peers). ENT-01 router only sees the aggregated /22 prefix.

Using redistribution

In this example, let's use redistribution instead of using the network statement. I'm going to remove the network statement from the previous example and use redistribute connected instead.

#HQ-01

router bgp 1000
 bgp log-neighbor-changes
 aggregate-address 100.100.0.0 255.255.252.0 summary-only
 redistribute connected
 neighbor 12.12.12.2 remote-as 100

Once configured, if I go to the router in the far right (ENT-01) and check the output, I should only be able to see the aggregated prefix. 

#ENT-01

ENT-01#show ip bgp 
BGP table version is 87, local router ID is 31.31.31.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/22   31.31.31.2                             0 100 1000 i
💡
Please note that by default when you redistribute routes into BGP, the origin code will be '?'. However, when you use aggregate-address, the origin code will always be 'i' as you can see above.

BGP aggregate-address and AS_Path

For the next example, we are going to use a slightly modified diagram. In this diagram, we have a network with four different Autonomous Systems, each connected through eBGP sessions. We have HQ-01 in AS 1000 with a couple of /24 prefixes, and Branch-01 in AS 100 with a single /24 prefix. ISP-01 sits in AS 200, functioning as an intermediary, while ENT-01 is in AS 2000, representing another separate network.

#HQ-01

router bgp 1000
 bgp log-neighbor-changes
 network 100.100.1.0 mask 255.255.255.0
 network 100.100.2.0 mask 255.255.255.0
 neighbor 12.12.12.2 remote-as 200
#Branch-01

router bgp 100
 bgp log-neighbor-changes
 network 100.100.3.0 mask 255.255.255.0
 neighbor 12.12.13.2 remote-as 200
#ISP-01

router bgp 200
 bgp log-neighbor-changes
 neighbor 12.12.12.1 remote-as 1000
 neighbor 12.12.13.1 remote-as 100
 neighbor 12.12.14.1 remote-as 2000
#ENT-01

router bgp 2000
 bgp log-neighbor-changes
 neighbor 12.12.14.2 remote-as 200

ENT-01 is designed to learn about the three prefixes originating from HQ-01 and Branch-01 through its eBGP connection with ISP-01. 

#ENT-01

ENT-01#show ip bgp 

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.1.0/24   12.12.14.2                             0 200 1000 i
 *>  100.100.2.0/24   12.12.14.2                             0 200 1000 i
 *>  100.100.3.0/24   12.12.14.2                             0 200 100 i

BGP Atomic Aggregate Attribute

What we want to do here is make ISP-01 perform route aggregation to summarize the individual /24 prefixes into a single /22 prefix, specifically 100.100.0.0/22. Then, ISP-01 will advertise this aggregated route to ENT-01. Let's add the aggregate-address command on the ISP-01 router as shown below. Now, ENT-01 should only receive the aggregated prefix. 

#ISP-01

router bgp 200
 bgp log-neighbor-changes
 aggregate-address 100.100.0.0 255.255.252.0 summary-only
 neighbor 12.12.12.1 remote-as 1000
 neighbor 12.12.13.1 remote-as 100
 neighbor 12.12.14.1 remote-as 2000
#ENT-01

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/22   12.12.14.2               0             0 200 i

Everything might look okay, right? But if we take a closer look at the AS_Path information in the BGP table on ENT-01, we might spot something unusual. The AS_Paths for AS 1000 and AS 100 aren't there. It appears as if the prefixes are coming directly from ISP-01, which could be misleading. This happens because when ISP-01 aggregates the routes into a single /22 prefix, the AS_Path information of the individual /24 networks are lost.

You can use the command show ip bgp 100.100.0.0 and from the output, you can see this prefix has been aggregated by the router with RID 12.12.14.2 and the atomic_aggregate attribute is also present in the BGP update.

#ENT-01

ENT-01#show ip bgp 100.100.0.0
BGP routing table entry for 100.100.0.0/22, version 14
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  200, (aggregated by 200 12.12.14.2)
    12.12.14.2 from 12.12.14.2 (12.12.14.2)
      Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best
      rx pathid: 0, tx pathid: 0x0
💡
Atomic Aggregate attribute is used to indicate the loss of specific path attributes during route summarization. 

Now, let's consider what could happen if this BGP update with the aggregated /22 prefix ends up in HQ-01 or Branch-01. Typically, BGP has loop prevention mechanisms that would prevent a router from accepting updates that include its own AS number in the AS_Path. But, since the aggregation at ISP-01 has removed the AS numbers of the individual routes if HQ-01 or Branch-01 receives this aggregate route, there is no longer an AS number to match, so they might accept the route.

BGP Route Aggregation with AS_SET

The as-set option in route aggregation within BGP is used to retain all AS numbers from the aggregated routes in the AS_Path attribute. When you use as-set, it creates a set that lists all the Autonomous Systems that the aggregated routes have passed through.

There is a way to fix or overcome this issue by adding the as-set parameter to the aggregate-adress command as shown below.

#ISP-01

router bgp 200
 bgp log-neighbor-changes
 aggregate-address 100.100.0.0 255.255.252.0 as-set summary-only
 neighbor 12.12.12.1 remote-as 1000
 neighbor 12.12.13.1 remote-as 100
 neighbor 12.12.14.1 remote-as 2000

Now, if we head back to ENT-01 and check the BGP table, the AS_Paths should show up.

#ENT-01

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/22   12.12.14.2               0             0 200 {1000,100} i
💡
Please note that the AS_SET you see within curly braces ({}) only counts as one hop even if there are multiple ASs listed
BGP Route Filtering Examples (ACL & Prefix List)
When working with BGP, you’ll frequently need to control which routes or prefixes you share with a peer or receive from them. For instance, you might want to send one or a few prefixes with your peer.
PacketswitchSuresh Vina
Written by
Suresh Vina

Suresh Vina

Tech enthusiast sharing Networking, Cloud & Automation insights. Join me in a welcoming space to learn & grow with simplicity and practicality.
View all posts
Comments
More from Packetswitch
Table of Contents
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Packetswitch.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.