We’ve already established, that important parts of the network stack are running on the VM hosts; but what do they have to provide for a cloud server to operate?

For the majority of servers, Internet reachability is required, so the system and its services can be accessed from home or abroad. Some servers use Private Networks, either instead of, or alongside public network , which connect servers, Load Balancers, and possibly dedicated servers via a private and virtual network that only your systems can access. Private network traffic is encapsulated using Virtual eXtensible LAN (VXLAN) and a unique Virtual Network Identifier (VNI) per private network. The host network stack ensures that only members attached to the respective private network can send or receive traffic.

To control access to your services available from the Internet, we provide the cloud Firewall feature. It allows controlling access to certain ports or protocols of the server, or can limit which traffic can leave the server. This should happen as close to the server as possible, hence on the host. Building stateful firewalls centrally, would require additional hardware and network overlays to transport the “clean” traffic to the servers, and add much complexity for highly available, central connection tracking.

By default, our cloud server images are configured to use the Dynamic Host Configuration Protocol (DHCP) for dynamic configuration of IPv4 addresses and routes. Hence, we have to provide a DHCP server, so servers can request their IPv4 networking configuration for public and private network interfaces.

Within most images, cloud-init is used to configure some parts of the system, for example configure IPv6 networking, trigger DHCP for private network interfaces, attach cloud Volumes, etc. For these tasks, cloud-init has to query information about the local system or user-specific configuration bits from our metadata server available at http://169.254.169.254/. Besides cloud-init, the metadata server is used by many integrations, including but not limited to our CSI driver, hc-utils, distribution tooling like Flatcar Linux's Afterburn and Ignition, or Talos Linux.

Both the DHCP and metadata servers are running locally on each VM host for maximum resiliency and availability.

Besides these user-facing services, the VM hosts run a bunch of internal services, which make sure your servers are up and running, the network stack gets the correct information to configure connectivity, and our monitoring knows what’s happening.

In this post, however, we’ll focus on the network stack and will have a deeper look into its inner workings.