Not too long ago, there was effectively only a single solution in the route server vendor market: the BIRD Internet routing daemon.
NIC.CZ (the organization developing BIRD) has done fantastic work on maintaining their BGP-4 implementation, however, it’s not healthy to have virtually every Internet Exchange Point (IXP) depend on a single open source project. The current situation can be compared to the state of the DNS root nameservers back in 2002 — their dependence on the BIND nameserver daemon and the resulting development of NSD as an alternative by NLnet, in cooperation with the RIPE NCC.
OpenBGPD used to be one of the most popular route server implementations until the early 2010s. OpenBGPD’s main problem was that its performance couldn’t keep up with the Internet’s growth, so it lost market share. An analysis by Job Snijders suggested that a modernized OpenBGPD distribution would be a most viable option to regain diversity on the route server level.
Missing features in OpenBGPD
The following main missing features were identified in OpenBGPD:
Performance
In previous versions of OpenBGPD, the filtering performance didn’t allow proper filtering of all EBGP sessions. Current best practice at IXP route servers is to carefully evaluate and validate all routes learned from EBGP peers.
The OpenBGPD ruleset required to do correct filtering (in many deployment scenarios) was simply too lengthy — and negatively impacted service performance during configuration reloads. While filtering performance is the biggest bottleneck, general improvements to the Routing Information Base were also made to improve scalability.
IXP route servers with a few hundred peering sessions are commonplace and adding new sessions shouldn’t impact the route servers’ service to other peers. We found that performance was the most pressing issue that needed to be tackled.
Lack of RPKI origin validation
As we’ve seen, more and more Internet operators are moving to adopt RPKI-based BGP origin validation. While it was theoretically possible to emulate RFC 6811-style origin validation in previous versions of OpenBGPD, the required configuration wasn’t optimized for performance and wasn’t user-friendly.
We believe that BGP origin validation should be as easy as possible — this requires BGP-4 vendors to implement native, optimized routines for origin validation. Of course, enabling origin validation shouldn’t have an impact on performance either when processing BGP updates or when updating the Route Origin Authorization (ROA) table itself.
Portability
OpenBGPD is an integral part of OpenBSD, but IXPs may prefer to run their services infrastructure on an operating system of their choice. Making sure that there’s a portable OpenBGPD version that follows the OpenBSD project release cycle will give IXPs this option.
Development steps
By addressing the issues mentioned above, we could bring back OpenBGPD as a viable route server implementation.
Since I was one of the core OpenBGPD developers, I was asked if I wanted to pick up this project again. Thanks to funding from the RIPE NCC Project Fund, this was possible.
Starting in June 2018, I’ve worked full time on this important community project and have addressed many of the previously mentioned problems. So far, 154 commits were made to OpenBGPD during the 6.4 development — around 8% of all commits ever to OpenBGPD! This shows that due to funding and dedicated resources, a lot of work could be pushed into the latest release of OpenBGPD.
OpenBGPD 6.4
The OpenBGPD version, as part of OpenBSD 6.4 release, demonstrates great progress. Even though there have been many changes to the core of OpenBGPD, the released version is as solid and reliable as previous releases. The many bug fixes and improvements make this the best OpenBGPD release so far.
The changes in the filter language allow users to write more efficient rulesets while the introduction of RPKI origination validation fixes an important missing feature.
For IXPs, OpenBGPD now is an alternative again. There are still open issues, but the gap is closing!
Feature highlights
The following changes should be highlighted:
- Introduction of background soft-reconfiguration on config reload
Running the soft-reconfiguration task in the background allows for new updates and withdraws to be processed at the same time. This improves convergence time — one of the key metrics for route servers.
- BGP origin validation when a roa-set is configured
Every EBGP route announcement is validated against the locally configured VRP table entries. Depending on the validation process’s outcome, the validation state is set to valid, invalid or not found. The filter language has been extended to allow checking for the origin validation state, and thanks to this, it is possible to deny invalid prefixes or regard valid prefixes different to the ones that aren’t found. The roa-set table is read from the configuration file and updated during configuration reloads. On production systems, reloading the roa-set and applying it to all prefixes is done in a couple of seconds.
- Fast prefix-set lookups
In OpenBSD 6.3, prefix-sets got introduced in OpenBGPD. A prefix-set combines many prefix lookups into a single filter rule. The original implementation wasn’t optimized but now a fast lookup is used. Thanks to this, large IRR DB prefix tables can now be implemented efficiently.
- Introduction of as-sets
Similar to prefix-sets, as-sets help group many AS numbers into a single lookup. Thanks to this, large IRR DB origin AS tables can be implemented efficiently.
- Introduction of origin-sets
Looking at the configurations of route servers doing full filtering, it was noticed that a common lookup was binding a prefix to an origin AS — similar to how a roa-set is used for RPKI. These origin-set tables are used to extend the IRR prefix lookup and generated from alternative sources.
Improving third-party tools
Users can only benefit from the changes introduced in OpenBGPD 6.4 when the surrounding third party tools are adjusted accordingly. Two open source projects such as bgpq3 and arouteserver are frequently used by network operators and IXPs to generate BGP configurations. Thanks to our contributions to those projects, we were able to get them ready for all the new features in OpenBGPD.
- bgpq3 was extended to create as-set and prefix-set tables based on IRR DB entries. This is replacing the old way of doing the same with a large number of filter rules. Thanks to the quick response from the bgpq3 maintainer, it was possible to ship OpenBSD 6.4 with a bgpq3 package that includes all the new features.
- arouteserver was adjusted to implement RPKI roa-set, as-set, prefix-set, and origin-set to generate a much better-performing configuration for the 6.4 version. With the v0.20.0 release of arouteserver, IXPs are able to generate an OpenBGPD configuration that is a lot faster but also implements new functionalities. Looking at YYCIX (the resident IXP in Calgary, Canada) the ruleset generated by arouteserver was reduced from 370,000 rules too well under 6,000 rules. This resulted in the initial convergence time dropping from over 1 hour to less than 2 minutes, and subsequent configuration reloads are hitless and no longer noticeable.
Read: IXP automation made easy with new open-source tool
What still needs to be done
A sizeable chunk of work is still left to do, including the rework of the RIB data structures in OpenBGPD — these haven’t been changed since the initial design of OpenBGPD in 2003. There’s currently ongoing work (in small steps, to avoid jeopardizing the stability of OpenBGPD) to modernize these data-structures. The goal is to provide better decoupling of the filter step from storing RIB database changes, to pave the way to multi-threaded operations at a later point.
Looking forward
Job Snijders, who oversaw this year’s fundraising and project management, adds:
It’s been incredibly productive to create an environment where a core developer is allowed to work full time on the OpenBGPD code base. However, it’s important to note there’s still room for a number of new features to help improve its operational capabilities (such as BMP, RFC 7313, ADD_PATH, etc). It’d be beneficial to the Internet community at large if we can extend Claudio Jeker’s involvement for another year. Open source software doesn’t grow on trees! Strategic investments are the only way to keep OpenBGPD’s roadmap aligned with Internet growth and operator requirements.
Contributors: Job Snijders
Adapted from original post which appeared on RIPE Labs Blog.
Claudio Jeker is a long time OpenBSD developer doing mostly crazy networking stuff.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.