News

Define your own subnets

As creating order is half the battle, a large number of system engineers have defined not only a naming scheme but also an address scheme to optimally support them in their daily work with their systems. It has already been helpful that cloudscale.ch allows any IP address to be used in private networks, and you can now also use our DHCP systems to assign addresses from your self-defined subnet to your servers.

To define your own subnet, first create a private network via API specifying "auto_create_ipv4_subnet": false; this will result in a fully functional layer 2 private network. Then, in this network, create your subnet and enter the IP range of your choice (at least a /24) as the cidr value. For each subnet you can also define the gateway and DNS servers that our DHCP systems should assign to your servers. An example:

$ curl -i -X POST -H "$AUTH_HEADER" -H "Content-Type: application/json" --data '{"cidr": "192.168.1.0/24", "network": "61fa...10ed", "gateway_address": "192.168.1.1", "dns_servers": ["192.168.1.1", "192.168.1.2"]}' https://api.cloudscale.ch/v1/subnets

With or without DHCP – IPs as needed

When launching a new server with a private network, all options are now available to you. If a subnet is defined in the private network, the server is by default assigned a randomly selected address from the DHCP range of the subnet, along with the gateway (optional) and the DNS servers. You can, however, also specify a fixed IP address if you wish. It goes without saying that it is also possible to completely disable DHCP for a server if you prefer.

As an example, the following API call creates a server that has a public interface as well as one in the private network, where the server should be assigned a fixed IP address via DHCP:

$ curl -i -X POST -H "$AUTH_HEADER" -H "Content-Type: application/json" --data '{"name": "firewall", ..., "interfaces": [{"network": "public"}, {"addresses": [{"subnet": "5b71...2912", "address": "192.168.1.21"}]}]}' https://api.cloudscale.ch/v1/servers

It goes without saying that you have the same options when adding interfaces to an existing server later on. For a complete overview of possible interface definitions, please refer to our API documentation.

DHCP is always enabled on the public interface (if present) and cannot be configured any further. You are, however, still free to configure all relevant settings on your server statically.

Please note that DHCP must be enabled on at least one interface (public or in at least one private network). In this way, the server learns a route to our metadata server to retrieve its configuration for cloud-init.

Consistency and efficiency

The advantage is obvious: when creating servers, you can also structure the private network appropriately. For a central firewall with OPNsense, for example, you can directly define a fixed IP address. The other servers to be located behind this firewall are then assigned the firewall IP via DHCP both as a gateway and as a DNS resolver.

It is also easier to maintain your own DNS resolver because you now know the internal IP addresses of your servers from the beginning and can record them directly in the DNS. And if you are experimenting with current Kubernetes distributions, new nodes can automatically integrate themselves into the cluster thanks to a reverse DNS lookup for their own internal IP address.

Using private networks, you have long been able to "wire" your virtual servers together at cloudscale.ch in the same way as with physical servers. Thanks to configurable IP addresses and subnets as well as DHCP options, you can now also model the logical level to enable your cloud setups to integrate ideally into your overall infrastructure.

The right address, right from the start!
Your cloudscale.ch team