Advertising Aggregates Routes

As a BGP admin, you will often need to make decisions on the ways to partition your IP Space, which routes to advertise to the Internet and which routes to suppress.

Ideally, you’d want to aggregate your IPv4/IPv6 Space as much as possible, by only advertising aggregate prefixes (also known as supernets and summary routes) to the Internet. Practically, this would mean that your Autonomous System (AS) will originate IP prefixes assigned to you by Regional Internet Registries (RIRs) or delegated to you by Upstream Providers, while suppressing all other advertisements. If everybody were to follow this rule, the Internet routing table would be much smaller and we would not have issues with FIB exhaustion.

In reality, however, we see that this set up not always possible, and will discussion the reasons for this in future articles.

In today’s discussion, we will use an example of a small ISP as illustrated below. This ISP was allocated ‘198.51.0.0/19 ‘ network that has been fragmented to cover ISP’s own needs (loopback addresses, point-to-point IPs) and allocated to end customers.

Your network might be different, as you might be managing an Enterprise deployment or have a different physical / logical topology. The basic principles discussed in this article will remain the same for any network.

Small ISP Network

Aggregate-Only Scenario

Aggregate-only is the scenario where the only prefix (or prefixes) advertised to the Internet is the block assigned by Regional Internet Registries (RIRs) or delegated by Upstream Providers.

In our example, this would mean that only ‘198.51.0.0/19 ‘ would be sent to the Internet.

Aggregate Advertisement to Upstream Peers

You need to take a few steps to implement this aggregation scenario:

Inject ‘198.51.0.0/19’ route into BGP

Advertise ‘198.51.0.0/19’ into BGP

Suppress all other advertisements

Inject Route Into BGP

Injecting route into BGP is your first task. Different vendors might offer different mechanisms to achieve this. The one preferred by the author is by using static routes with route-tagging.

In its simplest form, you’d use two tags – one for Aggregate routes being advertised to EBGP peers and the other one for Customer routes local to your Network.

Static Tag

BGP Communities

Meaning

100

110:100

Aggregate Route to be advertised to the Internet

200

110:200 no-export

Customer Route not to be advertised to the Internet

Cisco IOS and IOS-XE Example

Cisco IOS and IOS-XE routers maintain BGP table that is different from the routing table, allowing to redistribute static routers into BGP table first and then match BGP Communities before advertising routers to EBGP peers.

Cisco Aggregate Advertisement via Redistribution

Create aggregate static route pointing to Null interfaces:

ip route 198.51.0.0 255.255.224.0 null 0 tag 100

Redistribute static route into BGP with predefined community attributes.

Juniper Example

As opposed to Cisco, Juniper routers do not maintain dedicated BGP table for inet.0 routes, meaning that you cannot redistribute routes into BGP with a certain community and then match this community before sending routes to EBGP peers all on the same router.

Cisco Aggregate Advertisement via Redistribution

Instead, we will use two redistribution policies – one for IBGP sessions and the other for EBGP sessions.

Create aggregate discard static route:

set routing-options static route 198.51.0.0/19 discard tag 100

Advertise Static Routes to IBGP Members

set policy-options community aggregate members 110:100set policy-options community customer-local members 110:200set policy-options community customer-local members no-exportset policy-options policy-statement Static-to-EBGP term 10 from protocol staticset policy-options policy-statement Static-to-EBGP term 10 from tag 100set policy-options policy-statement Static-to-EBGP term 10 then acceptset policy-options policy-statement Static-to-IBGP term 10 from protocol staticset policy-options policy-statement Static-to-IBGP term 10 from tag 100set policy-options policy-statement Static-to-IBGP term 10 then community set aggregateset policy-options policy-statement Static-to-IBGP term 10 then acceptset policy-options policy-statement Static-to-IBGP term 20 from protocol staticset policy-options policy-statement Static-to-IBGP term 20 from tag 200set policy-options policy-statement Static-to-IBGP term 20 then community add customer-localset policy-options policy-statement Static-to-IBGP term 20 then accept
set policy-options policy-statement Static-to-IBGP term 9999 then rejectset protocols bgp group IBGP export Static-to-IBGP

Where to originate aggregates?

So far, we have covered the topic of how to originate aggregate routes, but we have not discussed where to originate these routes from. It is paramount that the aggregate routes always get advertised, or your network will get isolated from the public Internet. Every network is different, so let us consider a typical ISP setup with four layers:

Peering Layer for Transit/Public/Peering connectivity

Core (P) Layer

Dedicated Route-Reflector Layer

Access Layer used for End Customer connectivity

Core layer might sound like an obvious choice, as it is supposed to be the most reliable part of your network. Despite this, we do not recommend originating routes from the Core. It is likely that you are already running BGP-Free Core or will migrate to BGP-Free Core in the future, making it impossible to inject any routes into BGP at the Core, as your Core devices will simply not run BGP.

Route-Reflector layer can be used to originate aggregates. In fact, this is how it’s done by many service providers. But you should be aware of one significant risk associated with this approach. If you don’t take some additional steps such as Next-Hop manipulation, your Route-Reflectors will start attracting traffic for unallocated subnets. In our previous example of 198.51.0.0/19 network, unless the entire prefix got fragmented into smaller pieces and more specific routes are available for all IP addresses in 198.51.0.0/19 range, traffic will start hitting Route-Reflectors. This is not desirable, as Route-Reflectors might not have bandwidth and CPU resources to handle these packets. This means that you should really know what you are doing, or simply do not use Route-Reflectors to originate Aggregates.

Peering Layer is the one we recommend using for Aggregate Origination. It is expected that at least one peering device on your network is up and in healthy state, or you are no longer connected to the Internet, making it the obvious choice for route-origination. While you might have many peering routers on your network, the total number is not as high as the number of access layer devices, so if a new Aggregate block gets allocated to you, configuration changes will need to be implemented on a relatively small number of devices. There is one scenario you need to be aware of and watch out for – if the peering device gets totally isolated from the rest of your network, it should stop advertising the aggregate block or your traffic will be blackholed. There are a few techniques you could employ in this scenario, all vendor-specific, so leave us a note if you want to discuss this topic.

Access Layer could also be used to generate Aggregates. In many ways, Access and Peering layers are very similar, as both used for 3rd party connectivity. The drawback of using Access Layer for Aggregate Origination is the number of devices you would need to update in case of new Aggregate allocation. It might also be risky and inefficient, as traffic for unallocated IPs within your Aggregate Block will arrive to one of the Access Layer devices just to get dropped. It is much more efficient to drop this unwanted traffic at the Peering Layer as soon as it enters your network.

It is also possible to originate Aggregate routes at more than one layer, for example simultaneous Peering and Access Layer origination is very common. It all comes down to the size of your network and your ability to implement simultaneous changes on multiple devices.

Suppressing Specific Blocks

So far, we’ve discussed how to advertise aggregate blocks, but said nothing about suppressing specific routes. There is a reason for that – if you use route-tagging and route-filtering approaches described in this article, non-aggregate routes will be suppressed automatically. Unless routes are tagged with specific values (‘100’ for static and ‘110:100’ for BGP routes in the previous examples), they will not be leaked to the Internet. This means that there is nothing for us to suppress.