Deploying FRRouting on Ubuntu 24.04 LTS: Production BGP and OSPF Routing

By Manny Fernandez

July 20, 2026

Deploying FRRouting on Ubuntu 24.04 LTS: Production BGP and OSPF Routing

1. Executive Summary

Objective. This guide turns a stock Ubuntu 24.04 LTS host into a fully functional software router using FRRouting (FRR). You will build a small but production-shaped fabric: an OSPF backbone between two routers and an eBGP session to an upstream provider, complete with route filtering, verification, and the diagnostics you actually need when a session refuses to come up.

Why it matters. FRR is the same routing stack that ships inside data-center switches and cloud gateways. Running it on commodity Linux gives you a real BGP and OSPF speaker for lab validation, route reflection, edge routing, or host-based routing at a fraction of the cost of dedicated hardware.

Target audience. Network Engineers, Systems Engineers, and Linux-focused DevOps or SRE practitioners who are comfortable at a shell and understand routing fundamentals but have not yet run FRR in anger.

2. Prerequisites and Architecture

Assumed Knowledge

Comfortable with the Linux CLI, sudo, and editing files with nano or vim.
Working knowledge of IP addressing, subnetting, and static routing.
Conceptual understanding of OSPF areas and BGP autonomous systems, neighbors, and prefixes.

Environment and Lab Requirements

Two Ubuntu 24.04 LTS instances (bare metal, KVM/Proxmox, EVE-NG, or cloud VMs). Minimum 2 vCPU and 2 GB RAM per node is plenty for a lab.
Three virtual NICs per router in this topology: management, core link, and (on R1) the provider uplink. Adjust to your hypervisor naming.
Root or sudo on each host, plus outbound internet for package installation.
Software versions: Ubuntu ships FRR 8.4.4 in the universe repository (maintained by Canonical with security backports). The official FRR repository currently offers 10.5.x, the latest stable branch. Both paths are covered in Phase 2.

Component Table

Component	Role	Interfaces and IPs	ASN / Router-ID
R1 (frr-core-01)	FRR router: OSPF + eBGP edge	ens18 mgmt 10.10.0.11/24 ens19 core 10.0.12.1/30 ens20 uplink 203.0.113.2/30 lo 10.255.0.1/32	AS 65001 RID 10.255.0.1
R2 (frr-core-02)	FRR router: OSPF core	ens18 mgmt 10.10.0.12/24 ens19 core 10.0.12.2/30 lo 10.255.0.2/32	AS 65001 RID 10.255.0.2
Upstream (edge)	Provider eBGP peer	203.0.113.1/30	AS 64512

All addresses use RFC 5737 and RFC 1918 documentation ranges. Substitute your own. OSPF runs in area 0 across the R1 to R2 core link; loopbacks are advertised as router identifiers and reachable service addresses.

3. Step-by-Step Implementation Workflow

Phase 1: Prepare the Host

Goal. Get the base OS current, set a stable hostname, apply static addressing, and enable kernel IP forwarding so the box can route packets between interfaces.

Action. Update packages and set the hostname (repeat per node, substituting the name).

bash

sudo apt update && sudo apt -y full-upgrade
sudo hostnamectl set-hostname frr-core-01
sudo timedatectl set-ntp true

Action. Apply static interface addressing with netplan. Create the file below on R1 (adjust for R2, which has no uplink NIC).

/etc/netplan/01-frr-lab.yaml

network:
  version: 2
  ethernets:
    ens18:                      # management
      addresses: [10.10.0.11/24]
      routes:
        - to: default
          via: 10.10.0.1
      nameservers:
        addresses: [10.10.0.1]
    ens19:                      # core link to R2
      addresses: [10.0.12.1/30]
    ens20:                      # provider uplink
      addresses: [203.0.113.2/30]

Action. Secure the netplan file (24.04 warns about world-readable configs) and apply it.

bash

sudo chmod 600 /etc/netplan/01-frr-lab.yaml
sudo netplan apply

