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.
EIPs come in two flavors:
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 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 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
This is what it looks like in the CLI:
# Reserve a manual EIP $ exo eip create de-fra-1 ┼──────────────────────────────────────┼──────────────┼─────────────┼──────────┼ │ ID │ IP │ DESCRIPTION │ ZONE │ ┼──────────────────────────────────────┼──────────────┼─────────────┼──────────┼ │ e585b853-ba8d-4f51-bfc5-7b5b94f73f97 │ 220.127.116.11 │ │ de-fra-1 │ ┼──────────────────────────────────────┼──────────────┼─────────────┼──────────┼ # Reserve a managed EIP $ exo eip create de-fra-1 \ --healthcheck-interval 60 \ --healthcheck-mode TCP \ --healthcheck-port 80 \ --healthcheck-strikes-fail 5 \ --healthcheck-strikes-ok 5 \ --healthcheck-timeout 10 ┼──────────────────────────────────────┼───────────────┼─────────────┼──────────┼ │ ID │ IP │ DESCRIPTION │ ZONE │ ┼──────────────────────────────────────┼───────────────┼─────────────┼──────────┼ │ ec4d1e88-79a7-4dec-a3d3-1fcc4096c251 │ 18.104.22.168 │ │ de-fra-1 │ ┼──────────────────────────────────────┼───────────────┼─────────────┼──────────┼
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 an Instance
Once the EIP as been reserved you can then associate it to one or more Instances.
$ exo eip associate 22.214.171.124 my-instance associate "126.96.36.199" EIP done! $ exo eip show 188.8.131.52 ┼─────────────┼──────────────────────────────────────┼ │ ELASTIC IP │ │ ┼─────────────┼──────────────────────────────────────┼ │ ID │ ec4d1e88-79a7-4dec-a3d3-1fcc4096c251 │ │ Zone │ de-fra-1 │ │ IP Address │ 184.108.40.206 │ │ Description │ │ │ Instances │ my-instance │ ┼─────────────┼──────────────────────────────────────┼
The EIP is now routing traffic to
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)
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.
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.
/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][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.