Open Nav

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.

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]

Website by Echo
Email
Call