Free Range Routing (frr): Architecture And Setup Guide

Free Range Routing, commonly known as FRR, is an open-source routing protocol suite that transforms standard Linux and Unix systems into robust network routers. It manages core dynamic routing protocols like BGP, OSPF, and IS-IS, turning commodity hardware or virtualized instances into production-grade routing nodes. Whether you're engineering a massive hyperscale data center or configuring a home lab, understanding how this software stack operates gives you direct control over complex network paths without proprietary hardware lock-in.

At its core, FRR interacts directly with the operating system kernel to dynamically update routing tables. Instead of relying on static routes that break when a link drops, FRR communicates with neighboring routers, exchanges real-time path availability metrics, and adapts instantly. It serves as the underlying routing control plane for enterprise distributions, open-source network operating systems like VyOS, and cloud-native Kubernetes environments.

Architecture: How FRR Daemons Work Together

FRR abandons the monolithic design of older routing software in favor of a modular, multi-process architecture. Each routing protocol runs inside its own isolated daemon. This isolation means a failure or memory leak in the BGP process won't crash your OSPF routing tables or take down the system kernel interface.

The suite relies on several key components:

• Zebra: The core coordination daemon. Zebra acts as the abstraction layer between individual protocol daemons and the Linux kernel. It gathers routes from protocols like BGP or OSPF, computes the best path, and programs those paths directly into the kernel routing table.
• bgpd: Handles the Border Gateway Protocol, managing external peering sessions, path attributes, and full Internet routing tables.
• ospfd and ospf6d: Manage Open Shortest Path First versions 2 (IPv4) and 3 (IPv6) for interior gateway routing within an autonomous system.
• isisd: Implements the IS-IS routing protocol, frequently deployed in large-scale service provider and data center fabrics.
• vtysh: A unified command-line shell that lets administrators configure all running daemons through a single interface that mirrors traditional Cisco IOS syntax.

If one protocol daemon fails, the others continue running undisturbed, and Zebra maintains existing forwarding entries until recovery occurs.

Getting Started: Installation and Basic Configuration

Setting up FRR requires a modern Linux distribution. Most Debian and Red Hat based systems include FRR in their default repositories, or you can pull directly from the project's official package repositories.

For Ubuntu or Debian systems, install the core software and Python extension tools using standard package management:

sudo apt update
sudo apt install frr frr-pythontools

FRR keeps its daemon configuration flags centralized. By default, the software boots with all protocols disabled for security and resource conservation. To configure which daemons start, open the configuration file:

sudo nano /etc/frr/daemons

Locate the lines for the protocols you need and change them from no to yes. You must always enable zebra because every other protocol relies on it:

zebra=yes
bgpd=yes
ospfd=no
vtysh_enable=yes

Save the file, then enable and start the system service to initialize the routing stack:

sudo systemctl enable frr
sudo systemctl start frr

Configuring Routes via the vtysh Interface

Once the service is active, you don't need to configure each daemon file individually. Instead, launch the integrated shell:

sudo vtysh

Your command prompt changes to frr#, indicating you're inside the unified shell. From here, enter global configuration mode to set up a routing protocol, such as establishing an Autonomous System (AS) number for BGP:

frr# configure terminal
frr(config)# router bgp 65001
frr(config-router)# neighbor 192.168.100.2 remote-as 65002
frr(config-router)# address-family ipv4 unicast
frr(config-router-af)# network 10.0.0.0/24

You can verify your live configuration and peer states at any time using standard operational commands:

frr# show ip bgp summary
frr# show running-config

Common Implementation Mistakes to Avoid

Network engineers transitioning to FRR often stumble over a few operational pitfalls that cause dropped sessions or unadvertised routes:

• Forgetting Zebra Integration: Trying to configure protocol daemons without ensuring Zebra is enabled in /etc/frr/daemons results in silent failures because protocols have nowhere to push their calculated routes.
• Omitting Write Commands: Changes made inside vtysh apply immediately to the running memory configuration, but they don't persist across reboots unless you explicitly save them using write memory or copy running-config to startup-config.
• Firewall and Permission Blocks: Linux distributions running strict firewall rules or SELinux policies may drop BGP (TCP port 179) or OSPF multicast traffic unless explicitly permitted in nftables or iptables.

Frequently Asked Questions

Can FRR handle a full Internet BGP routing table?

Yes. FRR is written in C and optimized for high-performance memory management. It easily processes full global BGP tables exceeding 900,000 routes when deployed on adequate hardware.

Is FRR only compatible with Linux?

While Linux is the primary production platform with the tightest kernel integration, FRR also runs on FreeBSD, OpenBSD, NetBSD, and Solaris.

How does FRR relate to Quagga?

FRR is a direct fork of the older Quagga routing suite, created in 2017 by core developers seeking more rapid release cycles, modernized code architecture, and broader protocol support.

Does FRR support IPv6 routing protocols natively?

Yes. FRR includes full native support for IPv6 routing extensions, including BGP-4+, OSPFv3, RIPng, and static IPv6 route management.