Deployment guide

FRRouting

Overview

FRRouting (FRR) 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.

This guide covers the deployment and configuration of FRRouting on Ubuntu 24.04 on Azure using SecureAnyCloud Azure Marketplace images. 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. It also adds the FRR origin to unattended upgrades, so your VM keeps receiving FRR security updates.

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, and nothing routable is opened.

FRR is a routing node inside your VNet, so the Network Security Group needs only TCP 22 for administration by default. When you configure real routing, open the specific protocol ports (BGP tcp/179, OSPF IP protocol 89, and so on) to your own peers inside your VNet.

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. The image ships a small OSPF demo, so it is provably a working router on a single VM with nothing attached. 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).

On first boot, show ip ospf neighbor shows a Full adjacency and show ip route shows a real OSPF-learned route, with no external peers. You replace the demo with your own routing when you are ready.

What you get:

FRRouting 10.7.0 (from the official frr-stable repository), run under systemd as frr.service.
zebra, bgpd and ospfd enabled and managed by watchfrr, ready for BGP and OSPF.
Every routing daemon VTY bound to 127.0.0.1 only, so 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

An active Azure subscription, an SSH public key, and a VNet and subnet in the target region.
A subscription to the FRRouting listing on Azure Marketplace.
Network Security Group rules that allow TCP 22 for administration. Add 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 that handle high traffic or many peers should use Standard_D2s_v5 or larger.

Deploy from the Azure Portal

Search the Marketplace for FRRouting, select the SecureAnyCloud publisher, and select Create.

Configure the Network Security Group to allow TCP 22 for administration. FRR is a routing node inside your VNet, 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).

Deploy from the Azure CLI

RG="net-prod"; LOCATION="eastus"; VM_NAME="frr-node" IMAGE_URN="sac1647283583153:frrouting-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:frrouting-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --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

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

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"

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. No external peers are required.

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

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, the route appears with the route code O (OSPF), not C (connected). This proves the router learned it dynamically over the adjacency rather than from a local interface.

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

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"

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.

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. Because the VTY stays loopback only (Step 7), the control plane is never exposed, even if a protocol port is open to a peer.

Manage FRR with vtysh

vtysh is the single management shell for every daemon. These are the 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 save the running configuration back to /etc/frr/frr.conf, use sudo vtysh -c "write memory".

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, because the VTY has no authentication by default.
Restrict the NSG. Expose only TCP 22 for administration. 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 your neighbors are cryptographically verified.
Filter your routes. Apply prefix lists and route maps to your BGP neighbors, so you accept and advertise only 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.

Support and Licensing

FRRouting is a project of the Linux Foundation and is distributed under the GPL 2.0 or later license. This SecureAnyCloud image installs the unmodified official FRRouting packages. SecureAnyCloud 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.

SecureAnyCloud 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 SecureAnyCloud. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email sales@secureanycloud.com for deployment help, configuration questions or licensing inquiries.

Deploy on Azure

Launch FRRouting (FRR) on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

FRRouting (FRR) is the open source IP routing protocol suite for Linux. It implements BGP, OSPFv2 and OSPFv3, IS-IS, RIP and RIPng, PIM, LDP, BFD, Babel, PBR, OpenFabric and VRRP. It is the successor to Quagga and a project of the Linux Foundation.

This image ships FRR 10.7.0 installed from the official FRR stable APT repository, with the repository signing key pinned by fingerprint. It runs under systemd as a hardened routing node.

FRR on an instance is a routing control plane and speaker. It exchanges routes with your peers using standard routing protocols and installs them into the instance's own kernel routing table. It is well suited to a BGP route reflector or route server, a dynamic routing speaker that peers with an on-premises network across a tunnel, or a learning and testing lab. It complements, rather than replaces, the AWS VPC route table for steering traffic between subnets. This guide frames those use cases below.

What you get:

The zebra routing manager together with the bgpd and ospfd daemons, all supervised by watchfrr and managed through the integrated vtysh shell. A single /etc/frr/frr.conf is the source of truth.
bgpd running and ready for you to add your own BGP neighbors, and ospfd running a live OSPF instance.
Kernel IP forwarding enabled and persisted, so the instance is a correct router.
A secure-by-default VTY. Every routing daemon binds its telnet VTY to the loopback interface only, so the VTY ports are never reachable off the instance. You manage the suite locally as root with vtysh over a root-only unix socket.
No VTY or enable password, and no shared or default routing credential, in the image.

Prerequisites

Before you deploy this image, you need:

An AWS account and permission to launch EC2 instances and subscribe to AWS Marketplace products.
An EC2 key pair in your target region, so you can connect over SSH.
A VPC with a subnet, and a security group that allows inbound SSH from your management network.
The AWS CLI, installed and configured, if you prefer to launch from the command line.
Familiarity with IP routing concepts and with vtysh, the FRR shell.

The recommended instance type for this product is m5.large (2 vCPU, 8 GB), which is comfortable for control plane routing. Small labs run on a smaller type. Production route reflectors that handle large tables benefit from more memory.

Launch from the AWS Marketplace

Open the product page on the AWS Marketplace and choose Continue to Subscribe, then Continue to Configuration.
Select the software version and your region, then choose Continue to Launch.
Choose Launch through EC2 (or Launch from Website). Pick the m5.large instance type, your VPC subnet, your key pair and a security group (see the ports section below).
Launch the instance and wait for the status checks to pass.

Launch from the AWS CLI

Replace the example values with your own. The product's launch page shows the AMI ID for your region.

$ aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <your-key-pair> \
  --security-group-ids <security-group-id> \
  --subnet-id <subnet-id> \
  --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=frrouting}]'

Security group and protocol ports

