This page is designed to track the connectivity of the global routing system by ranking providers on who they are connected to. Now this is a subjective rating system, so before you flame me, please understand that this for educational purposes only. However, I have, and others, may find it useful as a way to pick backbone providers.
This also helps me track the concept that sales droids have been trying to tell me, "UUnet is losing ground as the largest ISP in the world". This may be true, but if these rankings make sense, its not been by much.
The ranking system is done by a perl script and the BGP dump information from the University of Oregon route-views project. For more informaiton go here. My employer provides routing-table information to this project to help extend the functionality of the route-views tool.
To read the ratings:
The first line is the AS owner(as known to the ARIN/RIPE/APNIC databases - getting this has been unreliable - I'd like to blame the ARIN whois servers), their AS, and the totally subjective rating number.
The second line has more meat, where is describes routes that the
provider provides connectivity for. The first number is the total
of routes, then in parentheses a breakdown of those routes. The
first number in parentheses is the routes that they originate,
and the second is the number of routes they are primary transit
for. The bonus number is generated by the size of the prefixes
they announce. Obviously providing connectivity to a /8 is
better than a /24. This number is generated and designed to
take this into account. The final number is the average
prefix size of all their announcements.
The next line contains a percentage of all the prefixes that they either are the best route to, or the owner of.
Note, the rankings are going to ebb and flow every day. For example, Cisco's behavior of breaking a tie with the "oldest" route could lead towards to quite a bit of difference in this report. Of course this could also lead me to believe that this report also watchs stability of the routing system on a day to day basis. Please take with a grain fo salt.
Recent change (August 10th): Fixed this so it doesn't include alot of /25 and greater prefix lengths in the calculation. Also adjusted so that if a provider is bleeding routes to the route-views, it will discard them as not being globally routable. Aka, these routes won't pad the numbers anymore...I'm sure there will be a reasonable amount of change from now on.
Big Update (November 2nd): The entire engine has been re-written to hopefully better reflect the Internet as a whole. The system now counts a transit path as every AS that is adjacent to the owning AS. This now should weigh out the percentage of how many of the global prefixes are you adjacent to the originating AS. Note, I've also added many items to prevent padding of the score. Example, transit paths are not counted if the transit AS and the AS presenting the path are the same.
New update (Feb 2 02) The results are pretty skewed as it seems that ignoring the path if the transit AS is the AS that sent the route to the route-views. I think that this has made the results off as appears AT&T doesn't have the benefits of someone using them as their primary access. Just because they are the only ISP to send a route to the viewer does not discount that they aren't still adjacent to a prefix. We will try counting it this way and determine if this is more viable.
New Update (2-17-02) This apparently skewed the data to really favor those that send routes to the route-views project. To correct this, the system now counts adjacent routes backwards and forwards. So, if you do not supply routes to the route-views, it will use reverse paths to count what AS's you are adjacent to. This report now fully utilizes the data provided. If the report does not record every AS you are adjacent to, its because that path is not available at route-views. If you would like to be properly reflected with all your paths, please contribute your feed to the route-views project. Most of the large ISPs contribute a feed, so that should be pretty accurate.
New Update (03-1-02) The new feature is that now it will record per autonomous system who it peers with, either customer or peer. I believe it will help account for if this script detected all the peers of an ISP. From the bug fix realm. there were some peers that were "double dipping" my counting system of reverse and forward paths. This has been corrected.
Recent change on April 23rd: Limited entries counted to 300 instead of 500. The last 200 entries aren't very interesting, while they slow down the process quite a bit.
Backbone provider rankings by date: