cloudparts

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
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 mgmtd is still in progress, so automation often still drives vtysh and 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 →

How it fits with other technologies

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

  1. 2017

    Forked from Quagga; announced as a Linux Foundation project on 3 April

  2. 2025

    10.4 in July and 10.5 in November

  3. 2026

    10.6 in March, 10.7 in July, 10.7.1 on 31 August

Sources9 · facts checked 28 October 2026

Improve this page on GitHub