All Exoscale instances include a native IPv4 address leased from a global pool. This address is strongly coupled to the Compute instance itself: when you destroy the instance, you release the IP address to the global pool with no guarantee that you will ever get the same IP address again next time you spawn a new instance.

There are however various cases where you may want an IP address to persist.

An Elastic IP (EIP) is an Exoscale resource leasing an individual IP address to your Organization. You can then associate it to one or several Compute instances in addition to their native IP address.

The simplest use case for this feature is to use an EIP as a persistent IP address you can move between instances. This allows you to overcome the IP address change on destroying an Instance. With an EIP, you can simply switch the underlying virtual machine and point traffic to the same address all the time.

Another possible use case would be having the need for several IP addresses on the same machine, e.g. to use multiple TLS certificates or run several instances of the same service.

EIP types

EIPs come in two flavors:

  • Manual
  • Managed

By default, both have the same basic behavior:

  • EIPs are reserved for your organization and will be available until you decide to explicitly release them.
  • EIPs are bound to a Zone. Only EIPs belonging to the same Zone as a Compute instances can be associated to them.
  • EIPs can be associated to one or multiple Instances at all times.
  • All incoming traffic towards an EIP is redirected to the associated Instances.
  • All outgoing traffic is still emitted by the internal IP address associated to the Instance itself: it will not be seen as coming from the EIP.
  • When multiple Instances are associated to an EIP a traffic aimed at the EIP is distributed to associated instances with no even load distribution guarantee.

On top of this, both have some distinct characteristics, and their behavior can be customized.

Managed EIP

Managed EIPs require no action from your side on the Instance itself. Once associated to an instance, the managed EIP transparently routes traffic to it. Moreover, a managed EIP has some basic health check capability, routing traffic only to healthy Instances. As a compromise:

  • Instances associated to a managed EIP see incoming traffic as it was coming from the native IP address (meaning you cannot differentiate traffic based on the target IP)
  • You cannot overcome the fact that the outgoing traffic is still originated from the native IP address, in contrast to manual EIPs.

Manual EIP

Manual EIPs need to be manually enabled on the Instance itself. This usually allows for more flexibility at the expense of more manual configuration. Distinct characteristics of manual EIPs include:

  • Internally, Instances associated to a manual EIP see traffic coming to the EIP address, in contrast to managed EIPs where incoming traffic is seen as coming to the native IP address of the Instance it is associated to.
  • Instances associated to a manual EIP can use it as source for outgoing traffic with some limitations.

Reserving an EIP

To use an EIP, the first step is to reserve it. This can be done through all supported tools, would it be our web application, our CLI, or API.

This is what it looks like in the CLI:

# Reserve a manual EIP
$ exo compute elastic-ip create --zone de-fra-1
 ✔ Creating Elastic IP... 3s
┼─────────────┼──────────────────────────────────────┼
│ ELASTIC IP  │                                      │
┼─────────────┼──────────────────────────────────────┼
│ ID          │ 5a5aed48-7a46-442a-8456-0a15d931fd0b │
│ IP Address  │ 194.182.170.202                      │
│ Description │                                      │
│ Zone        │ de-fra-1                             │
│ Type        │ manual                               │
┼─────────────┼──────────────────────────────────────┼

# Reserve a managed EIP
$ exo compute elastic-ip create  \
  --zone de-fra-1                \
  --healthcheck-interval 60      \
  --healthcheck-mode tcp         \
  --healthcheck-port 80          \
  --healthcheck-strikes-fail 5   \
  --healthcheck-strikes-ok 5     \
  --healthcheck-timeout 10
 ✔ Creating Elastic IP... 3s
┼──────────────────────────┼──────────────────────────────────────┼
│        ELASTIC IP        │                                      │
┼──────────────────────────┼──────────────────────────────────────┼
│ ID                       │ 868d029d-b1a2-4fd3-9006-4b98998240b4 │
│ IP Address               │ 89.145.161.64                        │
│ Description              │                                      │
│ Zone                     │ de-fra-1                             │
│ Type                     │ managed                              │
│ Healthcheck Mode         │ tcp                                  │
│ Healthcheck Port         │ 80                                   │
│ Healthcheck Interval     │ 1m0s                                 │
│ Healthcheck Timeout      │ 10s                                  │
│ Healthcheck Strikes OK   │ 5                                    │
│ Healthcheck Strikes Fail │ 5                                    │
┼──────────────────────────┼──────────────────────────────────────┼

