Networking

Every workload, container or virtual machine, has a network card on a private network that spans every server of the realm. Around it, Velrix gives you the pieces of a cloud network: security groups, public addresses, load balancers and hostnames.

Private networks

• A workload keeps its private address and its MAC when it moves to another server, so nothing that talks to it notices the move.
• Workloads on one network reach each other by name, across servers, and containers and VMs alike. Other owners’ networks can’t reach them.
• Whether a network’s workloads may open connections to the internet is a setting of the network (Egress).
• A server with IPv6 gives workloads IPv6 too; a workload can also get its own public IPv6 address, routed straight to it with no NAT.

Security groups

A security group is a set of rules, and the workloads you put in it. On a network where no workload is in a group, every workload talks freely. Once one is:

• members of a group reach each other;
• between groups, only what an inbound rule of the receiving group allows opens;
• outbound traffic is open unless a group of the workload has outbound rules: then only those.

Replies to a connection that was let through always pass. Changes apply within seconds, wherever the workload runs. Networking shows how to set them.

Your provider may also apply network policy templates before your own groups, such as one that blocks sending mail directly on port 25. They are listed on your Networks window, and you can ask to have one lifted.

Reaching workloads from outside

• Hostnames put a web app on your own domain, with a certificate, over HTTP/1.1, HTTP/2 and HTTP/3. This is the common way in (Apps).
• Floating IPs are public addresses you hold, pointed at one workload. The address follows the workload when it moves.
• Load balancers put one address in front of an app’s healthy copies, on the app’s own ports.
• Gateways are the servers an operator picks to hold floating IPs and balancer addresses, and to carry workloads’ traffic to the internet. If the active gateway fails, the next one takes over within seconds.

What an app exposes is declared as protocols on its page (HTTPS, PostgreSQL, SSH, Minecraft and so on, with their ports). Hostnames and load balancers carry what the protocols say. Protocols are definitions an operator can extend, not code. Floating IPs and load balancers covers this side.

The dataplane

Under all of this, each server forwards and filters packets in the Linux kernel with eBPF, and the gateways use XDP for their public traffic. There is no connection tracking table and no older firewall behind it to fall back to.

• Security groups are judged once per packet, on the workload’s own port, as the packet enters. Replies are recognised by a small reply cache per network, so one network’s traffic can never push out another’s.
• Load balancers spread connections with Maglev hashing, one table per balancer, at the gateway’s network card. A connection keeps its backend while backends come and go, and it survives a gateway failover, because no gateway holds state the next one lacks.
• Floating IPs are translated without per-connection state, so established connections survive a gateway failover too.
• Outbound traffic to the internet is translated per owner, within a bounded share, so one owner can never use up the gateway’s ports for everyone else.
• Every owner has bounds and counters: how many flows, replies and translations they may hold, and what they used. An operator sees each network’s counters.
• SYN floods against a public address are answered at the gateway’s network card, before they reach any workload.
• If the dataplane can’t judge a packet, it drops it. A server never forwards traffic it has not checked.

Operators: Dataplane has the network card requirements, native and generic XDP, and how to read the counters.