FRRouting BGP on Linux: Dual-Uplink Failover Guide for Dedicated Servers

Many dedicated servers run with a single network cable and a single default route. If that uplink fails, the server is offline. With two upstream providers and BGP, the server keeps its IP addresses and moves traffic to the second provider in about a second.

In this guide, you will learn how to configure FRRouting BGP on a Linux dedicated server. If you have set up BGP on a MikroTik router, this will feel familiar. Peers, filters, and route maps work the same way, but the tool is different. Our BGP configuration on MikroTik VPS guide shows the RouterOS side.

You will build a small setup with one Linux server and two upstream providers. Here is the network plan for this guide:

• Both ISPs send you a default route (0.0.0.0/0). You accept only that route.
• You send only your own prefix 192.0.2.0/24 to both ISPs.
• ISP-A is preferred for outgoing traffic (local preference 200). ISP-B is the backup (local preference 100).
• BFD finds a dead link in about 1 second, and BGP moves traffic to the other ISP.

This small lab is a base you can reuse when you configure FRRouting BGP on Linux for a real server.

Note: The ASN 65010 and the IP ranges above are for a lab. For a real setup, use your own public ASN, your own IP block, and the link IPs and ASNs your providers give you.

Before you start to configure FRRouting BGP on a Linux dedicated server, make sure you have the items below:

• A Linux dedicated server with two network ports or two VLANs for the two uplinks. A PerLod dedicated server with routed IP space is a good option for this setup.
• Ubuntu 24.04 LTS. Also, these steps work on Ubuntu 22.04, Ubuntu 26.04, Debian 12, and Debian 13.
• Root or sudo access, and access for IPMI, KVM, or console. Routing changes can lock you out of SSH.
• For a lab: two more Linux machines or VMs to act as ISP-A and ISP-B.
• For a real setup: your own ASN, provider-independent IP space, and a BGP session from each provider.

Note: Ask your hosting provider if BGP sessions are allowed and which link IPs you should use.

Also, check your interface names with the command below. This guide uses eth0 and eth1. Replace them with your names:

Ubuntu and Debian include an FRR package, but it is usually an older version. To get FRR 10.7, you must use the official FRR repository. Its frr-10.7 branch installs FRR 10.7.x.

First, install the tools and add the FRR key with the commands below:

Then, add the repository and install FRR with the following commands:

Once you are done, check the version to verify the installation:

FRR runs each protocol as its own small program, called a daemon. BGP and BFD are off by default, so you must turn them on before you can use them. To do this, open the daemons file:

Find the following lines and change no to yes:

Once you are done, save and exit. Also, you can do the same with one command:

FRR keeps all its settings in one file, which is /etc/frr/frr.conf. You must run the command below to check that the FRR command-line shell, called vtysh, saves its changes to that file:

If you do not see service integrated-vtysh-config, you must add it with the command below:

Before FRR can route traffic, Linux needs a few settings. In this step, you must turn on IP forwarding, set up your link IPs, and open the firewall for BGP and BFD.

Your server must pass traffic between networks, so IP forwarding has to be on. With two uplinks, a reply can come back on a different network port than the one the request used. The default strict filter drops those packets, so you must also set the reverse path filter to loose mode (value 2).

First, create the following file, which holds your kernel settings for routing:

Add the following settings to the file:

Once you are done, save and exit. Then, apply it and check with the commands below:

If an interface still shows 1, you must set it too. Linux uses the higher value of all and the interface value:

Your server needs an IP address on each uplink to talk to your providers. Also, you need one more address for the router ID, which stays the same if a link goes down. You can set all three with a Netplan file.

First, create the Netplan file with the command below:

Add the following content to the file:

Note: Do not add a static default route. BGP will give you the default route. If your current Netplan file, for example, 50-cloud-init.yaml, already has one, remove it first. Keep console access ready in case you lose your SSH connection.

Then, set safe permissions and apply with a rollback timer:

Press Enter to accept. Then, check with the command below:

BGP uses TCP port 179. Single-hop BFD uses UDP port 3784. You must allow them only from your two providers. Example for UFW:

Now that your Linux server is ready, you can set up FRR. You must write the full config file. Back up the old file and open it with the commands below:

Delete the old content and paste this into the file:

Save and exit the file. Make sure the owner and mode are correct, then check the syntax and load it:

Note: If your provider needs a BGP password, add this line under router bgp 65010 for each neighbor. Use the password your provider gave you:

The config file has many lines, but each part has one clear job. This section explains them, so you know what each setting does before you go live.

ASN and router ID: router bgp 65010 starts BGP with your ASN. bgp router-id 192.0.2.1 sets a fixed ID. Always set it manually, so it does not change when an IP changes.

