OSPF on Linux Part 2: Why FRRouting Is the Defacto Choice

Part 1 covered how Linux routing got from GNU Zebra to Quagga to FRRouting, a maintenance story more than a technical one. This post covers what you actually get: the architecture underneath FRR’s OSPF implementation, and why FRR specifically, rather than BIRD, is the thing worth installing when the goal is an OSPF speaker that fits into a lab (or a production network) built around Cisco, FortiOS, and Junos routers.

The architecture: zebra as the broker, protocols as tenants

FRR is not one daemon. It’s a family of them, one per protocol, ospfd, bgpd, ripd, isisd, and so on, each an independent process with its own RIB. None of them talk to the kernel directly. Every one of them hands routes to zebra, which owns the actual conversation with the Linux kernel’s FIB over netlink, resolves which protocol’s route wins when more than one offers a path to the same prefix, and installs the winner. zebra is the only FRR component that touches the kernel routing table at all.

This matters practically in a way that isn’t obvious from a features list. Because ospfd is its own process, it can crash, hang, or get restarted without taking bgpd down with it, and zebra keeps whatever routes were already installed from other protocols in place while it happens. It also means the daemon list in /etc/frr/daemons, covered in Part 3, is a genuine on/off switch per protocol rather than a compile-time option: an OSPF-only Linux router runs zebra and ospfd and nothing else, with every other protocol daemon simply not started.

vtysh sits on top of all of it as a single shell that multiplexes commands out to whichever daemon owns them, router ospf context goes to ospfd, show ip route goes to zebra, and presents the result as one continuous CLI session rather than a collection of separate consoles. That’s the part that reads as familiar to anyone who’s spent time in CORE-CSR’s IOS-XE terminal from the OSPF Deep Dive lab, deliberately, because Zebra’s original authors modeled the shell on Cisco’s CLI in 1996 and FRR inherited it unchanged.

FRR against BIRD

BIRD is the other project that came out of this same era still actively maintained, and it’s worth naming directly rather than pretending FRR is the only option. BIRD takes a different architectural bet: one daemon handling every protocol internally, with its own configuration language rather than a Cisco-styled CLI, and a long-standing reputation as the tool of choice at internet exchange points and for route-server workloads where BGP scale and a lean footprint matter more than anything else. It supports OSPF too, competently.

FRR’s case against it, for the purposes of this series and for most enterprise-network use generally, comes down to two things. First, the multi-daemon architecture and the vtysh shell mean the mental model and even a fair amount of the literal syntax, router ospf, network <prefix> area <id>, show ip ospf neighbor, transfers directly from the Cisco and FortiOS configuration already covered in OSPF Deep Dive Parts 7 and 8, which is a genuine advantage in a mixed-vendor shop and not just a nostalgia feature. Second, FRR’s adoption footprint in production networking is broader specifically where Linux is doing real routing rather than just hosting a lab: it’s the routing engine inside Cumulus Linux (now NVIDIA’s data-center NOS line), it ships as the default in several open network operating systems, and it’s the routing daemon containerlab reaches for by default when a topology calls for a Linux router node. BIRD remains the stronger pick for a dedicated route-server or an operator whose workload is overwhelmingly BGP at very high peer counts; FRR is the stronger pick for “I need this Linux box to be a real, general-purpose OSPF router that a Cisco engineer can read the config of,” which is exactly this series’ brief.

What “defacto” means here, concretely

FRR is under active, funded development, NetDEF-governed, with a release cadence that hasn’t slowed the way Zebra’s and Quagga’s each did before their respective forks, release 10.7.0 shipped in July 2026. It’s the daemon behind the OSPF configuration already used in the Linux Networking from the Ground Up post on this site, in the netns lab there. This series goes further than that post did on OSPF specifically: real installation from a package, real daemon configuration, and a live seat in the OSPF Deep Dive lab rather than a namespace sandbox on its own.

Part 3 installs it.