EIPs

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.

There are various cases where you may want an IP address to persist, however. By creating an Elastic IP, you can have a specific IP address for your organization. You can then attach it to one or several instances in addition to their native IP address.

The simplest use case for this feature is to use an Elastic IP as a persistent IP address you can move between instances. This allows you to circumvent the IP address change on destroying an instance. With an Elastic IP, you can switch the underlying instance 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, such as to use multiple TLS certificates, or run several instances of the same service.

Elastic IP Types

Elastic IPs come in two management types:

  • Manual
  • Managed

By default, both have the same basic behavior:

  • Elastic IPs are created for your organization. An Elastic IP will be available until you decide to delete it.
  • Elastic IPs can be attached to one or multiple instances at any time.
  • Elastic IPs are bound to a zone. Elastic IPs can only be attached to Compute instances in the same zone.
  • All incoming traffic towards an Elastic IP is redirected to the attached instances.
  • All outgoing traffic is still sent by the internal IP address attached to the instance itself: it will not be seen as coming from the Elastic IP.
  • When multiple instances are attached to an Elastic IP, traffic aimed at the Elastic IP is distributed to those attached instances with no even load distribution guarantee.

On top of all this, both manual and managed Elastic IPs have distinct characteristics. Their behavior can also be customized.

Managed Elastic IP

Managed Elastic IPs require no action from your side on the instance itself. After a managed Elastic IP is attached to an instance, it transparently routes traffic to the instance. Moreover, a managed Elastic IP has some basic health check capabilities, routing traffic only to healthy instances. However, note that:

  • Instances attached to a managed Elastic IP see incoming traffic as if it is coming from the native IP address. This means you cannot differentiate traffic based on the target IP.
  • Outgoing traffic will always originate from the native IP address, in contrast to manual Elastic IPs.

Manual Elastic IP

Manual Elastic IPs need to be manually enabled on the instance. This management type allows for more flexibility, but requires more manual configuration. Distinct characteristics of manual Elastic IPs include:

  • Internally, instances attached to a manual Elastic IP see traffic coming to the Elastic IP address. This differs from managed Elastic IPs, where incoming traffic is seen as coming to the native IP address of the attached instance.
  • Instances attached to a manual Elastic IP can use it as a source for outgoing traffic, with some limitations.

Creating an Elastic IP

You can create an Elastic IP through the Portal, the CLI or the API.

This is an example from the CLI:

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

# Create a managed Elastic IP
$ 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               │ 203.0.113.203                        │
│ 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                                    │
┼──────────────────────────┼──────────────────────────────────────┼

Note that in order to create a managed Elastic IP, you have to provide health check parameters. Without those parameters, the Elastic IP is created as manual management type.

Attach an Elastic IP to a Compute instance

Once the Elastic IP address as been created, you can attach it to one or more Compute instances. Here is another example from the CLI:

$ exo compute instance elastic-ip attach my-instance 203.0.113.202
 ✔ Attaching Elastic IP "203.0.113.202" 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          │ 203.0.113.202                        │
│ IP Address           │ 203.0.113.20                         │
│ IPv6 Address         │ 2001:db8:e00:588:4fe:9cef:fe00:23f   │
│ SSH Key              │ admin                                │
│ Disk Size            │ 10 GiB                               │
│ State                │ running                              │
│ Labels               │ n/a                                  │
┼──────────────────────┼──────────────────────────────────────┼

The Elastic IP is now routing traffic to my-instance.

After an Elastic IP is attached to an instance, a managed Elastic IP does not require explicitly configuring an extra network interface on the instance. However, a manual Elastic IP requires some further configuration.

Managed Elastic IP Health Check Options

Managed Elastic IPs have an integrated health check. The health check will periodically run on the attached instances in order to prevent sending ingress traffic to an instance that is unable to receive it for various reasons, such as during 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 two 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 - It is not currently possible to retrieve the health status of an instance. While the system will not direct traffic to an unhealthy instance, the internal state of attached instances is not exposed.

Configure a Manual Elastic IP on an instance

Manual Elastic IPs require additional configuration on the target instance for that instance to receive traffic.

WARNING - The Elastic IP address is set up as an additional IP address for your instance. The original IP address will still work, as it is used for outgoing connections. Do not remove the original IP address of the instance as the Elastic IP will not work without it. Several other native functionalities will also break.

The operations and commands to be performed vary depending on your chosen template. Below are a few examples for different templates:

Ubuntu Bionic

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

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

And then, apply it: sudo netplan apply

Debian or Ubuntu (Xenial and lower)

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

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

