leaseweb knowledge base logo - white color on the orange background
leaseweb knowledge base logo - white color on the orange background

Using Floating IPs

< Back

Using Floating IPs

How to use Floating IPs

Contents

What are Floating IPs

Floating IPs are a kind of virtual IP address that can be dynamically routed to any server in the same network.

Multiple servers can own the same Floating IP address, but it can only be active on one server at any given time.

Floating IPs can be used to:

  • Implement failover in a high-availability cluster
  • Implement zero-downtime Continuous Deployment
  • Keep the same IP address on a server, even when it is being relocated in the data center
  • Use your own IP addresses with IP Announcement on any server
  • Create a redundant firewall with stateful connection sync over our Private Network

How does it work?

A Floating IP address has a dynamic, one-to-one relation with an “Anchor” IP address. The Anchor IP address is the primary IP address of the server that the Floating IP address is being routed to.

This sounds complicated, but what it really means is that the Floating IP just piggybacks on another IP address, that you can choose and change at your leisure.

Via the Customer Portal and the Leaseweb API, the Floating IP ↔ Anchor IP relation can be updated real time, so you can direct traffic incoming on the Floating IP to the server of your choice.

Consider the following scenario. A user entering the Floating IP address 1.1.1.1 in their browser, its Anchor IP address is 2.2.2.2 , which belongs to server A. The user will be served the website running on server A.

When the Anchor IP is changed to 2.2.2.3, which belongs to server B, the same end user accessing the same website will be served the website running on server B.

This change is instant, without any perceptible downtime from the perspective of the end user.

Using Floating IPs

Using Floating IPs is quite simple, you can order them through the customer portal and set them up on your server as an additional IP address.

Demonstration

Taking the example from above, let’s setup two servers with a simple HTTP web server and use a Floating IP address to access the website of either one server.

  • Server A has IP address 212.32.230.75 and is installed with CentOS 7
  • Server B has IP address 212.32.230.66 and is installed with Ubuntu 18.04
  • 89.149.192.0 is the Floating IP address

Setting up the Floating IP address in the Customer Portal

  1. Login to the Leaseweb Customer Portal, and click Floating IP in the Dashboard.
    108199978
  2. In the Floating IPs page, click the Request Floating IPs button. 
    108199977
  3. In the Request Floating IPs page, select the Type (Metro or Site), the Location and the Amount of IPs required, select the Terms and Conditions checkbox, and click Ok.
    108199976

  4. After your request is processed a new Floating IP Range will be visible in the Customer Portal.
    108199975

  5. Clicking on Manage you will be redirected to a page with a list of all definitions for your range.
    108199974

  6. By clicking the Add Floating IP Definition button, it is possible to setup a relationship between a Floating IP and an Anchor IP. This is called a Floating IP Definition.
    108199973
    1. Floating IP ↔ Anchor IP
      1. A Floating IP Definition can have only one single active Anchor IP.
      2. That IP address must be associated to an device that belongs to your account.
    2. Passive Anchor IP
      1. You are allowed to register an Passive Anchor IP that must also be associated to an device that belongs to your account.
      2. When you have an Passive Anchor IP configured you enable the Anchor IP Toggling capability for that definition.
  7. There are actions available for you to manage the definition:
    1. Modify Flip: Here you are able to modify your definition, setting a new Anchor IP or a different Passive Anchor IP.

      108199941

    2. Toggle Anchor IP: This action allows you to quickly switch between Anchor IP and Passive Anchor IP and switch back whenever you want to.
      108199939
    3. Remove Flip: This action removes the definition.
      108199940

Setting up the Floating IP address on the servers

On a server, Floating IPs can be setup as any other additional IP address. A gateway address is not necessary, and the subnet mask is always 255.255.255.255, or /32 in CIDR notation.

To add an additional IP address to an interface in Linux without making the change persistent, we can simply use the
ip -4 address show
command to show which device the main IP address is configured on, and then do
ip address add /32 dev
to add the floating IP to the same device.

We also install a HTTP server and create a simple demo webpage:

Add Floating IP to server A (CentOS)
# Check which device we need to add the IP address to
ip -4 address show
ip address add 89.149.192.0/32 dev eno1

