External IP addresses are similar to physical resources like compute and storage in that they are limited in quantity and subject to allocation among different tenants. IP pools are logical collections of external IP addresses that let operators control which silos can use which IPs. Operators can adjust the size of pools based on demand and other constraints while users can reference the same logical entity in provisioning requests without having to understand the physical setup. See the Guest Networking guide for details on how external IPs are used.
Key concepts
An IP pool is a named collection of IP address ranges.
When an IP pool is linked to a silo, users in that silo can assign external IP addresses from that pool to their VM instances. A pool can be linked to any number of silos, including zero.
The default pool for a silo will be used automatically for external IP allocation in that silo when a pool is not specified. A silo can have at most one default pool. If a silo has no default pool, users will always have to specify a pool, which is inconvenient. Silos should typically be given a default pool.
Defining IP Pools
Operators may define IP pools that are shared by different silos or used by specific silos. If you plan to have a common pool of external IP addresses for all silos, you can create one IP pool, add all available IP ranges to it, and make it the default pool for every silo.
The following policies are enforced by the system when defining IP pools and address ranges:
The permission to manage IP pools is restricted to operators.
The first and last IP addresses must be valid IPv4 addresses.
No overlapping IP ranges is allowed within the same pool or across different pools.
Linking IP pools with silos
A silo can be configured to use one or more IP pools and one of them should be designated as the default. The default setting allows IP addresses to be allocated automatically without users having to specify a pool when creating an instance or a floating IP.
IP pools can be linked and unlinked dynamically, though you cannot unlink a pool from a silo if there are IP addresses from that pool in use in the silo.
External IP Address Allocation
External address categorization
There are three categories of external address which can be allocated to an instance, as described in the Guest Networking guide. Here, we will focus on the assignment method and how it may affect IP pool utilization and sizing considerations.
Ephemeral IP: It is a temporary IP address allocated to a new instance via DHCP. The address is used exclusively by the instance for inbound traffic and is mapped to its primary NIC on the VPC. The address is returned to the IP pool upon instance termination.
Floating IP: It is a permanent IP address managed within the scope of a project. Project users can create and delete these addresses, choose how and when to associate them to different instances. Once a floating IP is attached to a particular instance, it works in the same way as an ephemeral IP. When the instance attached to it is terminated, the IP address will be freed up for another instance in the project but is not returned to the pool.
SNAT IP: Source NAT is an external IP address allocated via DHCP to every instance with network interface(s). SNAT allows outbound communications with external hosts. Each SNAT IP takes up only a quarter of the port range on a particular address. In other words, up to four instances may be sharing the same SNAT IP over different port ranges. IP addresses currently in use for SNAT purposes will not be allocated as ephemeral or floating IP.
Address assignment from the default pool
When creating a VM instance in the web console, if the user selects the "default" option for networking configuration, an external IP address will be assigned automatically from the silo’s default IP pool. Similarly, the silo default pool is used when the pool name attribute is not specified in an instance or floating IP create request, e.g.
"external_ips": [
{
"type": "ephemeral"
}
]Address assignment from the non-default pools
To get an external IP address from the non-default pools, user can specify the pool name in the instance or floating IP create requests, e.g.
"external_ips": [
{
"type": "ephemeral",
"pool": "inter-dc"
}
]The IP pool used must be linked to the silo. A HTTP 404 (Not found) error will be returned if the IP pool is not associated with the silo to which the user belongs.
IP pool utilization and capacity checks
The current IP utilization metrics for individual IP pools are available on the web console under Networking and through the CLI.
When the system is unable to allocate external IP addresses from the silo default IP pool due to capacity issues, users will get a HTTP 507 error ("No external IP addresses available") when attempting to create more instances. The system does not fall back to use another IP pool automatically. The user has several options to resolve the error:
Free up in-use addresses by deleting existing instances
Ask the operator to add more addresses to the silo’s default IP pool
Specify another pool with available IP addresses, if there is one linked to the silo
Service IP Pool
There is a special IP pool called the service pool used by the control plane for internal services like DNS, API, and NAT. If the service pool runs out of IP addresses, system update and service cluster expansion may fail. The service pool is managed separately from the other pools: it cannot be linked to silos and will not appear in the main list of pools. There is no shared address space between the service pool and other pools, though this fact is not specific to the service pool: as state above, no two IP ranges in any pool can overlap.