FRR is a routing node inside your VPC. The image itself opens nothing outward, and the only port you must allow to operate it is SSH.

TCP 22 (SSH): allow from your management network so you can administer the router.

Open the specific protocol ports your routing design uses only to your own peers. Ideally, reference the peers' security group or private CIDR rather than the whole internet:

TCP 179: BGP, to your BGP neighbors.
IP protocol 89 (OSPF): to your OSPF neighbors on the same layer 2 or over a tunnel.
UDP 3784 and 3785: BFD, if you enable bidirectional forwarding detection.
TCP/UDP 646: LDP, if you enable label distribution.

The per-daemon telnet VTY ports (2601 to 2616) are bound to 127.0.0.1 only and must never be exposed. Manage the router with vtysh over SSH instead.

Connect over SSH

Connect as the ubuntu user with your key pair. You manage FRR with the vtysh shell.

$ ssh -i <your-key.pem> ubuntu@<public-ip>

First boot writes the per-instance node details to a root-only file. It contains no secret, because there is no routing login. View it with:

$
sudo cat /root/frrouting-credentials.txt

Confirm FRR is running

Check that the routing suite is up and read its version. FRR reports itself as operational under systemd, with zebra, ospfd, bgpd and watchfrr all running:

systemctl is-active frr
sudo vtysh -c "show version"

The enabled daemons and configuration

List the running daemons and read the running configuration. zebra, ospfd and bgpd are enabled. The configuration is a single integrated file, so show running-config reflects exactly what is loaded.

sudo vtysh -c "show daemons"
sudo vtysh -c "show running-config"

The self-contained OSPF demonstration

The image ships a functional OSPF demonstration that runs on a single instance with no external peers, so you can see real dynamic routing immediately. A virtual link joins the main router to a lightweight peer router in an isolated network namespace. OSPF area 0 forms a real Full adjacency across the link, and the peer originates 10.20.20.2/32, which the main router learns via OSPF (route code O).

sudo vtysh -c "show ip ospf neighbor"
sudo vtysh -c "show ip route ospf"
sudo vtysh -c "show ip route"

The show ip ospf neighbor output shows the adjacency in state Full, and show ip route shows O>* 10.20.20.2/32 learned from the peer, a real dynamic route rather than a directly connected one. The demonstration survives a systemctl restart frr. When you are ready to run your own topology, replace the demo configuration in /etc/frr/frr.conf and remove the demo units, as shown later.

bgpd is enabled and running as well, ready for you to add your own neighbors:

sudo vtysh -c "show ip bgp summary"
sudo vtysh -c "show version"

Secure by default

Confirm that every daemon VTY is bound to the loopback interface and that IP forwarding is enabled. The listening VTY ports appear only on 127.0.0.1, and net.ipv4.ip_forward is 1.

sudo ss -tln sudo sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding

Because the VTY is loopback only, there is no network-facing management interface to attack and no VTY password to manage. Keep it that way, and administer the router through vtysh over SSH.

Configure your own routing

Edit the configuration through vtysh in configuration mode, then write it so it persists. The example below adds a BGP neighbor. Adapt the addresses and AS numbers to your design.

These commands change the running router, so review them and run them yourself:

sudo vtysh configure terminal router bgp 65000 neighbor 203.0.113.10 remote-as 64512 address-family ipv4 unicast neighbor 203.0.113.10 activate exit-address-family exit end write memory

To enable another protocol daemon, set it to yes in /etc/frr/daemons and reload FRR:

sudo sed -i 's/^isisd=no/isisd=yes/' /etc/frr/daemons
sudo systemctl reload frr

When you are ready to retire the shipped OSPF demonstration and run only your own configuration, disable the demo units and clear the demo stanzas from /etc/frr/frr.conf:

sudo systemctl disable --now frr-demo-peer.service frr-demo-topology.service
sudo vtysh -c "configure terminal" -c "no router ospf" -c "end" -c "write memory"

Real world use cases

BGP route reflector or route server. Peer several routers with this instance so they exchange routes through it instead of a full mesh. The instance runs bgpd and holds the routing information. It does not itself have to carry the data plane traffic.
Dynamic routing to on-premises. Bring up a VPN or AWS Direct Connect tunnel to your data center and run BGP or OSPF over it. Routes are then exchanged automatically as your networks change, rather than being maintained by hand.
Overlay and software routing. Use FRR as the control plane for GRE, VXLAN or WireGuard overlays, distributing reachability with a routing protocol.
Learning and testing lab. Study BGP, OSPF, IS-IS and the other protocols against a real, current FRR build. The shipped OSPF demonstration is a working example to build on.

For steering traffic between subnets inside a single VPC, the AWS VPC route table remains the mechanism AWS uses. FRR on an instance complements it as a routing speaker and control plane rather than replacing it.

Updating and maintenance

The image installs FRR from the official FRR stable APT repository and adds that origin to the unattended upgrades allow list, so the instance keeps receiving FRR security updates alongside the base Ubuntu updates. To update manually:

$
sudo apt-get update $
sudo apt-get upgrade

Back up your routing configuration by copying /etc/frr/frr.conf and /etc/frr/daemons somewhere safe. After a configuration change, run write memory in vtysh to save the running configuration back to /etc/frr/frr.conf.

Support

SecureAnyCloud provides this image with 24/7 technical support by email and chat. Support covers deployment, BGP and OSPF peering design, route reflectors and route servers, connecting dynamic routing to on-premises networks over a tunnel, and upgrade planning. Visit secureanycloud.com for more information.

FRRouting and FRR are trademarks of their respective holders. This product is not affiliated with, sponsored by, or endorsed by The FRRouting Project or the Linux Foundation.

Deploy on AWS

Launch FRRouting on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS