Free Range Routing (FRRouting or FRR) is an open-source Internet routing protocol suite for Linux and Unix platforms that implements BGP, OSPF, RIP, IS-IS, PIM, LDP, BFD, Babel, PBR, OpenFabric and VRRP, with alpha support for EIGRP and NHRP. It launched in April 2017, when Quagga forked.
I joined the FRRouting organization in late 2018, shortly after FRR 5.0. Since then, we have seen FRR grow from strength to strength thanks to our amazing community of contributors.
Growing FRR
More than 320 authors — around 70 every release — have helped develop FRR (Figure 1).
Until FRR 8.2, we received more than 23,000 commits and 7,000 Pull Requests (PRs) (Figure 2).
Figure 3 shows how many commits and PRs were created per release. The FRR 8.0 release was the largest release since its launch. The purple lines show that over time we have received fewer commits per PRs — we now receive around one commit for one PR. That means we’ve only needed to do small changes and/or bug fixes instead of huge features. This is good because it’s easier for maintainers to review and test the changes.
As per Figure 4, the Merged and Closed PR ratio is positive. Closed in some cases can be a real fix, but also closed if:
- The author does not respond for a long time. PR just becomes abandoned.
- More changes are requested. Working with open-source is hard and challenging. Sometimes it’s very annoying when you have to deal with multiple parties and find the best way to solve the issue, but again, it keeps you challenged and improves your skills.
- A duplicate PR is just going to be closed.
Considering these factors, the percentage of Closed PRs is less than 13%. This is a good indicator and especially looks promising for first-time contributors.
Importantly, the ratio of Created/Closed issues (Figure 5) is close to the point that last year we closed more issues than were created.
More contributors, fewer issues
I encourage people who use FRR to start contributing. Find an interesting open issue in Github, and tinker with it — this is how I started contributing (volunteering) to the project. Four years ago, I didn’t have any experience with programming, but I found something that I was passionate about.
You could even ask your employer if they would be willing to allow you paid time to work on this as part of your professional development.
As for who is contributing, there has been a range of organizations (Figures 6 and 7). Having such diversity helps uncover and address issues.
I feel honoured to work with such great companies behind FRR. You see how huge projects evolve, learn new stuff periodically and can discuss and get help from very smart people.
Being RFC compliant is important
RFC-Compliance is code that follows the formal requirements for the protocols in the TCP/IP stack specified in several RFCs published by the Internet Engineering Task Force (IETF).
Why is it important? People often ask about some specific features in FRR. If this is a minor feature request, we normally implement it in days. With new drafts/RFCs, it’s a bit more complicated, but we try to implement as many features as possible, especially for BGP, which is nowadays a number one protocol not only in provider networks but even in data centres.
In the last couple of years, FRR gained lots of missing drafts/RFCs that are not crucial for BGP to exist, but a real sign to show that we are trying to be the most compliant BGP stack on the market.
Below is the list of drafts/RFCs implemented recently:
- Extended Message Support for BGP (RFC 8654)
- Extended Optional Parameters Length for BGP OPEN Message (RFC 9072)
- Extended BGP Administrative Shutdown Communication (RFC 9003)
- Default External BGP (EBGP) Route Propagation Behaviour without Policies (RFC 8212)
- Codification of AS 0 Processing (RFC 7607)
- Revised Error Handling for BGP UPDATE Messages (RFC 7606)
- Enhanced Route Refresh Capability for BGP-4 (RFC 7313)
- Reservation of Last Autonomous System (AS) Numbers (RFC 7300)
- Making Route Flap Damping Usable (RFC 7196)
- Notification Message Support for BGP Graceful Restart (RFC 8538)
- Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID (RFC 6938)
- Subcodes for BGP Finite State Machine Error (RFC 6608)
- Autonomous-System-Wide Unique BGP Identifier for BGP-4 (RFC 6286)
- Long-lived Graceful-Restart (draft)
- IPv6 FlowSpec (draft)
- Send Hold Timer (draft)
Note, the above is not exhaustive; there are missing BGP RFCs/drafts/tools that are being worked on or would be great to have, including:
- BGP Optimal Route Reflection (RFC 9107)
- There are people already working on this and I believe we will have this feature this year. Working PRs exist but we must have documentation and tests before new features are added.
- Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages (RFC 9234)
- We’ve started work on this and plan on releasing it later this year.
- Link-Local Next Hop Capability for BGP
- To push others to be consistent, we are suggesting creating a new link-local capability for BGP to negotiate and handle next-hops accordingly. This is still under draft, but FRR has already adopted what the draft says and properly handles next-hops with 16 or 32 bytes.
- A comparison matrix for choosing software based on features, compliance:
- Something similar to the one in this series of blog posts about open-source BGP stacks.
What’s new for FRR 8.3?
FRR 8.3 is expected to be released in July 2022 and will include:
- Send Hold Timer for BGP
- Notification Message Support for BGP Graceful Restart (RFC 8538)
- BGP RPKI fixes and librtr >= 0.8.0 is required to work correctly, especially when dealing with connection handling.
- JSON output for all BGP RPKI show commands
- New command for route-maps set as-path replace <any|asn>
- Preparation work on PIMv6
- Support added for protodown
- Several bug fixes as usual
- Critical memory leaks fixed for BGP (Especially when dealing with lots of peers and DFZ)
- Several CLI various improvements
Also, FRR 8.2.3 is about to be released with many bug fixes backported. FRR does not have a long-term support release workflow. Therefore, we recommend using the latest stable version.
You can learn about more interesting, less-known or unknown (for some people) features in my RIPE 84 presentation.
If you find FRR interesting and want to contribute, please feel free to get in touch, especially if you are a first-time contributor and want to know about the flow, best practices, or how the organization works.
Donatas Abraitis is a systems engineer at Hostinger.
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.