FRRouting (FRR): a multi-protocol routing suite for Linux and BSD

What FRR is and which operators it targets

FRR is free software that implements and manages various IPv4 and IPv6 routing protocols. It runs on nearly all distributions of Linux and BSD and supports all modern CPU architectures, according to the README. The project website is frrouting.org.

The protocol list is long: BGP, OSPFv2, OSPFv3, RIPv1, RIPv2, RIPng, IS-IS, PIM (SM, DM, SSM, MSDP), LDP, BFD, Babel, PBR, OpenFabric, VRRP, plus EIGRP and NHRP, which the README marks as alpha. That list tells you who this is for. It is for network engineers and platform teams who want routing protocols running as software on a general-purpose Linux or BSD host, rather than on a vendor appliance. Typical fits are lab topologies, virtual routers in a hypervisor or container, route servers, and hosts that need to speak BGP to a fabric.

The README does not claim a performance envelope, a supported throughput figure, or a hardware compatibility list beyond CPU architecture and operating system. Anyone choosing FRR for a high-rate peering role should treat that silence as something to resolve with their own testing, not as a guarantee.

One daemon per protocol: the zebra and vtysh model

The repository layout makes the architecture visible. Top-level directories include bgpd, ospfd, ospf6d, isisd, ripd, ripngd, pimd, ldpd, bfdd, babeld, eigrpd, nhrpd, pbrd, vrrpd, staticd, pathd and sharpd, alongside zebra, vtysh, watchfrr, lib, mgmtd and yang. Each protocol daemon is its own process. Zebra sits underneath as the component that owns the kernel routing table and the interface state, and the protocol daemons hand their selected routes to it. Vtysh is the integrated command-line shell that lets you configure the daemons from one prompt instead of attaching to each process separately.

That split has consequences worth naming. A crash in a single protocol daemon does not take the others with it, and watchfrr exists to notice and restart daemons. The cost is operational: you are managing a set of processes, not one binary, so startup ordering, per-daemon configuration files and log destinations all matter. The README points to the user guide for use instructions, and the repository keeps configuration and YANG models in the yang/ directory, which is where the mgmtd work described next draws its schemas from.

The README also flags a migration in progress. The mgmtd daemon applies YANG configuration to the routing protocol daemons through the northbound API, instead of each daemon only having its own legacy configuration path. The README states plainly that not all daemons are migrated yet and that ongoing changes should be expected. If you are writing automation against FRR configuration, that sentence is the one to weigh: a legacy per-daemon path and a YANG-modelled path can coexist in the same release, and which one a given daemon uses depends on migration state.

Installing FRR on Ubuntu and Debian from the APT packages

The README gives two packaged routes and one source route. Pre-built packages are available via APT for Debian and derivatives at deb.frrouting.org, and via RPM for RHEL, Fedora and related distributions at rpm.frrouting.org. Instructions for building and installing from source for supported platforms are in the developer docs, and source tarballs are on the releases page.

The README does not print the exact apt commands or the repository signing steps, so the block below is limited to what the README states: the package source host and the resulting package name. Add the deb.frrouting.org repository to your sources following that site's own instructions, then install:

apt update
apt install frr

After installation, the README says to refer to the user guide at docs.frrouting.org for instructions on use. That is where the per-daemon configuration and the vtysh commands live; the README itself does not reproduce them. What you should expect from the repository layout is a set of daemons rather than a single service, with zebra as the component that talks to the kernel and vtysh as the shell you configure them through.

For source builds, the README points at the developer docs page on building, and the repository carries bootstrap.sh and configure.ac at the top level, which is consistent with an autotools build. The README does not document the configure flags, so take them from the developer docs rather than guessing.

One more installation note from the repository root: there are packaging directories for debian, redhat, alpine, pkgsrc, snapcraft and docker, and a docker/ directory. The README does not describe a supported container image or its usage, so treat the docker directory as a packaging artifact rather than a documented deployment path.

Where FRR is the wrong tool

The README's own caveats are the honest starting point. Not every protocol or feature is available on every platform, and it directs readers to the feature matrix in the user guide. That means a protocol appearing in the supported list is not the same as that protocol working on your operating system. Check the matrix before designing around a protocol.

Two protocols carry an explicit maturity warning: EIGRP and NHRP are labelled alpha. Alpha in a routing daemon is not a stylistic label. If your design depends on EIGRP or NHRP, the README is telling you the implementation is not at the same level as BGP, OSPF or IS-IS.

