FRRouting on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of FRRouting (FRR) on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. FRRouting is a full IP routing protocol suite for Linux, the successor to Quagga and a project of the Linux Foundation. It runs the core internet routing protocols, including BGP, OSPF, IS-IS, RIP, PIM, LDP and BFD, as cooperating daemons (zebra, bgpd, ospfd, and more) managed through a single shell, vtysh. It turns a Linux host into a capable software router or route server for a cloud network, an on premises site or a lab.

The image installs the current stable FRRouting release (10.7.0) from the official FRR APT repository, with the repository signing key pinned by fingerprint, and adds the FRR origin to unattended upgrades so your VM keeps receiving FRR security updates.

Security by design — the VTY is never exposed. Each FRR daemon offers a telnet style VTY on a dedicated port (2601 to 2616). Left on a routable address with no password those ports are a serious attack surface, so this image binds every daemon VTY to 127.0.0.1 only. You manage the router locally as root with vtysh over its unix socket; nothing routable is opened. FRR is an internal VNet routing node, so the Network Security Group needs only TCP 22 for administration by default. You open the specific protocol ports (BGP tcp/179, OSPF IP protocol 89, and so on) to your own peers inside your VNet when you configure real routing.

Security by design — no baked credential. Routing is managed locally as root through vtysh, so there is no login credential baked into the image and nothing to rotate. First boot writes the per VM node details to /root/frrouting-credentials.txt (readable by root only).

A self contained demo that works the moment it boots. So the image is provably a working router on a single VM with nothing attached, it ships a small OSPF demo: this router (id 10.0.0.1) forms a real Full OSPF adjacency, over a virtual link, with a lightweight peer router that runs in a network namespace (id 10.0.0.2). The peer originates the route 10.20.20.2/32, which this router learns via OSPF (route code O). So show ip ospf neighbor shows a Full adjacency and show ip route shows a real OSPF learned route on first boot, with no external peers. You replace the demo with your own routing when you are ready.

What is included:

• FRRouting 10.7.0 (from the official frr-stable repository), run under systemd as frr.service

• zebra + bgpd + ospfd enabled and managed by watchfrr, ready for BGP and OSPF

• Every routing daemon VTY bound to 127.0.0.1 only — the telnet VTY ports are never exposed off box

• A self contained OSPF demo (a Full adjacency plus an OSPF learned route) that is live on first boot with no external peers

• Kernel IP forwarding enabled and the full networking module set installed, so the VM is a correct router

• No baked login credential — FRR is managed locally as root through vtysh

• Unattended security upgrades left enabled, covering both the OS and FRR

Prerequisites

• Active Azure subscription, SSH public key, VNet + subnet in the target region

• Subscription to the FRRouting listing on Azure Marketplace

• Network Security Group rules allowing TCP 22 for administration, plus whichever routing protocol ports you will use with your own peers (for example BGP tcp/179) restricted to those peers

Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM) for a control plane router or route server. Routers handling high traffic or many peers should use Standard_D2s_v5 or larger.

Step 1: Deploy from the Azure Portal

Search FRRouting in Marketplace, select the cloudimg publisher, and click Create. Configure the Network Security Group to allow TCP 22 for administration. FRR is an internal routing node, so do not expose the VTY or protocol ports to the internet; open protocol ports such as BGP tcp/179 only to your own peers inside your VNet (see Step 8).

Step 2: Deploy from the Azure CLI

RG="net-prod"; LOCATION="eastus"; VM_NAME="frr-node"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/frrouting-ubuntu-24-04/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
# Administration only. Open routing protocol ports to your own peers separately (Step 8):
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1001

Step 3: First boot

On first boot the image brings up the demo topology, starts FRR and the demo peer router, waits for the OSPF adjacency to reach Full, and writes /root/frrouting-credentials.txt. This completes within a minute. SSH in as azureuser and read the details:

sudo cat /root/frrouting-credentials.txt

Step 4: Confirm FRR is running

frr.service is active, vtysh reports the FRRouting version, and show daemons lists the enabled routing daemons running under watchfrr.

systemctl is-active frr.service
sudo vtysh -c "show version"
sudo vtysh -c "show daemons"

Step 5: Inspect the self contained OSPF demo

The image ships a live OSPF demo so you can see routing working immediately. This router forms a Full OSPF adjacency with a peer router running in a network namespace, over a point to point link in area 0, with no external peers required.