Action. Enable IPv4 and IPv6 forwarding with a sysctl drop-in so the setting survives reboots.

bash

sudo tee /etc/sysctl.d/99-frr.conf >/dev/null <<'EOF'
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
EOF
sudo sysctl --system

GUI Verification. There is no web interface at this stage. FRR is CLI-first. Confirm addressing and forwarding from the shell:

bash

ip -brief address
sysctl net.ipv4.ip_forward     # expect: net.ipv4.ip_forward = 1

Phase 2: Install FRRouting

Goal. Install the FRR suite and its Python tooling. Pick one of the two paths below and use it on both routers.

Action, Option A (Ubuntu universe, FRR 8.4.4). Simplest path, maintained by Canonical with security backports for the life of 24.04 LTS.

bash

sudo apt install -y frr frr-pythontools

Action, Option B (official FRR repo, 10.5.x). Use this when you need current features (mgmtd, newer BGP/EVPN/SRv6 work) or the latest fixes. Add the signed repository, then install.

bash

# 1) Import the FRR signing key
curl -s https://deb.frrouting.org/frr/keys.gpg | \
  sudo tee /usr/share/keyrings/frrouting.gpg > /dev/null

# 2) Add the repo. FRRVER options include frr-stable, frr-10, frr-10.5
FRRVER="frr-stable"
echo deb '[signed-by=/usr/share/keyrings/frrouting.gpg]' \
  https://deb.frrouting.org/frr $(lsb_release -s -c) $FRRVER | \
  sudo tee -a /etc/apt/sources.list.d/frr.list

# 3) Install
sudo apt update && sudo apt install -y frr frr-pythontools

Which one? For most production edge or lab work, Option B (10.5.x) is the better long-term choice because the FRR project fixes bugs there first. Choose Option A if your compliance posture requires that every package come from the Canonical archive.

GUI Verification. Confirm the version and that the service unit is present.

bash

vtysh -c "show version"
systemctl status frr --no-pager

Phase 3: Enable the Routing Daemons

Goal. FRR ships with every protocol daemon disabled except zebra. You must explicitly turn on the daemons you intend to run. This is the single most common reason a fresh FRR install appears to do nothing.

Action. Edit /etc/frr/daemons and set the two daemons we need to yes, then restart FRR.

bash

# Flip ospfd and bgpd to yes (idempotent sed edits)
sudo sed -i 's/^ospfd=no/ospfd=yes/'  /etc/frr/daemons
sudo sed -i 's/^bgpd=no/bgpd=yes/'    /etc/frr/daemons

# Apply
sudo systemctl restart frr
sudo systemctl enable frr

GUI Verification. Enter the integrated operator shell (vtysh) and confirm both daemons are live.

vtysh

sudo vtysh -c "show daemons"
# Expect zebra, ospfd, and bgpd (plus staticd/mgmtd on 10.x) in the list

Phase 4: Add Loopbacks in FRR

Goal. Give each router a stable /32 loopback that serves as its router identifier and a reachable service address. Zebra can manage the address directly, keeping all routing state in one place.

Action. From the shell, drop into vtysh and configure the loopback (R1 shown, use 10.255.0.2/32 on R2).

vtysh

sudo vtysh

configure terminal
interface lo
 ip address 10.255.0.1/32
exit
end
write memory

Phase 5: Configure the OSPF Backbone

Goal. Bring up an OSPF adjacency across the R1 to R2 core link in area 0, and advertise each router’s loopback. We set passive-interface default so OSPF never leaks onto management or uplink segments, then selectively activate the one interface that should form a neighbor.

Action, R1.

vtysh (R1)

configure terminal
router ospf
 ospf router-id 10.255.0.1
 passive-interface default
 no passive-interface ens19
 network 10.0.12.0/30 area 0
 network 10.255.0.1/32 area 0
exit
end
write memory

Action, R2. Same pattern, with R2’s identifier and loopback.

