IRRPT

Summary

A collection of tools which allow ISPs to easily track, manage, and
utilize IPv4 and IPv6 BGP routing information stored in Internet Routing
Registry (IRR) databases. Some of these tools include automated IRR data
retrieval, update tracking via CVS, e-mail notifications, e-mail based
notification for ISPs who still do human processing of routing information,
and hooks for automatically deploying prefix-lists on routers.

Purpose

Internet Routing Registry (IRR) services have existed in various forms for
some time, yet many ISPs (particularly outside of the European/RIPE
region) have still not adopted it. There are a variety of reasons given,
but some of the most important ones include:

The system is overly complicated, and lacks sufficient examples. End
users can not figure it out, which means another layer of support
structure must be added, or proxy registration must be implemented.
A publicly accessable description of every import and export policy
to every transit, peer, and customer, is difficult to maintain, and
is not in the best business interests of many ISPs.
There are no existing tools which provides registration change
tracking. Without this kind of tracking, there is not enough
accountability for prefix registrations, and router configuration
updates are difficult to manage.

This tool takes a pragmatic approach, by focusing on the key elements and
critical goal of the IRR, in order to provide simple and effective prefix-
list management for the masses. To that end, IRR PowerTools aims to
provide the following functionality:

Automated retrieval of prefixes registered behind an IRR Object.
Automatic exclusion of bogon or other configured undesirable routes.
Tracking and long-term recording of prefix changes through CVS.
Automatic aggregation to optimize data and reduce unnecessary changes.
E-mail updates, letting users know that their change was processed.
E-mail alerts to the ISP, letting them know of new routing changes.
Exporting of change data in e-mail form, for non-IRR using ISPs.
Router config generation, for easy automated config deployment.

While many ISPs still rely on error-prone e-mail and human processing to
handle prefix-lists, a few have developed systems similar to this one in
order to automate their prefix-list management. Unfortunately each of
these systems is proprietary and owned by the respective ISPs, leaving
other networks with a choice between spending money and man-hours writing
duplicating this work, or more often taking the path of least resistance
and simply using e-mails and human processing.
This project aims to provide to every network the same features that
individual ISPs have been developing internally for years. By making it
easier for every ISP to effectively utilize the IRR data, we hope to
increase the popularity of the IRR as a prefix-list management tool, which
will hopefully lead to more accurate data and a more effective system.

Requirements

PHP >= 7.2.0 (http://www.php.net/downloads.php)
CVS Optional (http://www.gnu.org/software/cvs/)
CVSweb Optional (http://people.freebsd.org/~scop/cvsweb/)

Installation

Make sure you have the required packages as listed above installed. Clone
the git respository in your desired install path via:
https://github.com/6connect/irrpt.git
Or, download the zip file and extract.
Run ‘php configure.php’ in the base installation directory.
To get started, you probably want to take a look at every file in
the /conf directory. The most important information to change will be
paths and company-specific information such as the name, ASN, and
e-mail addresses.

irrpt.conf      - This is the master config file which contains global 
                  configuration information, the paths to our internal 
                  locations and external tools, and internal parameters.

irrdb.conf      - This is the second most important config file, 
                  containing a list of the ASNs and IRR Objects you wish
                  to track.

nag.conf        - This file contains the settings for the nag process.

nag.msg         - This file contains the message that will be sent 
                  during the nag process.

exclusions.conf - This file lists routes which can not be registered. A 
                  good example for this file would be known bogon routes,
                  or routes in known unallocated space.

The irrdb.conf file should certain a unique ASN, the IRR object (an
AS-SET or AUT-NUM record) that you are interested in tracking, and a
contact e-mail for change notification. You probably want to track your
own ASN and AS-SET record here as well.
A reasonable deployment would be to crontab the fetch process once or
better yet twice a day. If you need to add a new customer outside of
the normal fetch schedule, or if a customer needs an emergency
prefix-list update, you can add the ASN/IRR Object to irrdb.conf and
run a manual pull of just that ASN, with “./fetch ASN”.
After the updates are processed, you should receive a local copy of the
e-mail. It is probably reasonable to keep a human being in the loop
between prefix fetching and prefix deployment, to make certain that
nothing “bad” or unintended is happening. After you are reasonably
certain that the changes are ready for deployment, you can generate
the router configs use the “pfxgen” tool. Optionally, you can nag
any of your transit providers who still require e-mail updates using
the nag process.
If there is anything else that you can’t figure out, it is probably
either a bug or an oversight in the documentation. Send e-mail about
either one, and I’ll make certain it gets addressed in a future
release.

Documentation

The operation of IRR PowerTools is broken down into the following distinct
operations:

irrpt_fetch

$ bin/irrpt_fetch -h
Usage: bin/irrpt_fetch [-h46qv] [-f file] [--nocvs] [object]

Quiet mode:

$ bin/irrpt_fetch -q 42
...

Verbose mode:

$ bin/irrpt_fetch -v 42
...

irrpt_fetch uses the list of objects provided by irrdb.conf by
default. To track additional objects, simply add them to the
irrdb.conf file. To fetch objects for a specific AS, or specific
object, provide this as an argument per the above example.
This is the stage where you pull data for the objects that you are
tracking off of the IRR, and store them locally. Inside the fetch
process, the following steps are performed:

Query a IRR whois server for prefixes behind the IRR object.
Match prefixes (including more-specifics) against the Exclusions
list, which contains prefixes that can not be registered.
Store the approved prefixes locally.
Run the prefixes through an aggregation tool to optimize them.
Track changes to both the raw and aggregated prefix lists via CVS.
When changes are detected, send out notification e-mails to
customers and optionally a local copy to your operations staff,
alerting everyone that the routing change has been successfully
processed.

irrpt_nag

$ bin/irrpt_nag -h
Usage: bin/irrpt_nag [-hp] [-c config] [-m message] <previous rev> <current rev>

Options:
   -p    Preview mode (for diagnostic use). Print results to screen instead of
         e-mail.

In this stage, any transit providers (or other interested parties)
who still track prefix-list updates via e-mail rather than via IRR
can be notified of the change.
As more providers begin to use IRR, and rely on it as their primary
prefix tracking tool, this should become less and less necessary.
Unfortunately many of the largest ISPs still use human processing of
prefix lists, so for the immediate future you will probably still be
getting a lot of use out…