Introduction

In the early days of the Internet very little examination of the contents of the Routing Table had been carried out. While there were many discussions about the size of the table, only one or two efforts at recording the size and contents of the table had been made.

With the introduction of CIDR and the transition from classful to classless addressing, the CIDR Report was instigated by Tony Bates as an effort to encourage ISPs to drop classful prefixes in favour of classless aggregates. The CIDR Report looked at the Internet Routing Table on a global scale and listed the top 30 ISPs who were contributing to the size of the table.

The CIDR Report was all that was really available to the general public, and examination of the table on a global scale ignored regional variations. The Routing Report was born out of this need.

Background

The current Routing Report takes a BGP feed from host organisations who volunteer an EBGP Multihop feed with the collector hosted by NSRC at the University of Oregon.

When the report was originally established in 1999, the Routing Report accessed APNIC's router at DIX-IE in Japan. This router has a view of the full Internet Routing Table as received from APNIC's transit providers at DIX-IE. This report still operates and can be accessed here.

Initially the analysis was targeted at the Asia Pacific Region, APNIC's service region, giving statistics on the Routing Table size and the APNIC region ISP's contribution to the Routing Table.

However, other regions showed interest in the details delivered by the report, and very soon it was extended to include other RIR regions, most recently with AfriNIC joining the RIR system. The report is now sent to the major operations lists around the world, on a request basis.

The report is produced on a weekly basis, with the mail shot based on data captured at 4am Australian Eastern Standard Time (+10GMT) every Saturday. The report is actually run on a daily basis, with a specialist mailing list as the destination for interested subscribers.

The weekly mailshot is currently sent to the NANOG, APOPS, RIPE Routing WG, and AfNOG lists amongst others.

Explaining the Report

This section explains the contents of the report based on the headings contained in it.

Analysis Summary

Registry Region Analysis Summary

RIR Region Per AS Prefix Count Summary

This section lists the top 20 ASes per RIR service region and their contribution to the Internet Routing Table. This is not the same as listing the largest ISPs, but those who are contributing most prefixes to the Internet. The columns list the ASN and the registered name of the ASN holder, the number of prefixes being announced, and the equivalent size in units of /20 blocks, and the number of prefixes they would announce if the AS operator attempted to aggregate their announcements better.

Global Per AS Maximum Aggregation Summary

This section lists the top 20 ASes who would contribute most to reducing the size the Internet Routing Table if they would perform better aggregation of their BGP announcements.

List of Unregistered Origin ASNs (Global)

This section lists any unallocated ASNs in use on the Internet. Mostly this captures private ASNs, but can also capture unallocated or ASNs still in the IANA reserved pool.

Advertised Unallocated Addresses

This section lists any prefixes being announced from unallocated address space.

Number of prefixes announced per prefix length (Global)

This section lists how many prefixes are being announced per prefix length in the Internet Routing Table

Advertised prefixes smaller than registry allocations

This section lists the top 20 ASes which are announcing prefixes smaller than the minimum allocations made by the RIRs. It indicates the top deaggregators in the Internet.

Number of /24s announced per /8 block (Global)

This section lists how many /24s are being announced out of each of the /8 address blocks. It is designed to show where all the /24s in the Internet Routing Table are coming from.

Other Details

The analysis software generally assumes it is going to receive a file which is the snapshot of BGP feed from a Cisco IOS router. Generally a captured "show ip bgp summary" is sufficient.

The analysis software will take the BGP table from the router, and process the best paths only, ignoring alternative paths. The idea is that it makes most sense to use the paths that the router considers best, rather than anything else.

If the feed provided to the router has no best path in it at all (for example, it might be the BGP feed received from a peer only), the software will process that in its stead. Where multiple paths to the destination are available, with no best path chosen by the router, the software will take the first path in the list (basically the oldest path as the router sees it).

Summary

It is hoped that the data that the Routing Report supplies are useful to service providers and Internet operations observers. While the original aim was to encourage aggregation on a regional basis, it now has a much larger role of providing info on various Internet metrics.

Caveats

I really do hope that the analysis is bug free. It wouldn't surprise me if there are errors though. If you find any, please let me know.

Some of the older reports had some small errors in them - while I've fixed errors in the software, I haven't gone back and re-run the analysis.

IPv6

Acknowledgements

Acknowledgements go to the many people who have reported bugs in the analysis software, to Tony Bates for original inspiration, and to Geoff Huston and Ronald F. Guilmette for many constructive suggestions and ideas.

Also, appreciative thanks to APNIC for permitting access to their Japanese node router, and for providing the server to run the analysis software and store the copious quantity of data it produces.

And finally thanks to NSRC for this version of the Routing Report which is focusing on the global Research and Education network infrastructure.

Philip Smith - March 2021

Back to Home page