As you can see, in order to reserve a managed EIP you have to provide the required health check parameters. Without those parameters the EIP is created as manual.

Associate an EIP to a Compute instance

Once the EIP as been reserved you can then associate it to one or more Compute instances.

$ exo compute instance elastic-ip attach my-instance 89.145.160.61
 ✔ Attaching Elastic IP "89.145.160.61" to instance "my-instance"... 3s
┼──────────────────────┼──────────────────────────────────────┼
│   COMPUTE INSTANCE   │                                      │
┼──────────────────────┼──────────────────────────────────────┼
│ ID                   │ 0e713d4c-9f3f-4a9a-b958-b4571450d3a8 │
│ Name                 │ my-instance                          │
│ Creation Date        │ 2019-03-08 15:07:14 +0000 UTC        │
│ Instance Type        │ standard.tiny                        │
│ Template             │ Linux Ubuntu 18.04 LTS 64-bit        │
│ Zone                 │ ch-gva-2                             │
│ Anti-Affinity Groups │ n/a                                  │
│ Security Groups      │ default                              │
│ Private Networks     │ n/a                                  │
│ Elastic IPs          │ 89.145.160.61                        │
│ IP Address           │ 185.19.30.32                         │
│ IPv6 Address         │ 2a04:c43:e00:588:4fe:9cef:fe00:23f   │
│ SSH Key              │ admin                                │
│ Disk Size            │ 10 GiB                               │
│ State                │ running                              │
│ Labels               │ n/a                                  │
┼──────────────────────┼──────────────────────────────────────┼

The EIP is now routing traffic to my-instance.

Once associated to an Instance, a managed EIP does not require explicitly configuring an extra network interface on the Instance. A manual EIP instead requires further configuration.

Managed Elastic IP Health Check Options

Managed EIP do have an integrated health check. The health check test will be periodically performed on the associated Instances in order to prevent sending ingress traffic to a virtual machine that is unable to receive it, like in the case of a maintenance or a crash.

The health check can be configured in one of the following modes:

  • TCP: check that a TCP connection can be successfully established on a given port
  • HTTP: check that an HTTP request can be successfully performed on a given port and URL path. HTTP checks are considered failed if the response status code is equal or greater than 400. Redirects are not followed.

In either mode, you can further configure the following parameters:

  • Interval: the time in seconds to wait between 2 health check tests (default: 10s)
  • Timeout: the time in seconds after which an unresponsive health check test is considered failed (default: 2s)
  • Strikes Fail: the minimum number of failed tests before considering an Instance unhealthy (default: 3)
  • Strikes OK: the minimum number of successful tests before considering an Instance healthy (default: 2)

Note

Currently is not possible to retrieve the health status of an Instance: while the system will not direct traffic to an unhealthy Instance, the internal state of associated Instances is not exposed.

Configure a Manual EIP on an Instance

Manual EIPs require additional configuration on the target Instance for the latter to receive traffic.

Warning

The EIP address is set up as an additional IP address for your Instance: the original IP address will still work and is used for outgoing connections. You must not remove the original IP address of the Instance as the EIP won’t work without it, and several other native functionalities will break.

The operations and commands to be performed vary depending on your chosen Template. Here following are some examples.

Ubuntu Bionic

In /etc/netplan/51-eip.yaml, put the following snippet.

network:
  version: 2
  renderer: networkd
  ethernets:
    lo:
      match:
        name: lo
      addresses:
        - 159.100.241.235/32

And then, apply it: sudo netplan apply

Debian / Ubuntu (Xenial and lower)

In /etc/network/interfaces.d/eip.cfg, add the following snippet.

auto lo:1
iface lo:1 inet static
    address 159.100.241.235/32

Then, use ifup lo:1 to enable the EIP. It will also be enabled automatically on boot. From here, you should be able to ping your Instance and any service authorized in the associated security group should be reachable with this EIP as well.

