Affordability and security are two essential components of establishing and managing any Internet Exchange Point (IXP).
As we’ve already seen, setting up an IXP can cost as little as 1,000 USD and requires only a small amount of space in a pre-existing data centre.
Recently, automation has also become a desired component, allowing several people to configure an IXP externally. ARouteServer is an IXP automation project that I’ve been working on lately.
The thinking behind this (too?) ambitious project is to provide automatic, as-secure-as-possible and feature-rich route server configurations that could be used in production environments, possibly based on community-driven best practices and generated by an open-source software everyone can contribute to.
How does ARouteServer work?
The project started as an OSS, with a goal to build such configurations starting from some syntax-agnostic high-level policies and clients definitions, which are automatically converted into BGP-speaker-specific configuration files.
Two YAML files are used to configure general options and client parameters. These files are then processed by the tool, which also gathers additional information from external sources, for example, IRRDBs, PeeringDB and Euro-IX JSON files, and finally builds the route server’s configuration file.
Most of the recommendations reported in RFC7947 and RFC7948 have been taken into account and converted into options that can be configured both in the general policies file and on a client-by-client basis:
- NEXT_HOP enforcing allows users to prevent traffic diversion and can be optionally configured to direct traffic through any IP address among those of the announcing AS
- Prefix leakage mitigation is obtained both through inbound prefix limits (that can be set on a client basis or automatically fetched from PeeringDB records) and through filters based on information from the Internet Routing Registry databases
- path-hiding mitigation techniques and ADD-PATH support allow you to avoid routes to be masked out by announcement control policies.
Moreover, other hygiene best practices can be configured to strengthen the trust that operators can put in the route server intelligence:
- RPKI-based filtering or routes tagging (à la draft-ietf-sidrops-route-server-rpki-light)
- AS_PATH sanitation (checks on leftmost ASN, excessive length, invalid ASNs, “transit-free” ASNs)
- bogons filters and prefix length checks.
In addition to route filtering, the tool also includes useful features to control route propagation to other route server clients (prepend to/do (not) announce to – any/specific peers) and blackhole filtering support. All these features are exposed to clients via BGP communities (standard/RFC1997, extended and large).
Integrate with other systems is easy
To ease integration with other systems (like the popular IXP-Manager, which also includes a route server configuration tool), ARouteServer can build the list of its clients on the basis of already existing Euro-IX JSON members lists, by fetching IP addresses, AS-SET macros and max-prefix limits, and converting them into its local format.
In order to have a working implementation, ARouteServer currently focuses only on BIRD, however there are plans to feature support for other BGP speakers. A comprehensive list of features and more details can be found on the website.
The project is in a beta status and it’s actively looking for testers and reviewers: some live testing scenarios have been created to validate configurations built using the tool, but feedback from real life is strongly needed and encouraged!
Email me if you’d like to know more about the project or would like to test the tool and share your experience.
This article was originially published on the APNIC blog.