At the NLNOG Day 2021 event last year, the Netherlands Network Operator Group (NLNOG) announced the release of a new version of IRR explorer. IRR explorer is software you can run as well as a service hosted by NLNOG. This article will explore 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, Autonomous System Numbers (ASNs), 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 emphasize 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 address, a prefix, an ASN, or an 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
In the table shown in Figure 1, you can see 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 Authorization (ROA) is present, or a route is found in the default-free zone (DFZ). The table shows several 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 ASes originate this prefix, according to the NLNOG Ring Looking Glass. 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 ROAs 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 have 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 some entries need investigation.
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 that links the prefix to AS12654 (shown in the ‘RIPE‘ column), which conflicts with the ROA shown in the ‘RPKI‘ table. This 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 188.8.131.52/24, which contains 184.108.40.206 (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 220.127.116.11/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 18.104.22.168/32 and one for 22.214.171.124/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 126.96.36.199/32 in this example. For both prefixes, IRR explorer shows an error, a warning, and an informational message.
The error is that an RPKI-invalid route object was found, which is of course because there’s only a ROA for 188.8.131.52/24 with a maximum prefix length of a /24 and origin AS13335, and 184.108.40.206/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 ASNs (AS1101 and AS6939) advertise the prefix at this moment. For AS1101 an 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:
- Improving routability of prefixes. IRR explorer can point out discrepancies between routing registry data, ROAs, and routing table entries, and make suggestions on how to fix them.
- Doing housekeeping on routing registry entries. By offering a clear overview of entries in many routing registries (and showing the relevant whois information) we have an easy way of finding those old database entries we forgot about.
- 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.
- 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 220.127.116.11/24 prefix we checked as in a previous example.
We hope you’ll find IRR explorer a useful tool. IRR explorer is open source and can be found on Github. Development and maintenance was made possible with generous donations by the RIPE NCC Community Projects Fund and the Internet Society (ISOC). Suggestions for improvements and new features are welcome!
Teun Vink is a board member for NLNOG, the Dutch Network Operator Group. In his day job he’s responsible for the network at BIT, a Dutch ISP and data centre.
Adapted from the original post at RIPE Labs.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.