Skip to main content

Route Aggregation

The purpose of this document is to describe the industry's collective opinion on a best practice framework to be used when evaluating a networks efficiency based on the number of route announcements from that network.

Introduction

The reasons for ensuring that any network is aggregated to the greatest practical extent are well documented elsewhere and are therefore not discussed within this document. Further references are included in the links section.

This is necessarily a 'living document', and it is the intention of LINX Council that it will be subject to continuous review with the membership in order to ensure that it continues to reflect the collective view of the industry.

Optimal Route Aggregation Evaluation

Network providers should aggregate their route announcements to the greatest practical extent.

It is accepted best practice that maximal aggregation of route announcements may not always be practical, so it is suggested that network providers should announce no more than (N * 2) + 3 prefixes, where N is the number of maximally aggregatable prefixes that could originate from the AS under ideal conditions.

There are two scenarios where prefixes can be aggregated.

Firstly:

  • They have the same AS path
  • They are adjacent
  • They are of equal size
  • They can be represented by a single new larger prefix which covers exactly the same address space as the two original prefixes.

In this case, the single new larger prefix is advertised, and the two original prefixes are withdrawn.

Or secondly:

  • They have the same AS path
  • One of the prefixes is larger than the other prefix
  •  The larger prefix includes the address space of the smaller prefix

In this case, the smaller prefix is withdrawn, and the larger prefix continues to be advertised. No new prefixes are advertised.

In order to determine maximal aggregation such prefixes shall be aggregated, and the criteria above applied again. This process shall be repeated until no further prefixes can be aggregated..

For network providers with large amounts of address space, for prefixes smaller than /16, deaggregates up to /16 are considered acceptable and all such announcements, for the purposes of the aggregation calculations, will be counted as one. For example, a Network provider with a /14 is able to announce this as 4 /16s and this is counted as 1 announcement.

These guidelines on aggregation should apply at all points of observation.

Examples of aggregation calculations
Example #1 

If you currently advertise the following prefixes from your ASN:

10.123.4.0/24
  10.123.5.0/24
  10.123.6.0/23

On the first aggregation pass, you could aggregate the first two prefixes into a single /23, leaving you with:

10.123.4.0/23
  10.123.6.0/23 

If you then aggregate again, you'll be able to further aggregate these together into a single /22, leaving you with:

10.123.4.0/22

However, if you were advertising the following prefixes: 

10.201.5.0/24
  10.201.6.0/24

Then these are already aggregated as far as possible, as although they are consecutive, and it appears that they could be replaced with a single /23, the first prefix, 10.201.5.0/24 is not on a /23 boundary.

Example #2

If you currently advertise the following prefixes from your ASN 65000 (with AS paths in brackets):

10.10.0.0/16 (65002 65000 i)
  10.10.4.0/23 (65001 65000 i)
  10.10.10.0/24 (65002 65000 i)

If you compare the first and second prefixes, then they have different AS paths, so cannot be aggregated.

If you compare the first and third prefixes, then they have same AS path, and the third prefix (the /24) is already included in the address space of the first prefix (the /16), so the third prefix should not be advertised.

Therefore, after aggregation, you should be left with just the two prefixes advertised:

10.10.0.0/16 (65002 65000 i)
  10.10.4.0/23 (65001 65000 i).

Example #3

Consider the prefixes announced from your ASN65000:
10.10.0.0/17 (65002 65000 i)
 10.10.128.0/17 (65002 65000 i)

These two prefixes:

have the same AS path
are adjacent
are of equal size.

Therefore these two prefixes can be replaced by one single aggregated prefix:

10.10.0.0/16 (65002 65000 i)


Links

Geoff Huston's Paper: Analyzing the Internet's BGP Routing Table
RFC 2519

[last modified: 14-10-2006]

With over 780 members connecting from over 76 different countries worldwide, LINX members have access to direct routes from a large number of diverse international peering partners.

© London Internet Exchange, 2017 Registered office: London Internet Exchange Limited, 2nd Floor, Trinity Court, Trinity Street, Peterborough PE1 1DA United Kingdom . Registered in England, Number: 3137929
VAT Registration Number: GB 665 9580 82 Head office main telephone number Telephone: +44 (0)1733 207700 Fax: +44 (0)1733 207729

Web Design by Web Design by Bluestorm Design & Marketing

Leave Feedback

Cookies

This site uses cookies to store information on your computer. Some of these cookies are essential to make our site work and have already been set. By using our site you accept the terms of our Privacy Policy.

×