How accurate are the Internet Route Registries (IRR)

Posted by Andree Toonk - March 28, 2009 - BGPmon.net, IRR - 12 Comments
Many service providers use an IRR to register their routes and to create BGP filters. These filters define what they will accept from customers or peers.  This is considered a good practice, as it will prevent accidental leaks. However, using an IRR to build your filters is only useful if the registries are complete. You probably have heard people saying that the IRR is incomplete and therefore useless. The question remains, how incomplete is it? What is an IRR The Internet route registry allows you to document a number of things about your network in a predefined format called RPSL. Common things to register are, your routing policies, what do you announce to who? And which prefixes are you originating and from which origin AS. In theory this is a wonderful idea, but as with many things in life ,day-to-day practice is a bit different.  If not everyone registers their routes in an IRR there’s no way of verifying if this is a valid announcement or not. After all it could just be that the origin AS announcing this prefix is not using the IRR the register their routes. How to use the IRR Some providers I work with such as Geant and Canarie are very strict in the IRR usage. If you don’t register your route, they will not accept it.  Simple as that! Since a few months BGPmon.net has support for IRR as well. Examples are the auto detect feature that will automatically detects all the prefixes for your Origin AS and indicates if there’s a valid route object or not. Another example of IRR usage can be found in the hijack detection feature. BGPmon.net will classify each hijack either as a Code10 or Code11 alarm. Depending on whether theirs is a valid route object for this announcement or not. The usefulness of these features is largely depending on the accuracy of the IRR databases.  So I decided to try to quantify the accuracy of the IRR. How accurate is the IRR BGPmon retrieves a local copy of “all well known” [1] IRR databases for analyses.  I use this data to determine the accuracy of the IRR data.  For each prefix and origin AS in the global routing table it was checked if a valid route object exist. Meaning, a route object for this prefix and this origin AS.  Let’s take a look at the prefix 142.90.0.0/16. This prefix is announced by AS271. For this IRR check to succeed a route object such as below has to exist
route:        142.90.0.0/16
descr:        Tri-University Meson Facility (TRIUMF)
origin:       AS271
notify:       nmc@BC.net
mnt-by:       BCNET-BC-MNT
changed:      bofh@BC.net 20090102
source:       bcnet
More specifics and aggregates. During this analysis I checked for both exact matches as well as a possible less specific (aggregate) that covered the prefix. In my experience, all our upstreams always required all the prefixes we wanted to announce to be explicitly defined as a route object.  More specifics are not accepted unless there’s an exact route object.  I wonder how your upstreams are doing this? The result
valid route object (exact routes) (Green = high score (good), Red = low score (bad))

valid route object (exact routes) (Green = high score (good), Red = low score (bad))

As it turns out 46% of all the prefixes in the routing table today have a valid route object. This means that if everybody would use strict IRR filtering, the way it is done by for example Geant and Canarie,  54% of the prefixes on the Internet would be unreachable, that’s 153685 prefixes. If we allow more specific as well, 62 % of all prefixes have a valid route object. I also distinguished the result on a per country basis, the result can be found below. And in the images. The images represent how many route objects were found for each prefix on a per country basis. Green means good, yellow medium and red means bad. In this map it's clearly visible that some countries score better than others. However, it might be that this analysis did not take into account an IRR server [1]  used in that region or country.
valid route object (including aggregates) (Green = high score (good), Red = low score (bad))

valid route object (including aggregates) (Green = high score (good), Red = low score (bad))

Raw data results: For those interested in a more detailed result, please see these files. Curious how accurate the IRR information for your prefixes are? Just search for your AS in the text files below. What does all this mean? It means what many already knew, the IRR is incomplete.  In this blog post I tried to quantify this and presented you some numbers, these might be as expected or shocking. The fact however is, that if we ever want to do proper filtering based on route-objects or preferably ROA’s, we have a whole lot of catching up to do. For those interested in this subject, Renesys did a similar analysis here.
Disclaimer & data sources
The check only examined route-objects. Route objects from the IRR registries below were examined.
RIPE RIS was used as a data source for the rib files. Only IPv4 prefixes were included.
MaxMind geo IP library was used to determine country information.
[1] Used IRR registries:
ripe, altdb, aoltw, apnic, arin, bcnet, bell, deru, digitalrealm,easynet, ebit, epoch, gt, gts,
gw, host, jpirr, level3, mto, nestegg, nttcom, openface, ottix, panix, radb, reach, retina,
rgnet, risq, rogers, savvis, wvfiber

12 comments

  • michael kubert says:

    Hi guys,
    Great article!
    It looks like I need to update my whois 😉

    Keep up the great work

  • Arne says:

    I checked the AS I’m responsible for and, as expected, found no unregistered prefixes. Thanks for this Service!

  • Andree says:

    For those who want to check their prefixes for valid route objects: You can now also use this url: http://www.bgpmon.net/ASinfo.php?AS=271

    Replace 271 with your own AS.
    It will show some general information for your AS, as well as all the prefixes announced by your AS.
    It will check for valid route objects for all of your prefixes.

  • I think if you use ALL the bases listed
    http://www.irr.net/docs/list.html, will make a greater contribution. Both under
    standpoint of accuracy of the records as the reliability of the bases.

  • Adrian says:

    If we add up the routes of bases that are missing (basically Pegasus and D) the difference is absurdly insignificant (Pegasus and D do not add up to 30 prefixes), so data remains reliable and accurate.

  • Yes, Adrian I understand. If your study isn’t permanent, you are correct. Thank you.

  • Andree says:

    Hi Julião,

    Keep in mind that this work was done in March 2009.
    When I did this study these were the all the IRR’s listed on http://www.irr.net/docs/list.html.
    So this study is snapshot of the situation in March 2009.

    As Adrian noted, there are only a few minor changes, it’s likely the results probably don’t differ much today.

  • Thanks, Andree for the good point. The work is very interesting. But I do not agree with the view of Adrian on the irrelevance of some IRR databases.

    In the past my AS28182 was recorded in WVFIBER, replaced by BBOI. Just now I use PEGASUS. If it were today, would be surprised to see that AS28182 is not on the article lists.

    If you search the RADB whois for my block, 189.89.0.0/20, you will see that there is a route object created by others (I guess it’s NTTCOM). So I think that users of the IRR need some recommendations for best practices, too. It’s an elementary step to the reliability of IRR.

  • Adrian says:

    How can a database with about 15 autonomous systems and fewer than 30 routes alter the results of this paper? This is the main issue. If a database as the RIPE or RADB had been forgotten I would not question, but a database as small as that cited no statistical relevance to such a search. That’s a fact!

  • But Adrian, “Prefixes that did not have an exact route object” and “Prefixes that not have an exact route object or an aggregate with a correct route object” aren’t statistics.

  • Adrian says:

    That’s your opinion, personally I do not think you understand the objectives of the study.

  • Meyer says:

    That’s a great study. People sadly ignore IRR information which can be easily automated upon BGP routing reconfigurations if someone wanted too. Its said, I recently had to find out how Sprint and ATT interexchange their communications as well as how Yahoo and Intelig are connected to ’em and find out some weird AS-PATH prepend behavior and some of those company’s IRR informations were just… imprecise (to say the least).

    Yes, PEGASUS is irrelevant for sure and many ISPs under this IRR are just out of date as well. So why bother? Its a 2009 article which keeps up-to-date because just like this article, IRR seems not to change as it should.

    Some BGP implementations have native tools which allow ’em to import and export routing information to RPSL (and filters, etc). I wish…

Leave a Reply

Your email address will not be published. Required fields are marked *