Then, use ifup lo:1 to enable the Elastic IP. 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 Elastic IP as well.

If you need to add any additional Elastic IPs, use lo:2, lo:3, et cetera.

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

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=203.0.113.202/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 can now ping the Elastic IP address and any service authorized in the associated Security Group should be reachable with this Elastic IP as well.

You can add multiple loopback Address blocks.

Other Linux Distributions

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

ip addr add 203.0.113.202/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 203.0.113.202/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 with the command 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 the hardware wizard. 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 Install the hardware that I manually select from a list:

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 list on the left-hand side, then Microsoft KM-TEST Loopback Adapter in the list on the right-hand side:

Windows: Add Hardware

click on Next, then click on Install.

The following steps will assign the EIP to the Loopback interface and activate IP Forwarding to the relevant interfaces.

NOTE - If you don’t have PowerShell on your instance, please try and install it or let us know about it. We will try and provide a different procedure.

Please open your favorite Windows editor and create a file called EIP.ps with the following content:

# Get the EIP in the format XXX.XXX.XXX.XXX/32 from the cli
param(
[string]$EIP
)
# split the address and its mask
$IPAddress=($EIP -split '/' | Select-Object -First 1)
$Mask=($EIP -split '/' | Select-Object -Last 1)
# query http://metadata.exoscale.com/latest/meta-data/local-ipv4 to get the Public IP
$MyPublicIPAddress=(Invoke-WebRequest metadata.exoscale.com/latest/meta-data/local-ipv4).Content.Trim()
# Rename to Loopback
Get-NetAdapter -InterfaceDescription "Microsoft *" | Rename-NetAdapter -NewName "Loopback"
# Configure the EIP
Get-NetAdapter -Name "Loopback" | New-NetIPAddress -IPAddress $IPAddress -PrefixLength $Mask
# Get the Public interface ifIndex
$PublicInterfaceIndex=(Get-NetIPAddress -AddressFamily IPv4 | Where-Object {$_.IPAddress -match $MyPublicIPAddress} | Select-Object InterfaceIndex)
# Get the Loopback interface ifIndex
$LoopbackInterfaceIndex=(Get-NetIPAddress -AddressFamily IPv4 | Where-Object {$_.IPAddress -match $IPAddress} | Select-Object InterfaceIndex)
# Enable Forwarding
Set-NetIPInterface -ifIndex $PublicInterfaceIndex.InterfaceIndex -Forwarding Enable
Set-NetIPInterface -ifIndex $LoopbackInterfaceIndex.InterfaceIndex -Forwarding Enable
# Print the status after the changes
Get-NetIPInterface -AddressFamily IPv4 | select ifIndex,InterfaceAlias,AddressFamily,ConnectionState,Forwarding | Sort-Object -Property IfIndex | Format-Table

Once the file is created you can now add your EIP as follows:

C:\> EIP.ps 203.0.113.203/32

In the same way you can attach multiple EIPs.

Manual Elastic IP as Traffic Source

There are some cases where you may want to use Elastic IP as a source IP address - for example, if you run an SMTP server. It is possible to achieve that with manual Elastic IPs for applications, which allows you to configure their source IP. The traffic emitted in this setup is seen as coming from the Elastic IP 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 = 203.0.113.202

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

WARNING - Elastic IP addresses should not be shared across multiple traffic-emitting instances, as it will result in asymmetric routing for returning traffic.

Limitations

  • Elastic IPs are initially limited to 5 per organization. You can ask for a quota increase in the quotas section of the Portal.
  • Instances sharing a common Elastic IP cannot communicate with each other by using the Elastic IP address.
  • Elastic IP 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 circumvented manually with manual Elastic IPs.
  • Instances associated with a managed Elastic IP will see incoming Elastic IP traffic destined to their primary interface IP address.
  • With managed Elastic IPs, 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.

Exoscale Compute instances can optionally feature a public IPv6 address, either upon creation or afterward. This address is partially derived from the instance’s MAC address, which is unique. Therefore, the IPv6 address is tied to the instance itself. When you destroy the instance, you release the public IPv6 address forever.

However, sometimes having a persistent IPv6 address is desirable. For example, needing to employ multiple IPv6 addresses for the same use case.

Elastic IPv6 prefix is a Compute resource that creates an entire IPv6 prefix (with prefix length /96) to your organization. You can then attach that prefix to one or several instances in addition to their primary IPv6 address. These instances need to have IPv6 enabled. Attaching multiple ElasticIPv6 prefixes for your organization is possible.

Elastic IPv6 prefix differs from its IPv4 counterpart in that it contains more than 4 billion addresses. All addresses within that IPv6 prefix are available to use according to your instances’ networking needs.

