Hyper Open Edge Cloud

Traffic Explanation for a private SlapOS

Understand all the traffic between the machines in a private SlapOS installation.
  • Last Update:2023-07-17
  • Version:001
  • Language:en


This presentation will help you understand all the traffic going between the machines used in a private SlapOS installation.

Providing that you have your own SlapOS installation (master, CDN, shacache, ...), you can run your cloud mostly without external access. We will outline the few situations where external access is needed.

Re6st traffic

Re6st is a SDN (Software Defined Network). It is the base of the communication between all machines. It provides IPv6 to all machines.

When bootstrapping, re6st will open a HTTP or HTTPS communication to the re6st registry (blue). This communication will setup re6st and give a bootstrap peer to the machine. Then this communication is not needed anymore.

By default, re6st opens OpenVPN tunnel in IPv4 on port 1194 (green). Inside those tunnels, IPv6 communication happens and IPv6 must be allowed (and at least UDP port 6696).

From time to time, re6st nodes need to talk to each other (e.g. before closing a tunnel), in this case, they use IPv4 UDP port 326 (red).

SlapOS traffic

Once re6st is running, all machine has IPv6. Then in order to run SlapOS services, each machine must connect to the SlapOS master. This communication happens in HTTPS either:

  • in IPv6 over re6st
  • in IPv4 with an available IPv4 of the SlapOS master (this IPv4 must be reachable by all SlapOS nodes)

CDN traffic

Most SlapOS services are available to the user via HTTP. Since the users don't have necessarily IPv6 and we don't want to force them to use re6st, we are using a HTTP CDN to access the services.

The CDN is made of one or several machines with IPv4 acting as HTTP proxy. The users will connect in IPv4 to the CDN machine and the CDN will then connect to the "backend" in IPv6 through re6st.

New machine installation

When we want to install a new machine in an already existing environment, we will simply boot from an existing empty image of the chose OS (Debian stable for example). And we will run a ansible playbook that we will download from Shacache using HTTP or HTTPS. This playbook will in turn upgrade the machine and install re6st and slapos (using the APT proxy).

In order to have everything working fine, RapidSpace team should be able to update from time to time the playbook stored in shacache via a secure connection. Also, the APT proxy machine will need to be able to download packages from a chosen location (this will be download only connection that can be controlled via firewall of the network).

New service deployment

When you want to deploy a new service (be it a new version of a service or a totally new service), you need to deploy this service to all machines. This happens in several steps:

  1. you compile the new service outside of the internal network (because compilation need to access many sources on internet)
  2. you push a compressed archive containing all the resources (binaries, templates, ...) needed for the new service into internal shacache. This can happen through any secure mean (VPN, SSH tunnel, ...)
  3. all SlapOS nodes will download the new service from shacache through the CDN