Brief overview of how the compute instances marshall packets to the application server layer

1

I have a gap in my understanding when building out a NetFoundry fabric. For example, my understanding is that at least one compute needs to be able to be accessible to the internet but all ports are closed. However, the central controller is what provides the packets the instructions of how to find the compute, even though it cannot be accessed via an IP address. This compute will then marshall the packets up into the application layer via NetFoundry SDK to the application server, just like I am intending to do for ORDS.

With this being the case, how would this work if the application layer is sitting on another compute that is on a private subnet that does not have access to the internet?

A more detailed description about how all of the mechanics work would be greatly appreciated.

2

The controller always needs to be accessible from the pieces of the network. It doesn’t need to be internet addressable, for example I run “private” ziti networks on my local machine or say in a container orchestration engine like docker/docker compose. The key is that every participating node of the network must be able to access the controller…

The same is true for the fabric. To form a mesh, all the routers need to be able to address one another or the link establishment can’t succeed.

Clients then would need to access at least one edge router to on-board onto the overlay fabric.

All these pieces must be able to address the controller. Routers must be able to route to the other routers advertised address (a configuration value). Clients must be able to route to one edge router…

Often times to provide access to the private networking space you would add an edge router (or a few) into the private address space, then create a second router which is “public”. The private router is NOT configured as a link listening router, to prevent the public router from trying to link to the private router. The public router is. Bring both online and you have the simplest overlay network that provides access via ziti to a totally dark network.

The docker compose quick start hopefully illustrates exactly this scenario: Local - Docker Compose | Ziti

It has a decent overview image that tries to explain it: http://openziti.github.io/ziti/quickstarts/network/docker-compose-overview.svg

This is an area we need to document better for sure. But thanks for asking the question and let us know if this sparks others, probably “exactly how do I configure each of these routers” would be the one that comes next. For that I’d say once you have the compose environment ruining use docker exec or docker cp and look at the file that’s generated. I’ll be happy to answer follow up questions regardless.

Nice to have you in the community!

1 Like