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.
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.
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.
- 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.
route-map Static-to-BGP permit 10 match tag 100 set community 110:100 ! route-map Static-to-BGP permit 20 match tag 200 set community 110:200 no-export ! route-map Static-to-BGP deny 9999 router bgp 110 redistribute static route-map Static-to-BGP
- Verify that the route was injected with proper BGP community attributes:
ce11#show bgp 198.51.0.0/19 BGP routing table entry for 198.51.0.0/19, version 4 Paths: (1 available, best #1, table default) Not advertised to any peer Refresh Epoch 1 Local 0.0.0.0 from 0.0.0.0 (192.168.3.231) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Community: 110:100 rx pathid: 0, tx pathid: 0x0
- Advertise Aggregate Route to EBGP Peers:
ip community-list expanded aggregate permit 110:100 route-map EBGP-Out permit 10 match community aggregate set community none ! route-map EBGP-Out deny 9999 ! router bgp 110 neighbor 120.0.4.17 remote-as 100 neighbor 120.0.4.17 route-map EBGP-Out out
- Verify that the aggregate route is being advertised to EBGP neighbor
ce11#show ip bgp neighbors 120.0.4.17 advertised-routes ... Network Next Hop Metric LocPrf Weight Path *> 198.51.0.0/19 0.0.0.0 0 32768 ? Total number of prefixes 1
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.
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:100 set policy-options community customer-local members 110:200 set policy-options community customer-local members no-export set policy-options policy-statement Static-to-EBGP term 10 from protocol static set policy-options policy-statement Static-to-EBGP term 10 from tag 100 set policy-options policy-statement Static-to-EBGP term 10 then accept set policy-options policy-statement Static-to-IBGP term 10 from protocol static set policy-options policy-statement Static-to-IBGP term 10 from tag 100 set policy-options policy-statement Static-to-IBGP term 10 then community set aggregate set policy-options policy-statement Static-to-IBGP term 10 then accept set policy-options policy-statement Static-to-IBGP term 20 from protocol static set policy-options policy-statement Static-to-IBGP term 20 from tag 200 set policy-options policy-statement Static-to-IBGP term 20 then community add customer-local set policy-options policy-statement Static-to-IBGP term 20 then accept set policy-options policy-statement Static-to-IBGP term 9999 then reject set protocols bgp group IBGP export Static-to-IBGP
- Advertise Aggregate Routes to EBGP Peers
set policy-options policy-statement Static-to-EBGP term 10 from protocol static set policy-options policy-statement Static-to-EBGP term 10 from tag 100 set policy-options policy-statement Static-to-EBGP term 10 then accept set policy-options policy-statement Static-to-EBGP term 20 from protocol bgp set policy-options policy-statement Static-to-EBGP term 20 from community aggregate set policy-options policy-statement Static-to-EBGP term 20 then accept set policy-options policy-statement Static-to-EBGP term 9999 then reject set protocols bgp group EBGP export Static-to-EBGP
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.