Hunting Routing Resources around the World

Following the progressive exhaustion of IPv4 address space, we observed a parallel growth in commercial trading of available IPv4 addresses which led to a global redistribution of address blocks from their original “birthplace”. Such is the case of address blocks that had been originally allocated by a given Regional Internet Registry (RIR) – say ARIN, for example – but were then sold to a company that started to use and announce them in a completely different region – say RIPE.

While this is perfectly fine and legitimate, it sometimes poses an additional burden on those subjects, namely Internet Exchange Points, that rely on information stored into Internet Routing Registries (IRR) to automatically generate BGP input filters for installations such as their Route Server (RS) infrastructure.

Back in the old times, IXPs use to rely on their reference RIR to find out all registered resources (route/route6 objects) belonging to an IXP participant. So it was for Namex, which mostly relied on the RIPE registry to properly generate filtering rules for its own IXP participants. Things began to change when international companies such as content providers and OTTs started joining the exchange, they could sometimes announce prefixes that were originally registered in their own country’s regional registry. With the more and more widespread use of traded addresses blocks, things are getting really messy …

Routing resources management in the contemporary era

Tracking routing resources is fundamental to the proper generation of BGP filters in Route Server infrastructures: in general, any IXP participant communicates its own Autonomous System Number (ASN) and an optional AS-SET containing all the ASNs for customers that the participant wants to announce over the IXP.

Starting from this <ASN, AS-SET> tuple, a filters’ generation framework starts to query one or more IRRs to retrieve all ROUTE and ROUTE6 objects which have an origin in one of the Autonomous Systems which result from the expansion of the <ASN, AS-SET> tuple.

Thus, knowing which IRR sources to query is essential for proper filter generations. In recent times we observed several situations which lead to incomplete filters’ generations, and thus potentially impact the amount of traffic exchanged over the IXP platform, such as:

• Resources registered into IRRs not related to the geographical region (such as ARIN or APNIC)
• Resources registered into commercial IRRs (such as RADB or NTTCOM)
• ASNs resulting from an AS-SET expansion for which there exist resources registered into completely different registries (i.e.: the AS-SET is registered in one registry, originated route objects registered into another registry)

In order to generate an input filter list for an IXP participant, tools like IXP Manager require the association of each participant with a corresponding IRR entry, which is made of:

• A whois server, which is optionally capable of performing recursive queries to other whois servers
• A list of sources in which to look for routing resources (the server may be authoritative for those sources or either be able to recursively forward queries to authoritative servers for those sources)

Given the above-mentioned scenarios, choosing the right IRR source list for each IXP participant is becoming a challenging task, that’s where our IRRHound tool comes to the rescue.

Hunting routing resources with IRRHound

We developed a simple Python package, named IRRHound, with the aim of helping in tracking routing resources across multiple IRR sources.

The package provides a library of functions and some example tools to perform extensive research for a given AS registered resources, research strategy is accomplished as follows:

• Given an input AS number and related AS-SET (both v4/v6 if needed) a recursive research is performed against whois.radb.net whois server by means of the bgpq3 tool, in order to retrieve the full list of main AS and customers’ASes.
• For each AS, related ROUTE objects are retrieved across all available registries
• In case multiple ROUTE objects are registered for the same prefix in different registries, a selection process favours objects in most accessed registries (in order to reduce the number of registries one needs to query)
• Information about duplicate ROUTE objects is kept with the main object selected

Package functions

Package irrhound.irrhound delivers two functions:

• irr_hunt_sources(asn,asmacro,asmacro6): returns a minimal set of sources containing resources (ROUTE objects) for the given AS number and related v4/v6 customers’ AS-SETs. Return value is a dict with the following structure: { 'sources': [list] }
• irr_hunt_routes(asn,asmacro,asmacro6): returns a complete set of ROUTE objects for the given AS number and v4/v6 customers’ AS-SETs. Each ROUTE object descriptor can carry additional duplicates from different regisitries. Return value is a dict with the following structure: { 'routes': [ { 'cidr': network, 'origin': ASN, 'source': IRR source, 'duplicates': [list of routes in dict format] }

Example tools

In the tools/ directory you will find some useful tools to deal with IRR resources:

• suggest_irr_sources.py: check for IRR sources that contain objects about a network operator, identified by its own Autonomous System and (optional) AS-SET
• retrieve_irr_resources.py: retrieve route objects from an IRR source for given AS number and AS-SET.

Final remarks

The package require a working instance of bgpq4 and the additional Python ipwhois package. We hope that the IRR source suggestion tool can help in fine-tuning IRR sources in IXP Manager and help to produce more accurate Route Servers input filters.

You can clone the source code from Github repository, feel free to try and test it: the code is still in its early stages and may contain bugs or produce yet incomplete results, any feedback or suggestions based on your experience is appreciated.