Free Range Routing

By on 29 Jun 2022

Category: Tech matters

Tags: , , , ,

Blog home

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).

Line graph showing number of authors per release from FRR 2.0.
Figure 1 — The number of contributors over time varies, but on average 70 authors contribute to new releases.

Until FRR 8.2, we received more than 23,000 commits and 7,000 Pull Requests (PRs) (Figure 2).

Line graph showing overall Commits/Pull Requests.
Figure 2 — Overall Commits/Pull Requests. The purple line indicates steady growth — around 1,000 commits and 500 PRs per release.

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.

Line graph showing Commits/Pull Requests per release since FRR 2.0.
Figure 3 — Commits/Pull Requests per release since FRR 2.0.

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.

Pie chart showing the percentage of Pull Requests that have been Open, Merged, Closed or in Draft.
Figure 4 — Percentage of Pull Requests that have been Open, Merged, Closed or in Draft.

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.

Bar chart showing the number of issues created and closed per year.
Figure 5 — Number of issues created and closed (2017-2022).

As for who is contributing, there has been a range of organizations (Figures 6 and 7). Having such diversity helps uncover and address issues.

Pie chart showing the percentage of commits per company.
Figure 6 — Percentage of commits per company since FRR 2.0.

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.

Pie chart showing the percentage of authors per company.
Figure 7 — There are several individuals or small groups of people from organizations (Others) contributing to the community. Lots of individuals contribute to FRR in their free time and are not paid for this work. VMWare and NVIDIA have the most contributors to FRR.

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.

Rate this article

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.

Leave a Reply

Your email address will not be published. Required fields are marked *