Configuring IP Failover over BGP using FRR (Advanced)

Traducciones al Español
Estamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
Create a Linode account to try this guide with a $100 credit.
This credit will be applied to any valid services used during your first 60 days.
Not all data centers supports configuring IP failover over BGP. Review the Configuring IP Failover on a Compute Instance to learn more about IP Sharing / IP failover availability within each data center.

This guide covers using the open source FRRouting (FRR) tool to configure IP failover with Linode Compute Instances. FRR is a routing service that uses BGP to monitor and fail over components in a high availability configuration. In a typical setup with IP failover, there is a primary Instance and a secondary Instance.

  • Primary: The primary Compute Instance is the one containing the IP address you’d like to configure for IP failover.
  • Secondary: The secondary Compute Instance is then configured to use that IP address in the event the primary Instance stops responding.

Before You Begin

Prior to following this guide, ensure the following has been done on each Compute Instance used within your IP failover strategy.

  1. Set the hostname and updated the hosts file.

  2. Verify Python3 is installed. See FRR’s official documentation to learn about FRR’s Python dependencies.

  3. Disable Network Helper.

Configure IP Sharing

Before using FRR to configure IP failover for a public or private IPv4 address (not VLANs), you first need to use Linode’s IP Sharing feature to share your IP address with other Compute Instances. To do so, follow the instructions within the Configuring IP Sharing section of the Managing IP Addresses guide for each secondary Compute Instance.

Install FRR

This section provides instructions for installing FRR on Debian, Ubuntu, and CentOS systems through their native package managers. If you’re using a different distribution or prefer to install FRR from source, follow FRR’s official installation instructions to install FRR using git.

Debian and Ubuntu

Supported distributions: Ubuntu 20.04, 18.04, and 16.04 | Debian 11, 10, and 9

  1. Set the FRR environment variable to the version you would like to install. The possible values are frr-6, frr-7, frr-8, and frr-stable, though it is recommended to use frr-stable to install the latest stable version.

    For more information on FRR versions, see the FRR Debian repository and FRR’s Github Releases.
  2. If you’re running an older Debian-based system, you may need to install the packages below, which come default with most modern Debian-based distributions.

    sudo apt install apt-transport-https gnupg
  3. Add FRR’s GPG key:

    curl -s | sudo apt-key add -
  4. Add FRR’s Debian repository to your system’s source’s list:

    echo deb $(lsb_release -s -c) $FRRVER | sudo tee -a /etc/apt/sources.list.d/frr.list
  5. Install FRR:

    sudo apt update && sudo apt install frr frr-pythontools

CentOS/RHEL 7 and 8

Supported distributions: CentOS Stream 9 (and 8), CentOS 8 (and 7), other RHEL derivatives (including AlmaLinux 8, and Rocky Linux 8), and Fedora.

  1. Set the FRR environment variable to the version you would like to install. The possible values are frr-6, frr-7, frr-8, and frr-stable, though it is recommended to use frr-stable to install the latest stable version.

    For more information on FRR versions, see the FRR RPM repository and FRR’s Github Releases.
  2. Add FRR’s RPM repository to your system:

    • CentOS/RHEL 8

      curl -O$FRRVER-repo-1-0.el8.noarch.rpm
      sudo dnf install ./$FRRVER*
    • CentOS/RHEL 7

      curl -O$FRRVER-repo-1-0.el7.noarch.rpm
      sudo yum install ./$FRRVER*
  3. Install FRR:

    • CentOS/RHEL 8

      sudo dnf install frr frr-pythontools
    • CentOS/RHEL 7

      sudo yum install frr frr-pythontools

Enable BGP within FRR

FRR works using a variety of protocols. Since we’re using FRR for its BGP support, the next step is to explicitly enable the bgpd daemon.

  1. Using a text editor of your choice, enable the bgpd daemon by updating its value to yes in the FRR daemons configuration file:

    File: /etc/frr/daemons
    # The watchfrr and zebra daemons are always started.
  2. Restart the FRR service:

    sudo systemctl restart frr.service

Configure FRR

