Emil Palm
Netnod IX

Netnod’s new route server platform

Netnod will launch a new route server platform at the Netnod IX Stockholm and Copenhagen by the end of H1 2019. The new platform will have some significant new features including a looking glass, support for RPKI and all standard BGP communities enabled. In this post, we look at the new features, what customers should do to prepare and the technology used on the new platform.


New features

The new platform will support all standard communities and, from day one, will be running Resource Public Key Infrastructure (RPKI). Adding RPKI on the route server has some important consequences. Firstly, it helps to ensure secure routing and prevent BGP hijacking. But, secondly, it means that customers need to make some important preparations to make sure their routes don’t get dropped. The new platform will provide a looking glass to help investigate possible route discrepancies but also to help new customers validate their setup. This will make it much easier to search for an AS number, peer or a specific IP prefix.

What do customers need to do?

Customers connecting to the Netnod route servers at the IXes in Stockholm or Copenhagen should ensure they have signed their prefixes with RPKI and that their AS-SETs are up-to-date. This is important because by the end of H1 2019, once RPKI is deployed on Netnod’s route servers, they will by default reject Route Origin Authorisations (ROAs) marked as ‘INVALID’. ROAs marked as ‘VALID’ will be accepted, while those marked as ‘UNKNOWN' will be checked in the customer AS-SET. If the prefix is present there, it will be accepted, otherwise it will be rejected by the route server. So if you want your routes to keep being accepted on the route server, please make sure your ROAs and AS-SETs are up to date!

RPKI and Communities

We will tag all incoming prefixes with the RPKI validation results using BGP communities. This means that  an INVALID route will be dropped. But, an ACCEPTED or UNKNOWN route will be tagged with a specific BGP community so that the receiving side can use standard BGP manipulation tools to alter the likelihood of whether that route is selected for BESTPATH in their network. In the case of “UNKNOWN” routes, you can drop these prefixes simply by matching the community sent by the route server. This, in turn, will promote the use of RPKI by more users and will also limit the possibility of BGP hijacking over the route servers.

More information about RPKI

If you want to get started with RPKI you can find more resources on the subject in the following links:







Technical background

So how did we move from our previous route server setup to the new version with all the features listed above? There were some important considerations, not least the need to abstract the implementation of the new platform from our actual customer data. For this we picked Arouteserver, which has the added benefits of a simple, shared codebase used by many others in the industry as well as high quality documentation and good interoperability with our dual-vendor solution (Bird and GoBGP).  Since it is based on collaboration between multiple players, Arouteserver gives us good scalability for future debugging and adding features.

If you want all the juicy technical details ( what we had to do to incorporate communities and RPKI in the looking glass, how we moved to a dual vendor solution, how we avoided duplicating customer information in multiple locations), you can see my talk from DKNog in March 2019 at: https://www.youtube.com/watch?v=zwbF8vR_8Ok

Next steps

During April-May 2019, we will be conducting friendly user tests of the new route server platform at Netnod IX Copenhagen. If you are present there and want to help us test GoBGP and RPKI stuff out, just shoot me an email at: emil[at]netnod[dot]se


After we have finished testing, we will start migrating the route servers at the Netnod IX Copenhagen, with the Netnod IX Stockholm to follow by the end of H1 2019.