An Introduction to IRR Explorer

Last year, at the NLNOG Day 2021 event, NLNOG announced the release of a new version of IRR explorer. IRR explorer is piece of software you can run as well as a service hosted by NLNOG at irrexplorer.nlnog.net. In this article, We would like to show you some of the features of IRR explorer and how to use them.

IRR explorer shows the routing, Internet Routing Registry (IRR) registrations and Resource Public Key Infrastructure (RPKI) status for resources (prefixes, AS numbers and AS-sets), and highlights potential issues. It can help engineers spot missing or incorrect data in routing registries, potential problems with RPKI validation of prefixes, potentially incorrect route advertisements, and many other irregularities. One important thing to emphasise here is that this is just an interpretation of the data available. It's not the absolute and only truth.

Using IRR explorer

So, how can you use IRR explorer? In this article, we assume you'll be using the hosted version of the tool. When you open the website, you'll see a simple webform with only one input field, where you can enter either an IP, a prefix, an ASN, or a AS-SET. Once submitted, IRR explorer will show all data it has available about the resource.

In case of an IP-address or prefix, a table is shown with the prefixes found that directly overlap the queried prefix. In some cases, a second table is shown with prefixes that overlap with the least specific query found in the first table.

If the resource entered is an ASN, all prefixes originated by that ASN are shown in a similar way as when a single prefix is entered.

A simple example

Let's take a look at 2001:7fb:fd02::/48, a prefix advertised by RIPE NCC (AS12654) as one of the RIS Routing Beacons.

In the table shown in the image above, you can see a the information IRR explorer gathered for this prefix. Each row of the table shows one prefix which is found in a routing registry, for which a Route Origin Authorisation (ROA) is present, or a route is found in the DFZ. The table shows a number of columns:

In the first column, you see the prefix for which information is shown.

The 'RIR' column shows which Regional Internet Registry (RIR) assigned or allocated the prefix. In this example, the prefix is assigned by RIPE.

The 'BGP' column shows which autonomous systems (ASNs) originate this prefix, according to the NLNOG Ring Looking Glass (which opens when you click the link). This looking glass currently receives BGP tables from well over 100 networks. In this example, AS12654 (one of the ASNs used by RIPE NCC).

The 'RPKI' column shows ROA's registered for this prefix (if any) and the maximum prefix length for the given prefix. In this example, the ROA is valid for 2001:7fb:fd02::/48 (mentioned in the first column), and only exactly this prefix length, so more specific prefixes should be considered invalid.

Next, we see a column 'RIPE'. This is because there is a route object for this prefix registered in the RIPE database. If the prefix is registered in more than one routing registry, we would a column for each registry here. All items in these columns are clickable and show a lookup in the IRR's routing registry database. Correct entries have a checkmark, incorrect entries have an 'x' next to them. Hovering over them with your mouse pointer will show some additional information on what is wrong with that specific entry.

The last column is the 'advice' column, which shows suggestions on what could be improved in routing registries. In this example, everything looks good and no changes need to be made. In the next examples, we'll see that there are many cases where there are some things to be said about some entries.

Trouble ahead

Now that we understand more of the output generated by IRR explorer, let's look at another RIPE RIS beacon: 2001:7fb:fd03::/48, an intentionally RPKI-invalid prefix.

The two messages in red in the 'advice' column immediately stand out now.

The first message - 'RPKI origin does not match BGP origin' - points out that although the RPKI ROA tells us that AS196615 should announce the prefix, we observe the prefix originated from AS12654 in the routing tables. Clicking on the 'BGP' link will show us which peers of the NLNOG Ring Looking Glass have this prefix in their routing table.

The second message - 'RPKI-invalid route objects found' - tells us there is a route object which links the prefix to AS12654 (shown in the 'RIPE' column), which conflicts with the ROA shown in the 'RPKI' table, which links the prefix to AS196615. Of course, these two should be identical for optimal routability.

The good, the bad and the ugly

For our next example, let's look at a prefix we've all heard about: 1.1.1.0/24, which contains 1.1.1.1 (one of CloudFlare's DNS resolvers). Here's the output of the IRR explorer query:

We're looking at the 'All overlaps of least specific match 1.1.1.0/24' table in the output here, because there are some unexpected rows there. The first row is shown in green, since that row shows an entry for which everything is looking good: routing registries, RPKI data and routing data all align.

But there are two more rows: one for 1.1.1.3/32 and one for 1.1.1.15/32. You can easily see from the colours that there are a few things wrong with these. Since the issues are similar, we'll only look at 1.1.1.3/32 in this example. For both prefixes, IRR explorer shows an error, a warning and an informational message.

The error is that a RPKI-invalid route object was found, which is of course because there's only a ROA for 1.1.1.0/24 with maximum prefix length /24 and origin AS13335, and 1.1.1.3/32 originated by AS2764 fails on both conditions.

The warning message 'Expected route object in APNIC, but only found in other IRRs' is shown because this specific prefix is registered in RADB, while one would expect an entry in the APNIC database. This doesn't have to be wrong, some networks may choose to use specific routing registries for registering their prefixes, but it's at least worth mentioning.

The informational message 'Route objects exist, but prefix not seen in DFZ' is shown because even though a route object exists, the route is not seen in the global routing tables. Of course, in this case this is most likely caused by the prefix length used. In other cases, it can be that a prefix isn't always advertised (or at least not with the specified prefix length), but registrations have been made to make sure it can be routed if needed.

Based on the output above, it's hard to tell the exact reasons why these two entries were registered in RADB, but due to the ROA and the prefix length used we can safely say these prefixes won't make it far in the DFZ.

One last example

Let's look at one more prefix: 2001::/32, the prefix used for the Teredo service, so we have seen all messages generated by IRR explorer. This prefix used to be advertised by many different ASNs as an anycasted IPv4 to IPv6 tunnel server. Teredo isn't used much anymore for various reasons (native IPv6 being deployed being one of them). But when we look at this prefix in IRR explorer, we still see some interesting things:

We see that there are many IRR entries present for this prefix in a number of routing registries, but only two ASN's (AS1101 and AS6939) advertise the prefix at this moment. For AS1101 a IRR record is present in the RIPE database, but for AS6939 there is none. This results in the 'No route objects match DFZ origin' error. The informational message 'no (covering) RPKI ROA found for route objects' is because there is no ROA configured for 2001::/32.

IRR explorer use cases

Now that we've seen some examples of the types of problems IRR explorer can help to spot, let's sum up some of the many use cases for IRR explorer:

1. Improving routability of prefixes. IRR explorer can point out discrepancies between routing registry data, ROA's and routing table entries, and make suggestions how to fix them.
2. Doing housekeeping on routing registry entries. By offering a clear overview of entries in many routing registries (and showing to relevant whois-information) we have an easy way of finding those old database entries we forgot about.
3. Analysing routing issues. Because IRR explorer combines data from so many sources, it's a good starting point for analysing some types of routing issues, for example missing routes in routing tables.
4. Monitoring your prefixes. IRR explorer can provide the data in nicely rendered tables, but also in raw JSON format. Below the tables there's a "source data as JSON" link. For example this link shows the JSON data for the 1.1.1.0/24 prefix we checked as in a previous example.

We hope you'll find IRR explorer a useful tool. The source code for IRR explorer can be found on Github. Suggestions for improvements and new features are welcome!