Integration with ALTDB & RADB

[anuragbhatia]

(Feature request)

Please consider integration with ALTDB as well as RADB for mantaining the AS SET of the IX route servers.

Workflow:

1. Arouteserver is provided with route server's AS SET. E.g: AS137251:AS-Peers as well as details like IRR which is being used.

2. When a new peer is added to clients.yml and config is generated, arouteserver also updates the AS SET.

This would provide the basis for various networks peer at the RS to generate the filtering config for the routes learnt via RS.

[pierky]

Hello @anuragbhatia, thanks for your message here.

Even though I totally see the benefits of this feature in an IX management environment, I believe it is out of scope with regards to the ultimate goal of ARouteServer, which is building route servers configurations.

I thought it could be good to create a side tool within the tools directory of the project. A set of plugins could be created to implement the various "northbound interfaces" needed to publish data into the various IRRs.

What do you think?

Just to set the right expectations, this would not be my top priority at the moment, but of course something that I'd like to create.

[anuragbhatia]

That sounds like a good idea!

[pierky]

Hello @anuragbhatia, I've started looking into this.

I've pushed some new commits to the dev branch, you can find a quick summary on how I'm approaching it here: https://arouteserver.readthedocs.io/en/dev/USAGE.html#generation-of-route-server-as-set-rpsl-object (it's the dev version of the docs site).

At the moment there's a new command that builds a RPSL AS-SET object with the ASes and AS-SETs of the route server clients; it just dumps the content to a file, it does not interact with upstream IRR DB providers. I'm inclined towards not implementing upstream interfaces at the moment, but to keep it simple for the time being. There are lots of potential IRR DB providers that users might be interested into, and most likely (I haven't fully analysed all of them) it would require lot of time and effort to implement their APIs or other ways to sync automatically, and to stay on top of them when they are updated. I still see the benefits of such a tool, although I'm not really sure it would be in scope for ARouteServer, and the effort required is not insignificant.

Are you aware of any middle-ware libraries/programs/scripts that can be fed with a RPSL objects and do the rest of the job? Ideally it should be something that abstracts the different mechanisms offered by IRR DB providers to deal with their data sources.

A CI pipeline is now running (see it on TravisCI); once it will complete, release v1.3.0-alpha1 will be out on PyPi-test; in case you wanna play with it, you can install it using the following instructions: https://arouteserver.readthedocs.io/en/dev/INSTALLATION.html#development-and-pre-release-versions

EDIT the pipeline failed, but it seems it's due to a Docker-hub rate limiter kicking in; I've manually uploaded arouteserver-1.3.0a1.tar.gz to the PyPi test instance, so it can be installed using the instruction above.

[dorkmatt]

@pierky rumor is ARIN will offer a modern (non-SMTP) API for IRR at some future date, at least in RIPE land this could be automated I assume?

[pierky]

@pierky rumor is ARIN will offer a modern (non-SMTP) API for IRR at some future date, at least in RIPE land this could be automated I assume?

Hello Matt,

thanks for the feedback.

At the moment I plan on not adding automatic IRR object uploading feature to ARouteServer, but rather to release this feature as it is right now (I did few changes that I'll explain in a bit), that is as a way to build the AS-SET object and dump it to a local file. The reason is that there are many IRR systems, each one with a different ingestion mechanism (APIs with different implementations between RIPE and RADB, email, web-based portals). Even to reach a reasonable coverage only of the most used ones would introduce a substantial cost to the project in terms of implementation effort and maintenance (the tool is already quite intensive in terms of external dependencies, for its own nature of course).

Not saying that I don't see the value of such a feature, nor that it will not be implemented in the future, I just prefer to start shipping what's ready and keep an eye on it. I believe that in the shape it's right now it would already provide value and help operators to track changes in their route servers AS-SETs, and make it a lot easier to deal with those changes.

As I've mentioned, a pipeline for v1.3.0-alpha2 is running and eventually a pre-release will be published (see https://arouteserver.readthedocs.io/en/dev/INSTALLATION.html#development-and-pre-release-versions). The dev version of the docs site already reflects how I changed it. Basically, there are now 2 templates that can be used to generate the output AS-SET, one of them is in a format that can be consumed by ripeinator, a tool that is able to implement the RIPE REST API for IRR. This is already something that could be used for RIPE-land in a automated way, with a wrapper that could execute ARouteServer to build the object and ripeinator to push it.

I'm not aware of other tools that do the same, I'll be glad to work on extending the templates should other software interfaces exist for more IRRs.

Hope this makes sense.

[pierky]

1.3.0 is out, which includes what described above. Going to close this issue. I'll think if/how to implement "upstream" interaction with IRR providers.