FRRouting (FRR)
An open-source IP routing suite for Linux and BSD: BGP, OSPF, IS-IS, PIM, BFD and other protocols as separate daemons that install routes into the kernel, used in switch operating systems, routers and Kubernetes clusters.
Linux Foundation project- What it is
- Software-defined networking
- Type
- Open source
- Made by
- FRRouting project (Linux Foundation), forked from Quagga
- Foundation
- The Linux Foundation, joined April 2017
- License
- GPL-2.0-or-later (most of the code; some files under other open-source licences)
- Facts checked
- 28 October 2026
What it is
FRR is the control plane of a router, as software. It exchanges routing information with neighbours, decides the best paths and tells the forwarding layer about them; it does not forward packets itself. Each protocol runs in its own daemon: bgpd for BGP, ospfd and ospf6d for OSPFv2 and OSPFv3, isisd, ripd and ripngd, pimd for multicast, ldpd for MPLS label distribution, bfdd for fast failure detection, and others for Babel, VRRP, policy-based routing, OpenFabric, and EIGRP and NHRP in alpha. They all talk to zebra, which collects their routes, picks the winners and installs them into the kernel’s routing table, or into a remote dataplane through a plugin. A crash in one protocol daemon generally leaves the others running.
Operators manage it through vtysh, a single shell with a Cisco-like command line that talks to every daemon and can keep the whole configuration in one frr.conf. A newer management daemon, mgmtd, applies configuration described in YANG models through a northbound API, though not every daemon has moved to it yet. FRR runs on nearly all Linux distributions and on FreeBSD, NetBSD and OpenBSD, from a Raspberry Pi with a few static routes to a server carrying full Internet routing tables.
Because it is open and runs on Linux, FRR is the routing stack inside many other systems: SONiC runs it in its BGP container, NVIDIA’s Cumulus Linux grew up with it, and MetalLB, the Kubernetes load balancer for bare-metal clusters, uses FRR through its FRR-K8s backend to announce service addresses over BGP. It started in April 2017 as a fork of Quagga and has been a Linux Foundation project since then. Feature releases come about every four months: 10.7.0 in July 2026, then 10.7.1 on 31 August 2026 alongside fix releases for the 10.4, 10.5 and 10.6 branches.
Why teams pick it
- A full set of routing protocols, BGP, OSPF, IS-IS, PIM, LDP and BFD among them, in one suite with one shell and one configuration file
- Runs on ordinary Linux, so the same routing stack works on switches, servers, VMs and Kubernetes nodes
- Separate daemons per protocol, so a fault in one protocol generally doesn’t take down the others
- Widely embedded: the routing layer of SONiC, Cumulus Linux and MetalLB, with an active multi-vendor community at the Linux Foundation
Watch out for
- Control plane only: forwarding speed depends on the kernel, the NIC or the switch chip that zebra programs
- The move to YANG-based configuration through
mgmtdis still in progress, so automation often still drivesvtyshand text configuration - Fast-moving: a feature release about every four months, and older branches get fixes only for a limited time
- Running BGP at scale, such as full Internet tables, needs memory, CPU and careful tuning; it is no substitute for routing expertise
Alternatives
What all software-defined networking have in common →Compare side by side →
OVN (Open Virtual Network)Open sourceA control plane for virtual networks built on Open vSwitch: you describe logical switches, routers, ACLs, NAT and load balancers, and it programs the OVS on every host to implement them.
SONiCOpen sourceSoftware for Open Networking in the Cloud: a Linux-based network operating system for data centre switches, built by Microsoft for Azure, that runs on hardware from many vendors through a common chip interface.How it fits with other technologies
What FRRouting (FRR) uses
Part of /etc/frr/frr.conf on a leaf switch: BGP unnumbered to two spines, announcing one subnet · text
frr defaults datacenter
hostname leaf1
!
router bgp 65101
bgp router-id 10.0.0.11
neighbor fabric peer-group
neighbor fabric remote-as external
neighbor swp1 interface peer-group fabric
neighbor swp2 interface peer-group fabric
!
address-family ipv4 unicast
network 10.1.1.0/24
exit-address-family
!
# then, from the shell:
# vtysh -c 'show bgp summary'See it in a real stack
No architecture uses FRRouting (FRR) yet. Drop it into the playground and wire it up yourself.Open playground →Where it came from2017–2026
FRR’s roots go back to GNU Zebra, an early open-source routing suite, and to Quagga, the fork that carried it on. Companies building network operating systems on Linux relied on Quagga, but several of its contributors were frustrated with the pace of its development. Cumulus Networks kept its own fork, known as “Cumulus private Quagga”, and other vendors had patches of their own.
In April 2017 the Network Device Education Foundation (NetDEF) and Cumulus Networks started a new fork, FRRouting, with contributors from Orange, 6WIND, Big Switch Networks, Volta Networks and others, and on 3 April 2017, at the Open Networking Summit, it was announced as a Linux Foundation project together with DPDK. NetDEF still runs the project’s CI and provides several maintainers.
FRR has since spread into many Linux-based network systems. It runs in SONiC’s BGP container, and MetalLB made FRR-K8s, a Kubernetes-native wrapper for FRR, its default BGP backend. The project keeps adding protocols and features, works on YANG-based management, and shipped 10.7 in July 2026.
Why it’s built this way
- One daemon per protocol, coordinated by zebra
- Separating protocols into processes contains crashes and exploits to one protocol and makes it easier to add new ones, while zebra alone deals with the platform’s forwarding layer.
- A fork under a neutral foundation
- Contributors frustrated with the pace of Quagga’s development started fresh under the Linux Foundation, where many companies could maintain the code together.
- Install routes into the Linux kernel
- Using the kernel as the default forwarding layer lets any Linux machine route, and lets switch operating systems mirror kernel routes into their chips.
Timeline
- 2017
Forked from Quagga; announced as a Linux Foundation project on 3 April
- 2025
10.4 in July and 10.5 in November
- 2026
10.6 in March, 10.7 in July, 10.7.1 on 31 August
- LWN: FRRouting joins the Linux Foundation (4 April 2017; rooted in Quagga, “Cumulus private Quagga”)
- SDxCentral: Free Range Routing and DPDK join the Linux Foundation (April 2017; Cumulus, Orange, 6WIND, Big Switch, Volta)
- NetDEF: FRRouting (started as a fork of Quagga in April 2017 with Cumulus Networks; NetDEF runs the CI)
- Wikipedia: FRRouting (fork of Quagga, itself a fork of GNU Zebra; pace of development)
- MetalLB: BGP mode (FRR-K8s is the default BGP backend)
- GitHub: FRRouting/frr releases
Sources9 · facts checked 28 October 2026
- FRR user guide: About FRR (control plane only, daemons, zebra, vtysh, platforms, system requirements)
- GitHub: FRRouting/frr README (supported protocols, mgmtd and YANG)
- GitHub: FRRouting/frr COPYING and SPDX headers (GPL-2.0-or-later and other licences)
- GitHub: FRRouting/frr releases (10.4.0 July 2025 to 10.7.1 August 2026)
- FRRouting: home page (a Linux Foundation Collaborative Project)
- SONiC wiki: Architecture (bgp container running FRR)
- NVIDIA Developer: FRRouting (designed originally by Cumulus Networks)
- MetalLB: BGP mode (FRR-K8s default backend)
- LWN: FRRouting joins the Linux Foundation (April 2017)