Creating a Elastic IPv6 prefix

To use an Elastic IPv6 prefix, the first step is to allocate it. This can be achieved via the Portal, the CLI or the API.

Create a Manual Elastic IPv6 prefix

To create an Elastic IPv6 prefix via the CLI, you need to specify IPv6 create --ipv6 and your chosen zone. This is what it looks like in the CLI:

# Mind the --ipv6 flag
$ exo compute elastic-ip create --ipv6 --zone at-vie-1
 ✔ Creating Elastic IP... 4s
┼────────────────┼──────────────────────────────────────┼
│   ELASTIC IP   │                                      │
┼────────────────┼──────────────────────────────────────┼
│ ID             │ 1eabae57-50c9-4368-a591-8695cbfe37ce │
│ IP Address     │ 2a04:c45:c00:3a46:500:2:0:1          │
│ Address Family │ inet6                                │
│ CIDR           │ 2a04:c45:c00:3a46:500:2::/96         │
│ Description    │                                      │
│ Zone           │ at-vie-1                             │
│ Type           │ manual                               │
┼────────────────┼──────────────────────────────────────┼

The Elastic IPv6 prefix is visible in the CIDR field, while a reference IPv6 address within that prefix is displayed in the IP Address field. Note that the whole prefix is usable.

Create a managed Elastic IPv6 prefix, backed by a health check 

$ exo compute elastic-ip create \
 --ipv6 \
 --zone at-vie-1 \
 --healthcheck-mode tcp \
 --healthcheck-port 80
 ✔ Creating Elastic IP... 3s
┼──────────────────────────┼──────────────────────────────────────┼
│        ELASTIC IP        │                                      │
┼──────────────────────────┼──────────────────────────────────────┼
│ ID                       │ 19f2cc9a-e7a7-4e03-b32c-525c123f4eb2 │
│ IP Address               │ 2a04:c45:c00:3a46:500:3:0:1          │
│ Address Family           │ inet6                                │
│ CIDR                     │ 2a04:c45:c00:3a46:500:3::/96         │
│ Description              │                                      │
│ Zone                     │ at-vie-1                             │
│ Type                     │ managed                              │
│ Healthcheck Mode         │ tcp                                  │
│ Healthcheck Port         │ 80                                   │
│ Healthcheck Interval     │ 10s                                  │
│ Healthcheck Timeout      │ 3s                                   │
│ Healthcheck Strikes OK   │ 3                                    │
│ Healthcheck Strikes Fail │ 2                                    │
┼──────────────────────────┼──────────────────────────────────────┼

As seen above, in order to create a managed Elastic IPv6 prefix, you also have to provide the required health check parameters. Without those parameters, an Elastic IPv6 manual type will be created.

Attach an Elastic IPv6 prefix to an instance

After the Elastic IPv6 prefix has been created, you can then attach it to one or more Compute instances.

To refer to a Elastic IPv6 prefix, use either its unique ID or the reference IPv6 address, as you can see here in the CLI:

➜  russell ~  exo c elastic-ip show 4ef39790-3409-4b2b-aa44-672db338edd5 -z at-vie-1
┼────────────────┼──────────────────────────────────────┼
│   ELASTIC IP   │                                      │
┼────────────────┼──────────────────────────────────────┼
│ ID             │ 4ef39790-3409-4b2b-aa44-672db338edd5 │
│ IP Address     │ 2a04:c45:c00:3a46:500:2:0:1          │
│ Address Family │ inet6                                │
│ CIDR           │ 2a04:c45:c00:3a46:500:2::/96         │
│ Description    │                                      │
│ Zone           │ at-vie-1                             │
│ Type           │ manual                               │
┼────────────────┼──────────────────────────────────────┼

Attach the Elastic IPv6 prefix like this:

$ exo compute instance elastic-ip attach my-instance 4ef39790-3409-4b2b-aa44-672db338edd5 -z at-vie-1
 ✔ Attaching Elastic IP "4ef39790-3409-4b2b-aa44-672db338edd5" to instance "my-instance"... 3s
