The technology behind the route server configurator 

diego.pngDiego Luis Neto is senior software engineer at NL-ix with a background in network security and specialized in data modelling, database design and systems integration. At the moment he is extremely busy designing and implementing the NL-ix automation platform.

Internet exchanges facilitate peering (the exchange of traffic) between organizations. A well-known tool for this is the route server. Unfortunately, at the moment, this approach comes with a few limitations that are not encouraging organizations to join route servers: there is no possibility to easily decide who to peer or who not to and the management of the route servers is usually something obscure, not standardized and still performed in a really manual way, that means inefficient, error prone and time consuming.

On top of it, at NL-ix due to the distributed European Network, also latency becomes a key factor in the selection of your peers and the filter mechanism based on community strings, once again, turns out to be limited. 

NL-ix decided to find a solution to the above-mentioned situation and implemented the route server configurator: a completely automated system - built on top of the open-source route server BIRD - that gives to the members full and fine-grained control on their peering sessions via a friendly web interface.

In the web interface the user selects peers based on a chosen maximum latency; he can select or deselect certain locations and further refine whom he wants to peer from the full list of the available peering members. To apply his selection the user just pushes a button, the route server configuration is automatically generated, deployed and immediately active.

 Behind the scenes, the web interface sends the data to a Django application that exposes REST API, this application stores the data and sends them to our automation orchestrator, Stackstorm,  for which we developed our own automation packs; using these packs Stackstorm is able to generate BIRD configuration files (IPv4 and IPv6) and send them to the BIRD route server to be deployed.

The transfer of the files on the route server is also performed via HTTP: to allow this HTTP communication with BIRD we developed a Flask application, called bird-proxy, running directly on the route server machine. Once the configuration file is transferred, bird-proxy performs all the required validation checks using the standard BIRD tools and applies the configuration without any risk for the stability of the route server; if there is any problem in the file or in the configuration the deployment is aborted and a notification is immediately sent to our network engineers.

The modular design based on communication via API enables network engineers to check and intervene at each step of the configuration chain. The usage of Stackstorm also allows the route server configurator to be integrated with the rest of the NL-ix automation platform and the other tools used within the organization such as Slack, on which we receive friendly notifications about everything has been automatically performed.

To my knowledge the route server configurator is the first fully automated system that at the same time offers such a highly flexible selection mechanism. This will definitely help the acceptance of the route server by organizations. We hope to contribute improving the functionality and acceptance of route servers