vtysh (R2)

configure terminal
router ospf
 ospf router-id 10.255.0.2
 passive-interface default
 no passive-interface ens19
 network 10.0.12.0/30 area 0
 network 10.255.0.2/32 area 0
exit
end
write memory

Tip. Modern FRR also supports per-interface OSPF with ip ospf area 0 under interface ens19 instead of network statements. Either works. Network statements are used here because they keep the whole OSPF config in one block.

GUI Verification. Within seconds the neighbor should reach Full state.

vtysh

sudo vtysh -c "show ip ospf neighbor"

Phase 6: Configure eBGP to the Upstream

Goal. Peer R1 with the provider in AS 64512 and originate a single summarized prefix (10.255.0.0/24) toward them, with inbound and outbound route-maps in place. FRR enforces a policy on eBGP sessions by default, so the route-maps are mandatory, not optional.

Action, R1. The discard (blackhole) route lets BGP originate the aggregate cleanly. Real traffic still follows the more specific OSPF /32 routes.

vtysh (R1)

configure terminal
!
! Discard route backing the advertised aggregate
ip route 10.255.0.0/24 blackhole
!
! What we are allowed to originate
ip prefix-list PL-LOCAL seq 5 permit 10.255.0.0/24
!
route-map RM-UPSTREAM-OUT permit 10
 match ip address prefix-list PL-LOCAL
!
! Inbound: permissive in the lab. In production, filter bogons
! and set a maximum-prefix guard (kept below).
route-map RM-UPSTREAM-IN permit 10
!
router bgp 65001
 bgp router-id 10.255.0.1
 neighbor 203.0.113.1 remote-as 64512
 neighbor 203.0.113.1 description UPSTREAM-EDGE
 !
 address-family ipv4 unicast
  network 10.255.0.0/24
  neighbor 203.0.113.1 route-map RM-UPSTREAM-IN in
  neighbor 203.0.113.1 route-map RM-UPSTREAM-OUT out
  neighbor 203.0.113.1 maximum-prefix 500000
 exit-address-family
exit
end
write memory

Gotcha preview. Since FRR 7.4, bgp ebgp-requires-policy is on by default. Without both an inbound and outbound policy, an eBGP session comes up but exchanges zero prefixes. The route-maps above satisfy that requirement. See Troubleshooting item 2.

GUI Verification. Confirm the session and prefix counts.

vtysh

sudo vtysh -c "show ip bgp summary"

Phase 7: Persist and Enable on Boot

Goal. Make the running config survive a reboot. With integrated config (the default on modern FRR), write memory saves everything into /etc/frr/frr.conf.

Action. Save and confirm the service is enabled on both routers.

bash

sudo vtysh -c "write memory"
sudo systemctl is-enabled frr     # expect: enabled
sudo cat /etc/frr/frr.conf | head -n 40

4. Verification and Validation

Run these from either router. They confirm the control plane (adjacencies and prefixes) and the data plane (reachability) independently.

vtysh

# OSPF adjacency and learned routes
sudo vtysh -c "show ip ospf neighbor"
sudo vtysh -c "show ip route ospf"

# BGP session, received and advertised prefixes
sudo vtysh -c "show ip bgp summary"
sudo vtysh -c "show ip bgp"
sudo vtysh -c "show ip bgp neighbor 203.0.113.1 advertised-routes"

# Data plane: reach R2's loopback sourced from R1's loopback
ping -c 3 -I 10.255.0.1 10.255.0.2

What success looks like:

show ip ospf neighbor lists the peer in state Full (for example Full/DR or Full/BDR). Anything stuck in Init, ExStart, or Exchange means trouble. See item 1.
show ip route ospf shows the remote loopback as an O route via the core link.
show ip bgp summary shows the neighbor with an uptime under the State/PfxRcd column instead of a state word. A numeric value there means the session is Established and prefixes are flowing.
The advertised-routes output contains 10.255.0.0/24, confirming your outbound policy is originating the aggregate.
The ping succeeds with 0 percent loss, proving end-to-end forwarding over the OSPF core.