sudo vtysh -c "show ip ospf neighbor"
sudo vtysh -c "show ip ospf interface frrveth0"

Step 6: See the OSPF learned route

Because the adjacency is Full, this router learns the peer's route 10.20.20.2/32 via OSPF. In show ip route it appears with the route code O (OSPF), not C (connected), proving it was learned dynamically over the adjacency rather than being a local interface.

sudo vtysh -c "show ip route ospf"
sudo vtysh -c "show ip route 10.20.20.2/32"

Step 7: Secure by default — the VTY is loopback only

This is the key security property for a routing node. Every FRR daemon's VTY listens on 127.0.0.1 only, so the telnet style management ports (2601 to 2616) are never reachable off box. bgpd is running and ready for you to add your own BGP peers.

sudo ss -tlnp | grep -E '127.0.0.1:(260[0-9]|261[0-6])'
grep -E '^(zebra|bgpd|ospfd)=yes' /etc/frr/daemons
sudo vtysh -c "show ip bgp summary"

Step 8: Configure your own routing

Replace the demo with your own routing. FRR reads its integrated configuration from /etc/frr/frr.conf; you can edit that file or configure live with vtysh. For example, to peer BGP with a router at 10.1.0.5 in AS 65010, add a neighbor under the existing router bgp block:

router bgp 65000
 neighbor 10.1.0.5 remote-as 65010
 address-family ipv4 unicast
  neighbor 10.1.0.5 activate
 exit-address-family

Apply configuration changes and check them with:

sudo systemctl reload frr
sudo vtysh -c "show running-config"

The demo OSPF configuration (interfaces frrveth0, the router ospf block with router id 10.0.0.1) is safe to leave in place or remove once you have your own routing; it uses private link addresses that do not touch your real interfaces.

Step 9: Open protocol ports to your peers

FRR only needs TCP 22 exposed for administration. When you configure real routing, open the relevant protocol ports to your specific peers, never to the internet:

BGP   TCP 179             from each BGP peer's address
OSPF  IP protocol 89      from each OSPF neighbour's address (multicast within the subnet)
BFD   UDP 3784 / 4784     from each BFD peer

Add narrowly scoped Network Security Group rules for exactly the peers and protocols you use. Keeping the VTY loopback only (Step 7) means the control plane is never exposed even if a protocol port is open to a peer.

Step 10: Manage FRR with vtysh

vtysh is the single management shell for every daemon. Common operations:

sudo vtysh -c "show ip route"
sudo vtysh -c "show ip ospf neighbor"
sudo vtysh -c "show ip bgp summary"
sudo vtysh -c "show running-config"

To configure interactively, run sudo vtysh, then configure terminal. To persist the running configuration back to /etc/frr/frr.conf, use sudo vtysh -c "write memory".

Step 11: Security recommendations

• Keep the VTY loopback only. Manage FRR locally with vtysh. Do not change the -A 127.0.0.1 bindings in /etc/frr/daemons to a routable address unless you place a firewall in front — the VTY has no authentication by default.

• Restrict the NSG. Expose only TCP 22 for administration, and open routing protocol ports (BGP 179, OSPF, BFD) only to the specific peers that need them, never to the internet.

• Authenticate your routing sessions. For production peering, configure BGP MD5 / TCP-AO and OSPF authentication so neighbours are cryptographically verified.

• Filter your routes. Apply prefix lists and route maps to your BGP neighbours so you only accept and advertise the prefixes you intend to.

• Keep the OS and FRR patched. Unattended security upgrades remain enabled on the running VM and cover both Ubuntu and the FRR packages.

Step 12: Support and Licensing

FRRouting is a project of the Linux Foundation and is distributed under the GPL 2.0 or later license. This cloudimg image installs the unmodified official FRRouting packages. cloudimg provides the packaging, the loopback only VTY hardening, the self contained OSPF demo, kernel router defaults, and 24/7 support with a guaranteed 24 hour response SLA.

cloudimg is not affiliated with or endorsed by The FRRouting Project or the Linux Foundation. FRRouting and FRR are marks of their respective owners and are used here only to identify the software.

Deploy on Azure

Find FRRouting on Ubuntu 24.04 LTS on the Azure Marketplace, published by cloudimg. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email support@cloudimg.co.uk for deployment help, configuration questions, or licensing enquiries.