The mgmtd migration is the second soft spot. Because the README says not all daemons are migrated and that changes are ongoing, an automation workflow built on the YANG northbound path can hit a daemon that still only has its legacy configuration path. If your requirement is a single uniform configuration interface across every protocol, FRR as documented does not yet offer that.

Finally, consider what FRR is not. It is a routing protocol suite, not a full network operating system with a management plane, a hardware data plane, or a vendor support contract. Teams that need a supported appliance with a single vendor accountable for the whole stack are looking at a different class of product, and the README does not present FRR as a replacement for one.

FRR compared with Quagga, its predecessor

The natural comparison is Quagga, the project FRR forked from. The architectural idea is shared: a zebra process that owns the kernel routing table, a set of protocol daemons above it, and a shell for configuration. Anyone who has run Quagga will recognise the shape of an FRR deployment.

The difference that the README documents is direction, not heritage. FRR's stated protocol list includes Babel, OpenFabric, PBR, VRRP, EIGRP and NHRP alongside the classic BGP, OSPF, IS-IS and RIP set, and it describes an ongoing move toward centralised configuration through mgmtd and the northbound YANG API. That migration is the clearest architectural divergence: FRR is working toward one daemon applying YANG configuration to the others, while the legacy model of each daemon owning its own configuration path still exists alongside it. A Quagga-style deployment assumes the legacy model throughout.

The practical difference for an operator is therefore about what you can automate and which protocols you can run, not about the process topology you will learn. If you are already comfortable with the zebra-plus-daemons layout, the FRR learning curve is mostly the protocol set and the mgmtd question.

Releases, maintenance and the licence question

The repository is not archived, and the last push was on 2026-09-23. Three releases were published on 2026-08-31: frr-10.6.2, frr-10.5.5 and frr-10.4.5. Those three version lines receiving releases on the same day is the concrete signal about upgrade cost: FRR appears to maintain several stable branches in parallel, so an operator on 10.4 or 10.5 has a maintained line to stay on rather than being forced onto the newest major version.

The README does not document an upgrade procedure, a rollback path, or a configuration compatibility guarantee between versions. Nothing in the README says whether configuration carries forward across a major upgrade. That gap is the main thing to resolve before planning a fleet-wide upgrade, and the release notes for each version are the place to look rather than assuming.

On licensing, the README is careful and so should you be. Per-file licences use SPDX identifiers; see COPYING and doc/licenses/. The combined work is generally understood to be distributable under GNU General Public License version 2 or later (GPLv2+), with COPYING holding the details. FRR's documentation uses a separate custom permissive licence, also described in COPYING. The repository metadata reports the licence as NOASSERTION, which is consistent with a per-file SPDX scheme rather than one top-level identifier. If you are embedding FRR in a product, read COPYING and doc/licenses/ and get your own advice; the README states the situation but does not resolve it for your use case.

Community, reporting and where to get help

Support runs through mailing lists rather than a single issue tracker. The README lists [email protected] for development, [email protected] for users and operators, and [email protected] for announcements, with subscription and archives at lists.frrouting.org. For chat, the project uses Slack at frrouting.slack.com, and the README says new members can join via the invite link on the community page at frrouting.org/community/.

Security reports have a dedicated channel: the security mailing list at security [at] lists.frrouting.org. That is the address the README gives, and it is the one to use rather than a public list or a chat channel.

For contributors, the README points at the developer docs for submitting patches and enhancements and for commit guidelines, and notes that the project maintains developer documentation with the full workflow and contributor expectations, plus technical documentation on internals. The repository also carries a .github/ directory and a github-ci workflow badge in the README, so continuous integration runs on GitHub even though discussion happens on the lists.

Editorial conclusion

Adopt FRR when you need a routing protocol stack on a Linux or BSD host and you are prepared to read the user guide and the feature matrix for your platform. Do not adopt it expecting every protocol on every platform: the README states that not every protocol or feature is available everywhere, and EIGRP and NHRP are marked alpha. Before deploying, check the feature matrix entry for your protocol and platform, and confirm whether the daemon you need is among those already migrated to mgmtd, since the README says not all daemons have been migrated yet.

Frequently asked questions

Official sources

1. FRRouting/frr on GitHub
2. Issues
3. Project website
4. README
5. Releases