5. Troubleshooting and Gotchas

1. OSPF neighbor stuck in ExStart or Exchange (MTU mismatch)

The classic OSPF failure. Adjacency reaches ExStart or Exchange and never advances to Full. The usual cause is an MTU mismatch between the two interfaces, common when one side rides a tunnel or a hypervisor with a smaller frame size.

vtysh

# Compare the MTU value on both ends
sudo vtysh -c "show ip ospf interface ens19"

# Watch the handshake in real time
sudo vtysh -c "debug ospf packet all"
sudo vtysh -c "show logging"     # or: journalctl -u frr -f

Resolution. Make the MTUs match on both interfaces (fix it in netplan and re-apply), or, if you cannot, tell OSPF to ignore the mismatch on that link:

vtysh

configure terminal
interface ens19
 ip ospf mtu-ignore
end
write memory

2. eBGP Established but zero prefixes exchanged (policy required)

The session shows Established, yet PfxRcd and PfxSnt stay at 0. On modern FRR this is almost always the ebgp-requires-policy default doing its job: an eBGP neighbor with no inbound or outbound policy is allowed to peer but not to move routes.

vtysh

# Look for a line noting inbound/outbound policy is required
sudo vtysh -c "show ip bgp neighbor 203.0.113.1"
sudo vtysh -c "show ip bgp neighbor 203.0.113.1 advertised-routes"

Resolution. Attach an inbound and outbound route-map, exactly as in Phase 6. Keep the policy in production and filter deliberately. Only in a throwaway lab should you consider disabling the guard entirely with no bgp ebgp-requires-policy under the BGP process. After any policy change, refresh the session:

vtysh

sudo vtysh -c "clear ip bgp 203.0.113.1 soft"

3. BGP session stuck in Active or Connect (no path or blocked port 179)

If the neighbor never reaches Established and cycles through Active or Connect, the TCP session to the peer is not forming. The three usual suspects are no IP reachability to the peer, a firewall blocking TCP 179, or a mismatched remote AS.

bash

# 1) Can we even reach the peer IP?
ping -c 3 203.0.113.1

# 2) Is bgpd listening on 179, and is anything blocking it?
sudo ss -tlnp | grep ':179'
sudo ufw status verbose

# 3) Does our remote-as match what the peer expects?
sudo vtysh -c "show ip bgp neighbor 203.0.113.1" | grep -i "remote AS"

Resolution. Fix the specific cause: correct the uplink addressing or routing if the ping fails; allow BGP if ufw is active; or correct the remote-as to match the peer. To open port 179 when ufw is enabled:

bash

sudo ufw allow from 203.0.113.1 to any port 179 proto tcp

Bonus gotcha: the config vanished after a reboot.

Two causes. First, you configured in vtysh but never ran write memory, so nothing was saved to /etc/frr/frr.conf. Second, the relevant daemon is set to no in /etc/frr/daemons, so the process never starts and its saved config is ignored. Confirm both, then reboot to validate.

Deploying FRRouting on Ubuntu 24.04 LTS: Production BGP and OSPF Routing

1. Executive Summary

2. Prerequisites and Architecture

Assumed Knowledge

Environment and Lab Requirements

Component Table

3. Step-by-Step Implementation Workflow

Phase 1: Prepare the Host

Phase 2: Install FRRouting

Phase 3: Enable the Routing Daemons

Phase 4: Add Loopbacks in FRR

Phase 5: Configure the OSPF Backbone

Phase 6: Configure eBGP to the Upstream

Phase 7: Persist and Enable on Boot

4. Verification and Validation

5. Troubleshooting and Gotchas

1. OSPF neighbor stuck in ExStart or Exchange (MTU mismatch)

2. eBGP Established but zero prefixes exchanged (policy required)

3. BGP session stuck in Active or Connect (no path or blocked port 179)

Recent posts