With FRR installed, you can now configure it to enable IP failover.

  1. Gather the following information, which is required for the next step:

    • Shared IP address ([SHARED_IP]): The shared IP address you’ve configured for both the primary and secondary instances. See Configure IP Sharing.
    • Hostname ([HOSTNAME]): The hostname defined on the Compute Instance you are configuring (ex:
    • Role ([ROLE]): The role of this Compute Instance within your failover strategy.
      • primary: All requests are routed to this Compute Instance, provided it is accessible.
      • secondary: If the primary instance fails, all requests are routed to this Compute Instance, provided it is accessible.
    • Data center ID ([DC_ID]): The ID of this data center as defined by the list below:
      • Atlanta (USA): 4
      • Dallas (USA): 2
      • Frankfurt (Germany): 10
      • Fremont (USA): 3
      • London (UK): 7
      • Mumbai (India): 14
      • Newark (USA): 6
      • Singapore: 9
      • Sydney (Australia): 16
      • Tokyo (Japan): 11
      • Toronto (Canada): 15
  2. Edit the /etc/frr/frr.conf file and add the following lines. Ensure you replace any instances of [SHARED_IP], [HOSTNAME], [ROLE], and [DC_ID] as outlined above.

    File: /etc/frr/frr.conf
    hostname [HOSTNAME]
    router bgp 65001
    no bgp ebgp-requires-policy
    coalesce-time 1000
    bgp bestpath as-path multipath-relax
    neighbor RS peer-group
    neighbor RS remote-as external
    neighbor RS capability extended-nexthop
    neighbor 2600:3c0f:[DC_ID]:34::1 peer-group RS
    neighbor 2600:3c0f:[DC_ID]:34::2 peer-group RS
    neighbor 2600:3c0f:[DC_ID]:34::3 peer-group RS
    neighbor 2600:3c0f:[DC_ID]:34::4 peer-group RS
    address-family ipv4 unicast
      network [SHARED_IP]/32 route-map [ROLE]
      redistribute static
    route-map primary permit 10
    set community 65000:1
    route-map secondary permit 10
    set community 65000:2
  3. Restart the FRR service:

    sudo systemctl restart frr

Configure the Network Interface

  1. Configure the Compute Instance’s network interface as detailed below. Replace [SHARED_IP] with the Shared IP address you’ve configured.

    • Debian 10 & Ubuntu 18.04

      Edit the /etc/network/interfaces file with the following entries.

      up   ip addr add [SHARED_IP]/32 dev eth0 label eth0
      down ip addr del [SHARED_IP]/32 dev eth0 label eth0
    • Ubuntu 20.04

      Edit the /etc/systemd/network/ file by adding an Address entry for the Shared IP.

    • CentOS 8

      Edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file with the following entry.

  2. Apply the eth0 network interface configuration:

    • Debian, Ubuntu 18.04 (and earlier), and CentOS/RHEL

      sudo ifdown eth0 && sudo ifup eth0
    • Ubuntu 20.04 (and later)

      systemctl restart systemd-networkd
  3. Ensure that your network interface configurations have been applied as expected:

    ip a | grep inet

    You should see a similar output:

    inet scope host lo
    inet6 ::1/128 scope host
    inet brd scope global dynamic eth0
    inet scope global eth0
    inet6 2600:3c04::f03c:92ff:fe7f:5774/64 scope global dynamic mngtmpaddr
    inet6 fe80::f03c:92ff:fe7f:5774/64 scope link
  4. Restart the FRR service:

    sudo systemctl restart frr.service

Test Shared IPs

Depending on how you configured your Compute Instances and Shared IP(s), testing steps may vary. In general, you can use the ping command to test sending packets to your Shared IP from a separate instance, your workstation, or any other computer/server:

ping [SHARED_IP]

For example, if you have two Compute Instances configured with the same Shared IP:

  • Ping the Shared IP when both instances are up. The packets should be received by the primary instance.

  • Shut down the primary instance and ping the Shared IP. The packets should be received by the secondary instance.

In each testing scenario, you can monitor ping traffic on a Compute Instance by inspecting icmp packets with the tcpdump command.

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

This page was originally published on

Your Feedback Is Important

Let us know if this guide made it easy to get the answer you needed.

Join the conversation.
Read other comments or post your own below. Comments must be respectful, constructive, and relevant to the topic of the guide. Do not post external links or advertisements. Before posting, consider if your comment would be better addressed by contacting our Support team or asking on our Community Site.