Juju and Fan networking

Fan networking addresses a need raised by the proliferation of container usage in an IPv4 context: the ability to manage the address space such that network connectivity among containers running on separate hosts is achieved.

Juju integrates with the Fan to provide network connectivity between containers that was hitherto not possible. The typical use case is the seamless interaction between deployed applications running within LXD containers on separate Juju machines.

Fan overview

The Fan is a mapping between a smaller IPv4 address space (e.g. a /16 network) and a larger one (e.g. a /8 network) where subnets from the smaller one (the underlay network) are assigned to addresses on the larger one (the overlay network). Connectivity between containers on the larger network is enabled in a simple and efficient manner.

In the case of the above networks (/16 underlay and /8 overlay), each host address on the underlay "provides" 253 addresses on the overlay. Fan networking can thus be considered a form of "address expansion".

Further reading on generic (non-Juju) Fan networking:

• Fan networking : general user documentation
• Container-to-Container Networking : a less technical overview
• LXD network configuration : Fan configuration options at the LXD level
• fanctl man page : configuration information at the operating system level

Juju model Fan configuration

Juju manages Fan networking at the model level, with the relevant configuration options being fan-config and container-networking-method.

First, configure the Fan via fan-config. This option can assume a space-separated list of <underlay-network>=<overlay-network>. This option maps the underlay network to the overlay network.

juju model-config fan-config=10.0.0.0/16=252.0.0.0/8

Then, enable the Fan with the container-networking-method option. It can take on the following values:

• local : standard LXD; addressing based on the LXD bridge (e.g. lxdbr0)
• provider : addressing based on host bridge; works only with providers with built-in container addressing support (e.g. MAAS with LXD)
• fan : Fan networking; works with any provider, in principle

juju model-config container-networking-method=fan

To confirm that a model is properly configured use the following command:

juju model-config | egrep 'fan-config|container-networking-method'

This example will produce the following output:

container-networking-method   model    fan
fan-config                    model    10.0.0.0/16=252.0.0.0/8

See Configuring models for more details on setting model options.

Cloud provider requirements

Juju autoconfigures Fan networking for both the AWS and GCE clouds. All that is needed is a controller, which does not need any special Fan options passed during its creation.

In principle, all public cloud types can utilize the Fan. Yet due to the myriad ways a cloud may configure their subnets your mileage may vary. At the very least, if you are using a cloud other than AWS or GCE, manual configuration at the Juju level will be needed (the above model options). Adjustments at the cloud level can also be expected. For guidance, the auto-configured clouds both start with a /16 address space. Juju then maps it onto an /8.

Note that MAAS has LXD addressing built-in so there is no point in applying the Fan in such a context.

Examples

Two examples are provided. Each will use a different cloud:

• Rudimentary confirmation of the Fan using a GCE cloud
• Deploying applications with the Fan using an AWS cloud

Rudimentary confirmation of the Fan using a GCE cloud

Fan networking works out-of-the-box with GCE. We'll use a GCE cloud to perform a rudimentary confirmation that the Fan is in working order by creating two machines with a LXD container on each. A network test will then be performed between the two containers to confirm connectivity.

Here we go:

juju add-machine -n 2
juju deploy ubuntu --to lxd:0
juju add-unit ubuntu --to lxd:1

After a while, we see the following output to command juju machines -m default | grep lxd:

0/lxd/0  started  252.0.63.146    juju-477cfe-0-lxd-0  xenial  us-east1-b Container started
1/lxd/0  started  252.0.78.212    juju-477cfe-1-lxd-0  xenial  us-east1-c Container started

So these two containers should be able to contact one another if the Fan is up:

juju ssh -m default 0 sudo lxc exec juju-477cfe-0-lxd-0 '/usr/bin/tracepath 252.0.78.212'

Output:

1?: [LOCALHOST]                                         pmtu 1410
 1:  252.0.78.212                                          1.027ms reached
 1:  252.0.78.212                                          0.610ms reached
     Resume: pmtu 1410 hops 1 back 1 
Connection to 35.196.138.253 closed.

Good work.

Deploying applications with the Fan using an AWS cloud

To use Fan networking with AWS a virtual private cloud (VPC) is required. Fortunately, a working VPC is provided with every AWS account and is used, by default, when creating regular EC2 instances.

Whether you created a secondary VPC out of necessity or preference you will need to inform Juju about it. See AWS specific features for how to do this.

Here, Fan networking will be leveraged by deploying and relating applications that are running in different LXD containers, where the containers are housed on separate machines.

juju add-machine -n 2
juju deploy mysql --to lxd:0
juju deploy wordpress --to lxd:1
juju add-relation mysql wordpress

A partial output to juju status is:

Unit          Workload  Agent      Machine  Public address  Ports     Message
mysql/0*      active    idle       0/lxd/0  252.0.82.239    3306/tcp  Ready
wordpress/0*  active    executing  1/lxd/0  252.0.169.174   80/tcp

We can confirm that the MySQL container can contact the WordPress container with:

juju ssh mysql/0 exec nc -vz 252.0.169.174 80

This example test was successful by yielding the following output:

Connection to 252.0.169.174 80 port [tcp/http] succeeded!