OSPF on Linux Part 1: A Brief History of Routing on Linux

The OSPF Deep Dive series covered the protocol across Cisco IOS-XE, FortiOS, and Junos. All three are appliances with the routing daemon baked into the vendor’s own operating system. Linux is different: the kernel has always been able to forward packets and hold a routing table, but it has never shipped an OSPF speaker of its own. Anything that talks OSPF on a Linux box is a userspace daemon that was bolted on, and which daemon that is has changed twice in the kernel’s history, each time for a specific and avoidable reason.

This series is a companion to OSPF Deep Dive, not a repeat of it. It assumes the protocol theory from Parts 1 through 6 of that series and applies it to a fourth platform: a Linux router running FRRouting, wired directly into the same three-router lab. This post covers why FRR is the thing you install today, starting from the beginning, because the shape of FRR’s configuration in Part 3, one daemon per protocol, all of them separate from the kernel, only makes sense once you’ve seen what it replaced.

Before Zebra, there wasn’t much

Early Linux could hold a routing table and forward between interfaces from the moment IP routing landed in the kernel, but “hold a routing table” and “run a routing protocol” are different problems. The kernel’s job is the FIB, the Forwarding Information Base, the compiled table the data plane actually consults per packet. Deciding what goes into that table dynamically, based on hellos and LSAs and SPF, is a control-plane problem, and the Linux kernel has never tried to solve it internally. routed (RIP) and gated existed on Unix systems generally through the 1980s and 90s, gated in particular supporting OSPF, but gated’s licensing tightened over time and it was never a natural fit for a Linux distribution the way a GPL project would be.

GNU Zebra: the split that’s still the architecture today

Kunihiro Ishiguro released GNU Zebra in 1996, with Yoshinari Yoshikawa, as the first open-source routing engine distributed under a free license, GPLv2. Zebra’s actual contribution wasn’t “OSPF for Linux” narrowly, it was an architecture: separate the RIB broker that talks to the kernel’s FIB over a defined interface from the protocol implementations themselves, and let each protocol run as its own daemon, ripd, ospfd, bgpd, all installing routes into the kernel through the shared zebra daemon rather than each one touching the FIB independently. A single CLI shell, styled deliberately close to Cisco IOS, sat on top and gave every daemon a familiar-feeling terminal.

That split, RIB broker plus independent protocol daemons plus a unifying shell, is still exactly the architecture FRR ships today. Nothing about it has changed at the structural level in thirty years; what changed is who maintains it and how fast.

Quagga: what happens when the original maintainer moves on

Zebra’s development stalled as Ishiguro’s attention shifted elsewhere, and in 2002 a group of contributors forked the codebase as Quagga specifically to keep it moving. GNU Zebra’s own final release, version 0.95a, came out in September 2005, and by then the community had already migrated: Quagga became the project distributions packaged, and for most of the following decade “Linux OSPF” effectively meant Quagga’s ospfd, inherited nearly unchanged from Zebra.

Quagga did the job for a long time. It’s also the reason the fork pattern repeated: Quagga’s own development process slowed in a similar way to Zebra’s, patches sitting unreviewed, releases spacing out, without a formal governance structure forcing throughput. A project that exists specifically to keep a stalled project moving eventually has to solve for what happens when it stalls too.

FRRouting: forking the fork, on purpose, with a maintainer behind it

Development on what became FRRouting started in mid-2016 among Quagga contributors who wanted a different process, not different code: continuous integration, a real review pipeline, and a project structure that didn’t depend on one person’s bandwidth. Cumulus Networks, 6WIND, BigSwitch Networks, and the Network Device Education Foundation (NetDEF) backed the effort, and NetDEF has governed the project since. FRR’s first public release shipped in April 2017.

The name is literal: Free Range Routing. The codebase at launch was recognizably Quagga’s, same zebra/daemon split, same vtysh shell, and the project has diverged steadily since on pace alone. As of this writing FRR is on release 10.7.0, shipped July 2026, against a Quagga project that last saw meaningful activity years earlier. That gap, not a technical rewrite, is the actual case for FRR: the architecture Zebra defined in 1996 didn’t need reinventing, it needed a maintainer that kept showing up.

Part 2 covers why that history settled on FRR specifically as the default choice today, rather than BIRD, the other project that survived this same period, and what FRR’s architecture looks like from the inside before Part 3 gets it installed.