┼──────────────────────┼──────────────────────────────────────┼
│   COMPUTE INSTANCE   │                                      │
┼──────────────────────┼──────────────────────────────────────┼
│ ID                   │ 8a7dd501-ccc4-4582-867a-347e14bf43ff │
│ Name                 │ my-instance                          │
│ Creation Date        │ 2022-08-25 14:23:04 +0000 UTC        │
│ Instance Type        │ standard.medium                      │
│ Template             │ Linux Ubuntu 20.04 LTS 64-bit        │
│ Zone                 │ at-vie-1                             │
│ Anti-Affinity Groups │ n/a                                  │
│ Security Groups      │ default                              │
│ Private Networks     │ n/a                                  │
│ Elastic IPs          │ 2a04:c45:c00:3a46:500:2:0:1          │
│ IP Address           │ 185.150.8.7                          │
│ IPv6 Address         │ 2a04:c45:c00:3a46:4fa:70ff:fe00:4a   │
│ SSH Key              │ my-instance-1661437382               │
│ Disk Size            │ 50 GiB                               │
│ State                │ running                              │
│ Labels               │ n/a                                  │
┼──────────────────────┼──────────────────────────────────────┼

Traffic for any address within the Elastic IPv6 prefix is now routed to my-instance.

Please note: in the case of the manual Elastic IPv6, the user has to configure the address within the attached instances.

For the managed Elastic IPv6, traffic towards the reference IPv6 address is transparently forwarded, with no need for additional configuration. The whole Elastic IPv6 prefix is still routed to the attached instances. However, any other IPv6 addresses need to be configured within the instances.

Managed Elastic IPv6 prefix health check options

Health check options for managed Elastic IPv6 prefixes are the same as the IPv4 counterpart.

Configure IPv6 addresses within a Compute instance

As we described, for managed Elastic IPv6 prefix a single reference IPv6 address will be transparently forwarded to the attached instances without any configuration needed. For all the other cases, manual configuration is needed within the Compute instances.

Some common use cases are:

  • To employ a managed Elastic IPv6 prefix, and you need to use more IPv6 addresses than the reference address.
  • To employ a manual Elastic IPv6 prefix.

WARNING - Do not remove the original IPv6 address of the compute instance, as Elastic IPv6 relies on it.

Configuration of additional IPv6 addresses within your Compute instance may vary depending the operating system. Some examples follow:

Ubuntu Jammy

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

---
network:
  version: 2
  renderer: networkd
  ethernets:
    lo:
      match:
        name: lo
      addresses:
        - 2a04:c45:c00:3a46:500:2::1337/128

And then, apply it with sudo netplan apply

Debian 11 (Bullseye)

In /etc/network/interfaces.d/51-eipv6 add the following snippet:

    auto lo:1
    iface lo:1 inet6 static
        address 2a04:c44:c00:3a46:500:2::1337/128

Then invoke ifup lo:1 to configure the IPv6 address on respective interface. For additional IPv6 addresses from the Elastic IPv6 prefix, use lo:2, lo:3, et cetera.

Manual Elastic IP as Traffic Source

There might be cases when you need to use IPv6 addresses from the Elastic IPv6 prefix as a source for egress traffic. You will need to either:

  • Configure the Elastic IPv6 addresses as binding addresses on the application level:

For example with Postfix mail server you could use smtp_bind_address6 = 2001:240:587:0:250:56ff:fe89:1

  • Configure the Elastic IPv6 address as the preferred source on the system’s routing level:

There are several ways to implement a preferred source at the level of routing, depending on the operating system and personal preference. Here are two examples with netplan and systemd-networkd, two popular networking options in the Linux world.

Modifying default IPv6 source address with netplan

Assuming you need to use 2a04:c44:c00:3a46:500:2::1337 as the source IPv6 address for all egress traffic:

sudo ip -6 address add 2a04:c44:c00:3a46:500:1:0:1337/128 dev lo

Then

cat <<EOF | sudo tee /etc/netplan/51-eipv6-source.yaml
---
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      routes:
        - to: default
          from: 2a04:c44:c00:3a46:500:2::1337
          via: $(ip -6 r show default | awk '{print $3}')
          metric: 99
EOF

and then invoke sudo netplan apply.

Modifying default IPv6 source address with systemd-networkd

Assuming you need to use 2a04:c44:c00:3a46:500:2::1337 as the source IPv6 address for all egress traffic:

sudo ip -6 address add 2a04:c44:c00:3a46:500:1:0:1337/128 dev lo

Then

debian@debianv6:~$ cat << EOF | sudo tee /etc/systemd/network/eth0.network
> [Match]
Name=eth0

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6
IPv6AcceptRA=yes

[Route]
Destination=::/0
Gateway=_ipv6ra
PreferredSource=2a04:c44:c00:3a46:500:1:0:1337
Metric=99
EOF

and then invoke sudo systemctl restart systemd-networkd.

Limitations

  • Elastic IPv6 prefixes have the same limitations as Elastic IPs.
  • For managed Elastic IPv6 prefixes, only the first-plus-one IPv6 address of that prefix is transparently forwarded to the associated instances.