N45 FAN container 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.

This page will cover the following topics:

FAN overview

FAN networking provides 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). The underlay to overlay address mapping uses a deterministic algorithm and allows routing of packets between containers without the need to maintain any additional state.

In the case of the above networks (/16 underlay and /8 overlay), each host address on the underlay maps to a range of 253 addresses on the overlay. FAN networking can thus be considered a form of “address expansion”.

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

Configuring a Juju model to use FAN networking

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=

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
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

See Configuring models for more details on setting model options.

Cloud provider support for FAN networking

FAN networking can be enabled on all cloud substrates that Juju supports. Note however that MAAS has LXD addressing built-in so there is no point in enabling FAN support in such a context.

Juju will automatically configure FAN networking when bootstrapping a controller on AWS and GCE clouds. As such, no further configuration is required to use the FAN.

For any other cloud provider, FAN support can be enabled by manually providing the required configuration options for the underlay and overlay networks as described in the previous section.

Establishing SSH connections to units with a FAN address

As FAN addresses are generally allocated from a private subnet (e.g., Juju clients cannot directly establish an SSH connection to application units which are only assigned a FAN address.

The juju ssh command supports a --proxy flag which instructs the Juju client to use the controller machine as a jump box for reaching the private FAN address of a particular unit.

Verifying container connectivity when using FAN networking

The following steps demonstrate how to test connectivity between containers running on different machines that have been assigned an address in the overlay network provided by FAN.

This example assumes that a controller has been bootstrapped on AWS. However, the verification steps also apply to any Juju deployment where FAN networking has been (automatically or manually) enabled.

To auto-configure FAN networking on AWS, a virtual private cloud (VPC) is required. The majority of AWS accounts nowadays provide a VPC out of the box so no further steps are required.

However, If you are using an old AWS account that does not provide a VPC you will need to follow the instructions outlined in Creating an AWS VPC before proceeding.

The following commands will first create two new machines and then deploy mysql and wordpress as LXD containers on each machine. Then, the two applications are related together.

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

Running jujus status should show the units for each application as active. In addition, each unit will be assigned an address on the FAN overlay network (in this case we are using as the overlay subnet):

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

We can verify that the mysql container can indeed contact the wordpress container with the following command:

wordpress_ip=$(juju show-unit wordpress/0 | grep public-address | awk '{print $2}')
juju ssh --proxy mysql/0 nc -vz $wordpress_ip

If the two containers can reach each other, the above command will yield the following output:

Connection to 80 port [tcp/http] succeeded!