Prefix filters: PL-DEFAULT-ONLY lets in only the default route. PL-MY-NETS lets out only your own prefix. This stops you from leaking routes between your two providers and stops a provider from sending you a huge table. If you need more than the default route, change the first list, for example, permit 0.0.0.0/0 le 24, and plan for more memory. maximum-prefix 5 closes the session if a provider sends too many routes by mistake.

Also, FRR needs a policy on every eBGP session; bgp ebgp-requires-policy is on by default. Without an in and out route map, FRR accepts and sends nothing, and show bgp summary shows (Policy). Your route maps handle this.

Local preference: Local preference decides which path your server uses to send traffic out. The higher value wins. ISP-A has 200 and ISP-B has 100, so the server uses ISP-A until it fails.

MED and AS-path prepend: MED tells a neighbor which of your links you prefer for incoming traffic. The lower value wins. But BGP compares MED only between routes from the same neighbor AS. Because ISP-A and ISP-B are different ASes, MED will not move traffic between them. That is why ISP-B also gets an AS-path prepend. It makes the path through ISP-B longer, so the Internet prefers ISP-A to reach you. MED is still useful if one ISP has two links to you.

Graceful restart: bgp graceful-restart lets the neighbors keep your routes for a short time while bgpd restarts, so a planned restart or upgrade does not drop traffic. restart-time 120 is the default value, shown here so it is clear in the config. It is meant for daemon restarts. Link failures are handled by BFD.

BFD: BFD sends tiny packets every 300 ms. If 3 packets are lost, it tells BGP to close the session at once. Without BFD, BGP waits for the hold timer (180 seconds by default) before it notices a silent failure. You can lower the BFD timers (for example, 100 ms), but only on stable links.

Skip this part if you already have real providers. For a lab, use two more Linux machines and install FRR on them with Steps 1 and 2. Connect each one to a separate network port on your server, using its own cable, VLAN, or bridge.

On the ISP-A lab router, add the link IP and a test address that both ISPs will own:

Paste into /etc/frr/frr.conf file on ISP-A:

On the ISP-B lab router, repeat the same steps with these changes:

• Link IP: 203.0.113.1/30
• Hostname: isp-b
• BGP AS: router bgp 65002
• Router ID: bgp router-id 203.0.113.1
• Neighbor: 203.0.113.2
• Test address: add the same 198.18.0.100/32 on lo

Then, restart FRR on both routers with the following command:

Now check that everything works before you test a failover. Run the commands below on your server. They show whether both BGP sessions are up, whether BFD is running, and which routes you send and receive:

Also, you can run the command below to check the kernel table:

Also, you can configure FRRouting BGP on Linux to use both links at once. Use this only if both links have a similar speed and you want to share outgoing traffic. For plain failover, skip it.

BGP uses more than one path only when the paths are equal. So first, make both local preferences the same. Edit the file:

Change set local-preference 200 in RM-ISPA-IN to set local-preference 100. Then, add two lines to the BGP block. The first goes under router bgp 65010 and the second under address-family ipv4 unicast:

multipath-relax is needed because the two paths come from different ASes. Next, tell Linux to spread flows by IP and port:

The default route should now show two next hops. Multipath helps only the traffic that leaves your server. Incoming traffic still follows your prepend and MED settings. To go back to failover mode, you can undo these changes.

After you configure FRRouting BGP on Linux, always test failover before you move real traffic. Run these tests in the lab, or in a maintenance window on a real server. Use the console, not an SSH session via the link you are testing.

Start a ping from your router ID address. The address stays the same on both links:

In a second terminal, drop all incoming packets on eth0. This looks like a silent failure, where the link stays up, but traffic is lost:

After about 1 second, BFD goes down, and BGP closes the ISP-A session. Check with:

Now the route uses 203.0.113.1 on eth1, and the ping works again. You should lose only a few packets. Then, remove the rule with:

BGP and BFD come back up, and traffic returns to ISP-A because it has the higher local preference.

In this test, you can restart FRR while a ping runs to see how the connection behaves. First, check that both sides support graceful restart, then restart FRR while a ping runs:

Watch the ping and the BGP summary. The time to recover depends on your neighbor. Always test a planned restart in the lab.

In this test, you can add a test prefix and check that the filter blocks it. Only your own prefix should be sent to the providers:

Only 192.0.2.0/24 should appear. Then, remove the test prefix:

You can save your running config if you changed anything in vtysh:

If something does not work, you can use the table below to find the cause. Start with the problem you see, then check the settings listed beside it.

You can run the command below to watch FRR logs and check for errors:

For more network guides, you can check the Networking and Connectivity tutorials on PerLod.

At this point, you have learned how to configure FRRouting BGP on a Linux dedicated server with two providers, route filters, and failover. Before going live, use your real ASN and IPs, check your providers’ rules, and test failover again.

We hope you enjoy this guide. For more detailed information, you can check the FRRouting BGP documentation.

You can use PerLod dedicated servers with routed IP space or private lab networking to run advanced Linux routing workloads like this one.