I am pleased to announce the public availability of a feature we're calling Advanced IP Management. We're making this accessible to select clients today, and expect to have it generally available over the next week or two.
I am pleased to announce the public availability of a feature we’re calling Advanced IP Management. We’re making this accessible to select clients today, and expect to have it generally available over the next week or two.
A common frustration among public cloud users is the lack of flexibility around how IP addressing is managed. In a typical hosting environment, servers or VMs are limited to a single IP address, which lives and dies as a given host is created or deleted. While some of the more enterprising providers have introduced the concept of routing additional IPs to server hosts, their applicability is somewhat limited, and the interface is cumbersome. And IPv6, despite being a must have for any forward-thinking Internet application in this day and age, remains all but unheard of in most cloud platforms.
In building a brand new hosting service, devoid of any legacy software or networking stacks, we at Packet saw this as our opportunity to shine. Taking advantage of such liberties of our massively scalable “layer-3 to the host” setup, we set out to let our customers consume IP addresses as they best see fit, without any of the usual limitations.
Under our new networking model, customer projects are assigned three types of IP networks:
- Public IPv4 - By default, a customer’s server is assigned a single public IPv4 address, to be used for its management, or to serve simple public content. Clients can use our customer portal to order additional public address space, ranging from a /32 (a single IP) through a /24 (256 IPs). Though there is no technical limit to how these IPs can be configured, we’ll need to see that you’re planning to use them responsibly, and we charge a nominal monthly fee per address -- they are, after all, a scarce resource!
- Private IPv4 - In addition, new servers are released with a single private IPv4 (“10 net”) address, for use keeping internal communication between servers free and clear of the public Internet. We also assign a /25 network (automatically replenished with additional /25 networks as it fills up) so clients can configure virtual IPs for internal services and clustering -- more on how these get routed shortly.
- Public IPv6 - A server is assigned with a single public IPv6 address. In addition, we assign a /56 on the project level, which is divisible into 256 /64s (“LAN subnets” in IPv6 parlance), each routable to a server.
While a server is released with all (3) types of addresses enabled, customers are able to use as many or few of these address families as needed (e.g. using cloud-config). Spinning up an internal resource which should be reachable over the private network, but not the public Internet? Not a problem! Planning to follow Facebook’s lead and enter the brave new world of IPv6-only nodes? No problem there either.
Not that we’ve got our terminology out of the way, supplementary IP addresses can be pointed at servers using one of two methods:
- Customer portal: using the portal interface, clients are able to view IPs and networks belonging to a project, as well as select which servers they should be routed towards. Any changes made are propagated out through our datacenter network in a matter of seconds.
- API: Customers may also interface with our IP management using the Packet API. This way, IP migrations can be fully integrated into automation frameworks, as well as failover/HA processes.
(It’s important to note that these additional addresses are separate from any server infrastructure you may consume. So even if you delete a server instance, your additional addresses are assigned to your account and can be re-pointed to an existing or new host in your environment.)
And that’s just the tip of the iceberg. Now that we have our basic infrastructure in place, expect to see more ways to route your IPs, including using BGP speakers such as Project Calico and ExaBGP, in our next release.
Customers interested in testing this functionality are encouraged to mail firstname.lastname@example.org. We’re also interested in hearing feedback about these abilities, here or via private e-mail. Please let us know if these abilities are helpful as a client, or if you can think of any additional use cases to consider.