FRR and Quagga on OPNsense — the routing daemons and how OPNsense exposes them

A routing protocol is not a single program. It is a collection of daemons that each handle one job, coordinated through a central manager. OPNsense’s dynamic routing story centres on FRR — the Free Range Routing suite — which descended from the Quagga project and which OPNsense exposes through the os-frr plugin. The operator who runs FRR on OPNsense without understanding the daemon model has a moving part they cannot reason about; the operator who understands the model can configure each protocol as a discrete concern and tune it independently.

This lesson covers what FRR is, its lineage from Quagga, the daemons it runs, how OPNsense exposes the configuration through its plugin, and the production discipline of running only the protocols the network needs.

The lineage — Zebra, Quagga, FRR

FRR did not appear from nowhere. Its history is worth understanding because the design — multiple cooperating daemons, a central manager — comes from the lineage and is the reason the production cost of running FRR is what it is.

• Zebra (1996) — Kunihiro Ishiguro wrote zebra for the GNU Zebra project, a routing suite that separated each protocol into its own daemon and coordinated them through a central manager. The architectural choice was unusual at the time (Cisco IOS runs everything in one image) but made Zebra easier to extend and easier to debug.
• Quagga (2002) — the GNU Zebra project went dormant; the community forked it as Quagga and continued development. Quagga became the dominant open-source routing suite on Linux and BSD for over a decade.
• FRR (2017) — the Quagga project slowed; a new community forked it as FRR (Free Range Routing) and accelerated development. FRR is the actively-maintained descendant and is what OPNsense ships in its os-frr plugin.

The architectural choice survived all three iterations: each protocol runs in its own daemon, all coordinated by a central zebra process. The OPNsense operator who runs FRR is running the same architecture Quagga shipped in 2002.

The daemons

FRR runs one zebra plus zero or more per-protocol daemons. The protocols OPNsense exposes through the os-frr plugin:

In production, an OPNsense deployment runs zebra plus one or two per-protocol daemons. A firewall that peers OSPF with an upstream runs zebra and ospfd. A multihomed edge that peers BGP with two ISPs runs zebra and bgpd. A firewall that runs all ten daemons is using none of them well.

The os-frr plugin on OPNsense

OPNsense exposes FRR through the os-frr plugin (System → Firmware → Plugins → os-frr). The plugin:

• Installs the FRR suite from the OPNsense package repository.
• Adds a top-level menu item (Routing → FRR) with a tab per daemon (General, OSPF, BGP, RIP, etc.).
• Writes the FRR configuration to /usr/local/etc/frr/ from the GUI settings.
• Provides start/stop control through configctl.
• Surfaces basic operational state in the GUI; the operator must use vtysh for detailed diagnostics.

The plugin does not change the kernel; it does not change PF; it does not change the firewall rule evaluation. It installs a routing daemon and writes its configuration. The operator who uses the plugin still has to understand the protocol — the GUI is a configuration interface, not a teaching tool.

$ sockstat -l -P tcp | grep -E ':(179|2601|2602|2604|2605|2606)'; echo '---'; ps -ax | grep -E '/frr|/zebra' | grep -v grep

root     frr       1234  4 tcp4   127.0.0.1:2601        *:*
root     frr       1234  5 tcp4   127.0.0.1:2602        *:*
root     frr       1234  6 tcp4   127.0.0.1:2604        *:*
root     frr       1234  9 tcp4   127.0.0.1:179          *:*
root     frr       1234  10 tcp6  ::1:179                *:*
---
1234  -  S    0:00.42 /usr/local/sbin/frr -f /usr/local/etc/frr/frr.conf
1240  -  S    0:00.18 /usr/local/sbin/zebra -f /usr/local/etc/frr/zebra.conf
1241  -  S    0:00.21 /usr/local/sbin/ospfd -f /usr/local/etc/frr/ospfd.conf
1242  -  S    0:00.19 /usr/local/sbin/bgpd -f /usr/local/etc/frr/bgpd.conf

The cost of running FRR

FRR is not free. The cost on a production firewall:

• CPU and memory — each daemon is a long-running process; FRR typically uses 30 to 80 MB of RAM with one or two protocols configured, plus CPU for SPF runs and BGP update processing. On a small firewall (1 GB RAM, slow CPU) this is significant; on a production firewall (8 GB RAM, modern CPU) it is in the noise.
• Configuration complexity — each protocol has its own configuration; the operator must understand the protocol to configure it correctly. A misconfigured OSPF area or a wrong BGP neighbor can black-hole traffic or, worse, advertise the wrong prefixes to the wrong peers.
• Security surface — a routing daemon that listens on an external interface is a target. BGP on the public Internet requires MD5 or TCP-AO authentication to prevent route hijacks and DoS. The operator must harden the daemon’s exposure.
• Operational surface — a routing daemon that crashes leaves the firewall with whatever routes were in the kernel at the moment of the crash; no new routes are learned until the daemon restarts. The operator must monitor the daemon’s health.

The discipline of running only what is needed

A clean FRR deployment has zebra and the one or two protocols the network needs. The operator who installs FRR and enables every protocol “in case” has:

• Increased the memory footprint for no benefit.
• Increased the configuration surface for no benefit.
• Increased the security surface for no benefit.
• Made the diagnostic story harder (more daemons to consider).

The discipline: configure the protocol the network needs, leave the others disabled, and verify with ps -ax | grep frr that only the intended daemons are running. A deployment that runs zebra, ospfd, bgpd, ripd, ripngd, and isisd is a deployment whose operator did not read the documentation.

Summary

• FRR is the actively-maintained descendant of Quagga and Zebra, with the same multi-daemon architecture.
• zebra is the central manager; per-protocol daemons (ospfd, bgpd, ripd, etc.) handle their respective protocols.
• OPNsense exposes FRR through the os-frr plugin, which writes the configuration and provides GUI control; the operator still must understand the protocol.
• The cost of FRR is real: memory, CPU, configuration complexity, security surface, and operational monitoring.
• The discipline is running only what the network needs — enabling every protocol is engineering theatre.