If you need to add any additional EIPs, use lo:2, lo:3, etc.

On Debian 8, you have to add source /etc/network/interfaces.d/* in your /etc/network/interfaces.

CentOS

Create a /etc/sysconfig/network-scripts/ifcfg-lo:1 file with the following content:

DEVICE=lo:1
IPADDR=159.100.241.235
NETMASK=255.255.255.255
ONBOOT=yes
NAME=lo1

Then, use ifup lo:1 to enable the EIP. It will also be enabled automatically on boot. You should be able to ping the EIP address and any service authorized in the associated security group should be reachable with this EIP as well.

If you need to add any additional EIPs, use lo:2, lo:3, etc.

CoreOS

Create the configuration file for loopback interface ‘/etc/systemd/network/loopback-alias.network’, with the following content:

[Match]
Name=lo

[Network]

[Address]
Label=lo:1
Address=159.100.241.235/32

Ensure that systemd-networkd is enable: sudo systemctl enable systemd-networkd.service

To apply the configuration, run sudo systemctl restart systemd-networkd to restart. It will also be enabled automatically on boot. You should be able to ping the EIP address and any service authorized in the associated security group should be reachable with this EIP as well.

You can add multiple loopback Address blocks.

Other Linux

You can manually add the EIP address on any Linux Instance with the following command:

ip addr add 159.100.241.235/32 dev lo

Beware this configuration will be lost if you reboot the Instance in absence of some custom automation.

OpenBSD

Configure your Elastic IP with this single command:

echo inet 159.100.241.235/32 > /etc/hostname.lo1

You can reconfigure your network on the fly with:

sh /etc/netstart

Since OpenBSD 6.7, it is now required to enable IP routing. This can be done via sysctl:

sysctl net.inet.ip.forwarding=1

# To persist the change upon reboot
echo net.inet.ip.forwarding=1 >> /etc/sysctl.conf

Windows

As a first step, we need to install a special driver. For this, open a command line and execute the following command:

hdwwiz

You should get the Add Hardware wizard:

Windows: add hardware

Click on Next. On the next screen, choose the second option:

Windows: add hardware

Click on Next. On the next screen, choose Network adapters:

Windows: add hardware

Click on Next. On the next screen, choose Microsoft in the left list, then Microsoft KM-TEST Loopback Adapter in the right list:

Windows: add hardware

Click on Next, then on Install.

Open a command-line and execute ipconfig /all. You should find an interface named Ethernet 2 whose description is Microsoft KM-TEST Loopback. Let’s rename it:

netsh interface set interface name="Ethernet 2" newname="Loopback"

You only need to execute those steps once per Instance.

To add the EIP, you now need to type the following command:

netsh interface ip add address Loopback 159.100.241.235 255.255.255.255

Use the same command when you need to add additional EIPs.

Manual EIP as Traffic Source

There are some cases where you may want to use EIP as a source IP address (for example, if you run an SMTP server).

It is possible to achieve that with manual EIPs for applications allowing you to configure their source IP. The traffic emitted in this setup is seen as coming from the EIP address and not from the native IP address.

For instance, with Postfix, you can add the following line in /etc/postfix/main.cf:

smtp_bind_address = 159.100.241.235

Most software have a similar setting for outgoing connections. Search for the bind keyword in the documentation.

Warning

EIP addresses should not be shared across multiple traffic-emitting Instances, as it will result in asymmetric routing for returning traffic.

Limitations

  • EIPs are initially limited to 5 per organization. You can ask for a limit increase in [the limits section of the web application][limits section.
  • Instances sharing a common EIP cannot communicate with each other by using the EIP address.
  • EIP will natively work only for incoming traffic. Outgoing traffic will still use the native Instance’s IP address as a source. This behavior can be partially overcome manually with manual EIPs.
  • Internally, instances associated to a managed EIP will see incoming traffic as coming through the native IP.
  • With managed EIPs it is currently not possible to retrieve the health status of an Instance: while the system will not direct traffic to a unhealthy Instance, there is no information about which Instance is in an unhealthy state.
  • HTTP health checks do not follow redirects.