Configuring IP Failover over BGP using FRR (Advanced)
Traducciones al EspañolEstamos 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.
NoteNot 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.
Set the hostname and updated the hosts file.
Verify Python3 is installed. See FRR’s official documentation to learn about FRR’s Python dependencies.
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
Set the FRR environment variable to the version you would like to install. The possible values are
frr-6
,frr-7
,frr-8
, andfrr-stable
, though it is recommended to usefrr-stable
to install the latest stable version.FRRVER="frr-stable"
Note
For more information on FRR versions, see the FRR Debian repository and FRR’s Github Releases.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
Add FRR’s GPG key:
curl -s https://deb.frrouting.org/frr/keys.asc | sudo apt-key add -
Add FRR’s Debian repository to your system’s source’s list:
echo deb https://deb.frrouting.org/frr $(lsb_release -s -c) $FRRVER | sudo tee -a /etc/apt/sources.list.d/frr.list
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.
Set the FRR environment variable to the version you would like to install. The possible values are
frr-6
,frr-7
,frr-8
, andfrr-stable
, though it is recommended to usefrr-stable
to install the latest stable version.FRRVER="frr-stable"
Note
For more information on FRR versions, see the FRR RPM repository and FRR’s Github Releases.Add FRR’s RPM repository to your system:
CentOS/RHEL 8
curl -O https://rpm.frrouting.org/repo/$FRRVER-repo-1-0.el8.noarch.rpm sudo dnf install ./$FRRVER*
CentOS/RHEL 7
curl -O https://rpm.frrouting.org/repo/$FRRVER-repo-1-0.el7.noarch.rpm sudo yum install ./$FRRVER*
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.
Using a text editor of your choice, enable the
bgpd
daemon by updating its value toyes
in the FRR daemons configuration file:- File: /etc/frr/daemons
1 2 3
# The watchfrr and zebra daemons are always started. # bgpd=yes
Restart the FRR service:
sudo systemctl restart frr.service
Configure FRR
With FRR installed, you can now configure it to enable IP failover.
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:atl-bgp-1.example.com
). - 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 theprimary
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
- Atlanta (USA):
- Shared IP address (
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
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 ebgp-multihop 10 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 exit-address-family address-family ipv6 unicast network [SHARED_IPV6]/64 route-map [ROLE] redistribute static exit-address-family route-map primary permit 10 set community 65000:1 route-map secondary permit 10 set community 65000:2 ipv6 nht resolve-via-default
Restart the FRR service:
sudo systemctl restart frr
Configure the Network Interface
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.1 2
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/05-eth0.network
file by adding anAddress
entry for the Shared IP.1 2 3 4
[Match] Name=eth0 ... Address=[SHARED_IP]/32
CentOS 8
Edit the
/etc/sysconfig/network-scripts/ifcfg-eth0
file with the following entry.1 2
IPADDR1=[SHARED_IP] PREFIX1="32"
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
Ensure that your network interface configurations have been applied as expected:
ip a | grep inet
You should see a similar output:
inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host inet 192.0.2.0/24 brd 192.0.2.255 scope global dynamic eth0 inet 203.0.113.0/32 scope global eth0 inet6 2600:3c04::f03c:92ff:fe7f:5774/64 scope global dynamic mngtmpaddr inet6 fe80::f03c:92ff:fe7f:5774/64 scope link
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