# The Floating IP address should now be visible on the device
ip -4 address show

# Install a web server and create a basic default webpage
yum install -y httpd
systemctl start httpd
cat < /var/www/html/index.html
> 
> 
> This is test server A
> 
This is test server A

> 
> EOF

Result:

tim@laptop:~$ ssh root@20483.lsw
[root@servera ~]# ip -4 address show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eno1:  mtu 1500 qdisc mq state UP group default qlen 1000
    inet 212.32.230.75/26 brd 212.32.230.127 scope global eno1
       valid_lft forever preferred_lft forever

[root@servera ~]# ip address add 89.149.192.0/32 dev eno1

[root@servera ~]# ip -4 address show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eno1:  mtu 1500 qdisc mq state UP group default qlen 1000
    inet 212.32.230.75/26 brd 212.32.230.127 scope global eno1
       valid_lft forever preferred_lft forever
    inet 89.149.192.0/32 scope global eno1
       valid_lft forever preferred_lft forever

[root@servera ~]# yum install -y httpd

[...]

[root@servera ~]# systemctl start httpd

[root@servera ~]# cat < /var/www/html/index.html
> 
> 
> This is test server A
> 
This is test server A

> 
> EOF

[root@servera ~]#

(note: ssh root@20483.lsw is a neat little trick explained here: https://gist.github.com/timwb/1f95737d54563aedd7c97d5e671667cc)

You should now already be able to ping the Floating IP address, and opening it in a browser loads the demo webpage:

107315207

Next, add the same Floating IP address to server B, install a HTTP web server and create a simple demo webpage:

Add Floating IP to server B (Ubuntu)
# Check which device we need to add the IP address to
ip -4 address show
ip address add 89.149.192.0/32 dev lo

# The Floating IP address should now be visible on the device
ip -4 address show

# Install a web server and create a basic default webpage
apt install -y nginx
cat < /var/www/html/index.html


This is test server B

This is test server B


EOF

Result:

tim@laptop:~$ ssh root@37089.lsw
root@serverb:~# ip -4 address show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp32s0:  mtu 1500 qdisc mq state UP group default qlen 1000
    inet 212.32.230.66/26 brd 212.32.230.127 scope global enp32s0
       valid_lft forever preferred_lft forever
3: enp34s0:  mtu 1500 qdisc mq state UP group default qlen 1000
    inet 10.32.18.208/27 brd 10.32.18.223 scope global enp34s0
       valid_lft forever preferred_lft forever

root@serverb:~# ip address add 89.149.192.0/32 dev lo

root@serverb:~# ip -4 address show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 89.149.192.0/32 scope host lo
       valid_lft forever preferred_lft forever 
2: enp32s0:  mtu 1500 qdisc mq state UP group default qlen 1000
    inet 212.32.230.66/26 brd 212.32.230.127 scope global enp32s0
       valid_lft forever preferred_lft forever
3: enp34s0:  mtu 1500 qdisc mq state UP group default qlen 1000
    inet 10.32.18.208/27 brd 10.32.18.223 scope global enp34s0
       valid_lft forever preferred_lft forever

root@serverb:~# apt install -y nginx

[...]

root@serverb:~# cat < /var/www/html/index.html
> 
> 
> This is test server B
> 
This is test server B

> 
> EOF

root@serverb:~#

FLIP’ing a Floating IP

Initially we’ve setup Floating IP 89.149.192.0 with Anchor IP 212.32.230.75, which belongs to server A.

Suppose we’ve built a new website on server B and after months of testing, it’s finally ready.

To direct users visiting 89.149.192.0 to server B, we need to update the Anchor IP of Floating IP 89.149.192.0, changing (FLIP’ing) it from 212.32.230.75 (server A) to 212.32.230.66 (server B).

To do this, you have to modify your definition by either Toggling the Anchor IP or Modifying the Floating IP Definition.

107315210

Now, when you refresh your browser, the page from server B is shown:

107315206

Congratulations, you’ve just set your first step towards a high availability, continuous deployment web hosting cluster.

Making the changes persistent on the servers

Since adding a Floating IP address is exactly like any other IP address, just follow the instructions at Adding an IPv6 address to your server

Using the API to manage Floating IPs

Of course, using the Customer Portal is a convenient way to setup and play Floating IPs, but the real power is in automation.

The official documentation of the Floating IPs API can be found on developer.leaseweb.com

In the following examples we’ll use curl to perform http requests and the jq tool to pretty-print the API responses, but you can use any tool or library for interacting with a RESTful API. You can find your API key (X-Lsw-Auth) in the Customer Portal under API

Information

Floating IPs and Floating IP ranges have a prefix length and are always written in CIDR notation. In the context of API calls, the forward slash “/” is replaced with an underscore “_” for compatibility in URLs. For a single Floating IP address (/32), the prefix length may be omitted.

List Floating IP ranges

To list your Floating IP ranges, make a GET request to /floatingIps/v2/ranges:
curl --silent --request GET --url https://api.leaseweb.com/floatingIps/v2/ranges --header 'X-Lsw-Auth: 213423-2134234-234234-23424' |jq

GET /floatingIps/v2/ranges
{
  "ranges": [
    {
      "id": "89.149.192.0_29",
      "range": "89.149.192.0/29",
      "customerId": "12345678",
      "salesOrgId": "2000",
      "pop": "AMS-01"
    }
  ],
  "_metadata": {
    "limit": 20,
    "offset": 0,
    "totalCount": 1
  }
}

List the Floating IP definitions in a Floating IP range

To list the Floating IP definitions within a certain Floating IP range, make a GET request to

GET /floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions
{
  "floatingIpDefinitions": [
    {
      "id": "89.149.192.0",
      "rangeId": "89.149.192.0_29",
      "pop": "AMS-01",
      "customerId": "12345678",
      "salesOrgId": "2000",
      "floatingIp": "89.149.192.0/32",
      "anchorIp": "212.32.230.66",
      "passiveAnchorIp": "212.32.230.75",
      "status": "ACTIVE",
      "createdAt": "2019-06-17T14:15:11+00:00",
      "updatedAt": "2019-06-26T09:26:52+00:00"
    }
  ],
  "_metadata": {
    "totalCount": 1,
    "limit": 20,
    "offset": 0
  }

POST /floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions
{
  "id": "89.149.192.3",
  "rangeId": "89.149.192.0_29",
  "pop": "AMS-01",
  "customerId": "12345678",
  "salesOrgId": "2000",
  "floatingIp": "89.149.192.3/32",
  "anchorIp": "212.32.230.66",
  "passiveAnchorIp": null,
  "status": "CREATING",
  "createdAt": "2019-06-26T14:30:40+00:00",
  "updatedAt": "2019-06-26T14:30:40+00:00"
}

GET /floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions
{
  "floatingIpDefinitions": [
    {
      "id": "89.149.192.0",
      "rangeId": "89.149.192.0_29",
      "pop": "AMS-01",
      "customerId": "12345678",
      "salesOrgId": "2000",
      "floatingIp": "89.149.192.0/32",
      "anchorIp": "212.32.230.66",
      "passiveAnchorIp": null,
      "status": "ACTIVE",
      "createdAt": "2019-06-17T14:15:11+00:00",
      "updatedAt": "2019-06-26T14:23:58+00:00"
    },
    {
      "id": "89.149.192.3",
      "rangeId": "89.149.192.0_29",
      "pop": "AMS-01",
      "customerId": "12345678",
      "salesOrgId": "2000",
      "floatingIp": "89.149.192.3/32",
      "anchorIp": "212.32.230.66",
      "passiveAnchorIp": null,
      "status": "ACTIVE",
      "createdAt": "2019-06-26T14:30:40+00:00",
      "updatedAt": "2019-06-26T14:30:45+00:00"
    }
  ],
  "_metadata": {
    "totalCount": 2,
    "limit": 20,
    "offset": 0
  }
}

updating 89.149.192.0 with Anchor IP 212.32.230.75, so we’re directing traffic back to server A again. You can also optionally provide a Passive Anchor IP in case you have plans to switch back the anchors.

curl --silent --request PUT --url https://api.leaseweb.com/floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions/89.149.192.0_32 --header 'X-Lsw-Auth: ' --header 'content-type: application/json' --data '{
    "anchorIp": "212.32.230.75",
    "passiveAnchorIp": "212.32.230.66"
}' |jq

PUT /floatingIps/v2/ranges89.149.192.0_29/floatingIpDefinitions/89.149.192.0_32
{
  "id": "89.149.192.0",
  "rangeId": "89.149.192.0_29",
  "pop": "AMS-01",
  "customerId": "12345678",
  "salesOrgId": "2000",
  "floatingIp": "89.149.192.0/32",
  "anchorIp": "212.32.230.66",
  "passiveAnchorIp": null,
  "status": "UPDATING",
  "createdAt": "2019-06-17T14:15:11+00:00",
  "updatedAt": "2019-06-26T14:35:57+00:00"
}

Note that in the response, the old Anchor IP is still listed and the status is changed to UPDATING. The update process is very fast, but not instantaneous. When making another GET request to , you can see that the update has processed seconds later:

GET /floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions
{
  "floatingIpDefinitions": [
    {
      "id": "89.149.192.0",
      "rangeId": "89.149.192.0_29",
      "pop": "AMS-01",
      "customerId": "12345678",
      "salesOrgId": "2000",
      "floatingIp": "89.149.192.0/32",
      "anchorIp": "212.32.230.75",
      "passiveAnchorIp": "212.32.230.68",
      "status": "ACTIVE",
      "createdAt": "2019-06-17T14:15:11+00:00",
      "updatedAt": "2019-06-26T14:36:01+00:00"
    }
  ],
  "_metadata": {
    "totalCount": 1,
    "limit": 20,
    "offset": 0
  }
}

Toggling Anchor IPs of a Floating IP definition

Imagine you to even more easily switch the Floating IP anchors between Server A and Server B.

With this PUT request you can toggle the Anchor IP address to point to, in this example, Server B, or any other server registered as the Passive Anchor IP. Within a matter of seconds the Anchor IP and the Passive Anchor IP will switch places and all the traffic destined for the Floating IP will now end up at the new Anchor IP:

curl --silent --request POST --url https://api.leaseweb.com/floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions/89.149.192.0/toggleAnchorIp --header 'X-Lsw-Auth: ' |jq

PUT /floatingIps/v2/ranges89.149.192.0_29/floatingIpDefinitions/89.149.192.0_32
{     
  "id": "89.149.192.0",
  "rangeId": "89.149.192.0_29",
  "pop": "AMS-01",
  "customerId": "12345678",
  "salesOrgId": "2000",
  "floatingIp": "89.149.192.0/32",
  "anchorIp": "212.32.230.75",
  "passiveAnchorIp": "212.32.230.68",
  "status": "UPDATING",
  "createdAt": "2019-06-17T14:15:11+00:00",
  "updatedAt": "2019-06-26T14:36:01+00:00" 
}

Note that in the response, the old Anchor IP is still listed and the status is changed to UPDATING. The update process is very fast, but not instantaneous. When making another GET request to , you can see that the update has processed seconds later:

Delete a Floating IP definition

Removing a Floating IP definition is as easy as making a DELETE call to :
curl --silent --request DELETE --url https://api.leaseweb.com/floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions/89.149.192.3 --header 'X-Lsw-Auth: ' |jq

DELETE /floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions/89.149.192.3
{
  "id": "89.149.192.3",
  "rangeId": "89.149.192.0_29",
  "pop": "AMS-01",
  "customerId": "12345678",
  "salesOrgId": "2000",
  "floatingIp": "89.149.192.3/32",
  "anchorIp": "212.32.230.66",
  "passiveAnchorIp": null, 
  "status": "REMOVING",
  "createdAt": "2019-06-26T14:30:40+00:00",
  "updatedAt": "2019-06-26T14:39:34+00:00"
}

Just like with the POST and PUT calls, it will take a couple of seconds to process.

Putting it all together – creating a highly available web server setup with Keepalived

Keepalived is a versatile piece of software that can be used to implement automatic failover using the Floating IPs API. In this example we’ll demonstrate how to create a simple active/backup setup where the Floating IP is automatically routed to server B in the event that server A fails.

It can do many more things, and keep in mind this is meant as a proof-of-concept example only, meant to demonstrate the functionality of Floating IPs in the simplest possible way.

The keepalived configuration

After installing, the configuration of keepalived resides in the /etc/keepalived/keepalived.conf file. In this file, we’ll instruct keepalived to:

  • Create a “vrrp” instance named webservers with id 123:
    Note: the id can be any random number between 0-255, but it needs to be the same between all servers.
    vrrp_instance webservers { ... }
    virtual_router_id
  • Setup server A to be the master, with priority 200:
    state MASTER
    priority 200
  • Setup server B to be the backup, with priority 100:
    state BACKUP
    priority 100
  • Communicate with each other using a shared secret:
    interface (see the instructions under Setting up the Floating IP address on the servers)
    unicast_src_IP
    unicast_peer { }
    authentication { ... }
  • Run a script to update the Anchor IP when either server becomes master
    notify_master /etc/keepalived/becomemaster.sh
  • Run a command to check if the web server is still running. On server A (CentOS) this is the httpd process, on server B (Ubuntu), this is the nginx process and we need to wrap the command in a small script instead.
    track_script { ... }

So, we run the following commands to setup server A:

Setup keepalived on server A (CentOS)
# Install keepalived
yum install -y keepalived

# Write keepalived config
cat < /etc/keepalived/keepalived.conf
vrrp_instance webservers {
    virtual_router_id 123
    state MASTER
    priority 200
    interface eno1
    unicast_src_ip 212.32.230.75
    unicast_peer {
        212.32.230.66
    }
    authentication {
        auth_type PASS
        auth_pass supersecret
    }
    notify_master /etc/keepalived/becomemaster.sh
    track_script {
        chk_apache
    }
}

vrrp_script chk_apache {
    script "/usr/sbin/pidof httpd"
    interval 2
}
EOF

# Write script that calls floating IP API to update the Floating IP with this server as Anchor IP
cat < /etc/keepalived/becomemaster.sh
#!/bin/sh
curl --silent --request PUT --url https://api.leaseweb.com/floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions/89.149.192.0_32 --header 'X-Lsw-Auth: '"213423-2134234-234234-23424" --header 'content-type: application/json' --data '{ "anchorIp": "212.32.230.75" }'
EOF
chmod +x /etc/keepalived/becomemaster.sh

# Restart keepalived
systemctl restart keepalived

# Check keepalived status
systemctl status keepalived

Result:

tim@laptop:~$ ssh root@20483.lsw
[root@servera ~]# yum install -y keepalived

[...]

[root@servera ~]# cat < /etc/keepalived/keepalived.conf
> vrrp_instance webservers {
>     virtual_router_id 123
>     state MASTER
>     priority 200
>     interface eno1
>     unicast_src_ip 212.32.230.75
>     unicast_peer {
>         212.32.230.66
>     }
>     authentication {
>         auth_type PASS
>         auth_pass supersecret
>     }
>     notify_master /etc/keepalived/becomemaster.sh
>     track_script {
>         chk_apache
>     }
> }
>
> vrrp_script chk_apache {
>     script "/usr/sbin/pidof httpd"
>     interval 2
> }
> EOF

[root@servera ~]# cat < /etc/keepalived/becomemaster.sh
> #!/bin/sh
> curl --silent --request PUT --url https://api.leaseweb.com/floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions/89.149.192.0_32 --header 'X-Lsw-Auth: '"213423-2134234-234234-23424" --header 'content-type: application/json' --data '{ "anchorIp": "212.32.230.75" }'
> EOF

[root@servera ~]# chmod +x /etc/keepalived/becomemaster.sh

[root@servera ~]# systemctl restart keepalived

[root@servera ~]# systemctl status keepalived
● keepalived.service - LVS and VRRP High Availability Monitor
   Loaded: loaded (/usr/lib/systemd/system/keepalived.service; disabled; vendor preset: disabled)
   Active: active (running) since Tue 2019-07-23 11:27:03 UTC; 30s ago
  Process: 1346 ExecStart=/usr/sbin/keepalived $KEEPALIVED_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 1347 (keepalived)
   CGroup: /system.slice/keepalived.service
           ├─1347 /usr/sbin/keepalived -D
           ├─1348 /usr/sbin/keepalived -D
           └─1349 /usr/sbin/keepalived -D

Jul 23 11:27:03 s20483 Keepalived_vrrp[1349]: Opening file '/etc/keepalived/keepalived.conf'.
Jul 23 11:27:03 s20483 Keepalived_vrrp[1349]: WARNING - default user 'keepalived_script' for script execution does not exist ...reate.
Jul 23 11:27:03 s20483 Keepalived_vrrp[1349]: Truncating auth_pass to 8 characters
Jul 23 11:27:03 s20483 Keepalived_vrrp[1349]: SECURITY VIOLATION - scripts are being executed but script_security not enabled.
Jul 23 11:27:03 s20483 Keepalived_vrrp[1349]: Using LinkWatch kernel netlink reflector...
Jul 23 11:27:03 s20483 Keepalived_vrrp[1349]: VRRP sockpool: [ifindex(2), proto(112), unicast(1), fd(10,11)]
Jul 23 11:27:03 s20483 Keepalived_vrrp[1349]: VRRP_Script(chk_apache) succeeded
Jul 23 11:27:04 s20483 Keepalived_vrrp[1349]: VRRP_Instance(webservers) Transition to MASTER STATE
Jul 23 11:27:05 s20483 Keepalived_vrrp[1349]: VRRP_Instance(webservers) Entering MASTER STATE
Jul 23 11:27:05 s20483 Keepalived_vrrp[1349]: Opening script file /etc/keepalived/becomemaster.sh
Hint: Some lines were ellipsized, use -l to show in full.

[root@servera ~]#

Then we setup server B:

Setup keepalived on server B (Ubuntu)
# Install keepalived
apt install -y keepalived

# Write keepalived config
cat < /etc/keepalived/keepalived.conf
vrrp_script chk_nginx {
    script "/etc/keepalived/chk_nginx.sh"
    interval 2
}

vrrp_instance webservers {
    virtual_router_id 123
    state BACKUP
    priority 100
    interface enp32s0
    unicast_src_ip 212.32.230.66
    unicast_peer {
        212.32.230.75
    }
    authentication {
        auth_type PASS
        auth_pass supersecret
    }
    notify_master /etc/keepalived/becomemaster.sh
    track_script {
        chk_nginx
    }
}
EOF

# Write script that calls floating IP API to update the Floating IP with this server as Anchor IP
cat < /etc/keepalived/becomemaster.sh
#!/bin/sh
curl --silent --request PUT --url https://api.leaseweb.com/floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions/89.149.192.0_32 --header 'X-Lsw-Auth: '"213423-2134234-234234-23424" --header 'content-type: application/json' --data '{ "anchorIp": "212.32.230.66" }'
EOF
chmod +x /etc/keepalived/becomemaster.sh

# Restart keepalived
systemctl restart keepalived

# Check keepalived status
systemctl status keepalived

Result:

tim@laptop:~$ ssh root@37089.lsw
[root@serverb ~]# apt install -y keepalived

[...]

[root@serverb ~]# cat < /etc/keepalived/keepalived.conf
> vrrp_instance webservers {
>     virtual_router_id 123
>     state BACKUP
>     priority 100
>     interface enp32s0
>     unicast_src_ip 212.32.230.66
>     unicast_peer {
>         212.32.230.75
>     }
>
>     authentication {
>         auth_type PASS
>         auth_pass supersecret
>     }
>
>     notify_master /etc/keepalived/becomemaster.sh
>
>     track_script {
>         chk_nginx
>     }
> }
>
> vrrp_script chk_nginx {
>     script "/etc/keepalived/chk_nginx.sh"
>     interval 2
> }
> EOF

[root@serverb ~]# cat < /etc/keepalived/becomemaster.sh
> #!/bin/sh
> curl --silent --request PUT --url https://api.leaseweb.com/floatingIps/v2/ranges/89.149.192.0_29/floatingIpDefinitions/89.149.192.0_32 --header 'X-Lsw-Auth: '"213423-2134234-234234-23424" --header 'content-type: > application/json' --data '{ "anchorIp": "212.32.230.66" }'
> EOF

[root@serverb ~]# cat < /etc/keepalived/chk_nginx.sh
> #!/bin/sh
> /bin/pidof nginx
> EOF

[root@serverb ~]# chmod +x /etc/keepalived/becomemaster.sh

[root@serverb ~]# systemctl restart keepalived

[root@serverb ~]# systemctl status keepalived
● keepalived.service - Keepalive Daemon (LVS and VRRP)
   Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-07-23 11:27:12 UTC; 48s ago
  Process: 24346 ExecStart=/usr/sbin/keepalived $DAEMON_ARGS (code=exited, status=0/SUCCESS)
 Main PID: 24355 (keepalived)
    Tasks: 3 (limit: 4574)
   CGroup: /system.slice/keepalived.service
           ├─24355 /usr/sbin/keepalived
           ├─24357 /usr/sbin/keepalived
           └─24358 /usr/sbin/keepalived

Jul 23 11:27:12 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: Registering Kernel netlink command channel
Jul 23 11:27:12 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: Registering gratuitous ARP shared channel
Jul 23 11:27:12 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: Opening file '/etc/keepalived/keepalived.conf'.
Jul 23 11:27:12 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: WARNING - default user 'keepalived_script' for script execution does not exist - please create.
Jul 23 11:27:12 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: Truncating auth_pass to 8 characters
Jul 23 11:27:12 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: SECURITY VIOLATION - scripts are being executed but script_security not enabled.
Jul 23 11:27:12 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: Using LinkWatch kernel netlink reflector...
Jul 23 11:27:12 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: VRRP_Instance(webservers) Entering BACKUP STATE
Jul 23 11:27:12 diy-dhcp-ams01-nl Keepalived_healthcheckers[24357]: Opening file '/etc/keepalived/keepalived.conf'.
Jul 23 11:27:12 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: VRRP_Script(chk_nginx) succeeded

[root@serverb ~]#


So now that we have our redundant setup and server A is the master. If we visit the Floating IP address in our browser, we see that it’s being served from server A:

107315205

Let’s simulate a failure on server A by shutting down the Apache web server with the and watch server B take over.

On server A, run:
systemctl stop httpd

Within a couple of seconds, you’ll see the it failover to server B. Feel free to hammer F5 like your life depends on it!

107315204

Looking at the logs of keepalived on server B, you can see that it detected the failure on server A and automatically executed the script to update the Anchor IP:

journalctl -u keepalived |tail

[ ... ]

Jul 23 11:51:43 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: VRRP_Instance(webservers) Transition to MASTER STATE
Jul 23 11:51:44 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: VRRP_Instance(webservers) Entering MASTER STATE
Jul 23 11:51:44 diy-dhcp-ams01-nl Keepalived_vrrp[24358]: Opening script file /etc/keepalived/becomemaster.sh

That’s it, you know have your own (minimal implementation of) a highly available web hosting cluster!

FAQs for using Floating IPs

Which IPs can I use as Anchor IPs?

Any IPv4 address that meets the following requirements can be used as Anchor IP address:

  • The Anchor IP address must belong to the same site (datacenter) as the Floating IP address
  • The Anchor IP address must be assigned to your account
  • The Anchor IP address cannot be a Floating IP address itself

This means you can use Floating IPs to route traffic to not just dedicated servers, but also servers, firwewalls or load balancers in private racks as well as shared and private colocation.

Virtual servers and private cloud cannot be used with Floating IPs at this moment, but we’re working to make that possible as well.

Can I convert my existing IPs into Floating IPs?

For normal IPs this is not possible. Floating IPs come from a separate block of IP addresses.

It is possible to convert IPs from a static route or from IP announcement to Floating IPs. If you’d like to do this, please contact your Account Manager.

Can Floating IPs be used for load balancing?

The traffic to a Floating IP can only be routed to a single Anchor IP at any given time, so it can be used to manage active/standby setups, but it cannot be used for load balancing.

Can Floating IPs be used with IPv6?

Using IPv6 for either Floating IPs or Anchor IPs is not possible.