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 the next time you spawn a new instance.
There are various cases where you may want an IP address to persist, however.
By creating an Elastic IP (EIP), you can have a specific IP address for your organization. You can then attach 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 circumvent 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.
EIPs come in two management types:
By default, both have the same basic behavior:
- EIPs are created for your organization and will be available until you decide to delete them.
- EIPs can be attached to one or multiple instances at all times.
- EIPs are bound to a zone. EIPs can only be attached to Compute instances in the same zone as the EIP.
- All incoming traffic towards an EIP 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 EIP.
- When multiple instances are attached to an EIP, traffic aimed at the EIP is distributed to those attached instances with no even load distribution guarantee.
On top of all this, both manual and managed EIPs have distinct characteristics. Their behavior can be customized.
Managed EIPs require no action from your side on the instance itself. Once attached to an instance, the managed EIP transparently routes traffic to it. Moreover, a managed EIP has some basic health check capabilities, routing traffic only to healthy instances. However, bear in mind that:
- Instances attached to a managed EIP 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 EIPs.
Manual EIPs need to be manually enabled on the instance itself. This allows for more flexibility, but requires more manual configuration. Distinct characteristics of manual EIPs include:
- Internally, instances attached to a manual EIP see traffic coming to the EIP address. This differs from managed EIPs, where incoming traffic is seen as coming to the native IP address of the attached instance.
- Instances attached to a manual EIP can use it as source for outgoing traffic, with some limitations.
Creating an EIP
To use an EIP address, the first step is to create it. This can be done through our web application, our CLI or the API.
This is an example from the CLI:
# Create 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 │ 220.127.116.11 │ │ Description │ │ │ Zone │ de-fra-1 │ │ Type │ manual │ ┼─────────────┼──────────────────────────────────────┼ # Create 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 │ 18.104.22.168 │ │ 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 EIP, you have to provide the required health check parameters. Without those parameters, the EIP is created as manual.
Attach an EIP to a Compute instance
Once the EIP address as been created, you can then attach it to one or more Compute instances. Here is another example from the CLI:
$ exo compute instance elastic-ip attach my-instance 22.214.171.124 ✔ Attaching Elastic IP "126.96.36.199" 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 │ 188.8.131.52 │ │ IP Address │ 184.108.40.206 │ │ 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
Once attached 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 EIPs have an integrated health check. The health check will be periodically run on the attached instances in order to prevent sending ingress traffic to a virtual machine 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)
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 EIP on an Instance
Manual EIPs require additional configuration on the target instance for that instance to receive traffic.
The EIP 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. You must not remove the original IP address of the instance as the EIP 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:
/etc/netplan/51-eip.yaml, put the following snippet.
network: version: 2 renderer: networkd ethernets: lo: match: name: lo addresses: - 220.127.116.11/32
And then, apply it:
sudo netplan apply
Debian / Ubuntu (Xenial and lower)
/etc/network/interfaces.d/eip.cfg, add the following snippet.
auto lo:1 iface lo:1 inet static address 18.104.22.168/32
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
On Debian 8, you have to add
source /etc/network/interfaces.d/* in
/etc/sysconfig/network-scripts/ifcfg-lo:1 file with the
DEVICE=lo:1 IPADDR=22.214.171.124 NETMASK=255.255.255.255 ONBOOT=yes NAME=lo1
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
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=126.96.36.199/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.
You can manually add the EIP address on any Linux Instance with the following command:
ip addr add 188.8.131.52/32 dev lo
Beware this configuration will be lost if you reboot the Instance in absence of some custom automation.
Configure your Elastic IP with this single command:
echo inet 184.108.40.206/32 > /etc/hostname.lo1
You can reconfigure your network on the fly with:
Since OpenBSD 6.7, it is now required to enable IP routing. This can be done via
sysctl net.inet.ip.forwarding=1 # To persist the change upon reboot echo net.inet.ip.forwarding=1 >> /etc/sysctl.conf
As a first step, we need to install a special driver. For this, open a command line and execute the following command:
You should get the Add Hardware wizard:
Click on Next. On the next screen, choose the second option:
Click on Next. On the next screen, choose Network adapters:
Click on Next. On the next screen, choose Microsoft in the left list, then Microsoft KM-TEST Loopback Adapter in the right list:
Click on Next, then on Install.
Open a command-line and execute
ipconfig /all. You should find an
Ethernet 2 whose description is
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 220.127.116.11 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
smtp_bind_address = 18.104.22.168
Most software have a similar setting for outgoing connections. Search
bind keyword in the documentation.
EIP addresses should not be shared across multiple traffic-emitting Instances, as it will result in asymmetric routing for returning traffic.
- EIPs are initially limited to 5 per organization. You can ask for a limit increase in the limits section of the web application.
- 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.