Update #3 – 27 January 2020: Fedora requires special instructions for routed to work. See the section below named The routed profile for Fedora for more.
UPDATE #2 – 26 January 2020: Debian requires special instructions for routed to work. See the section below named The routed profile for Debian for more.
UPDATE #1 – 11 August 2020: Ubuntu 20.04 as a container did not work with the instructions in this post. There is a need for an addition to the profile in order to make it work for both older versions of Ubuntu and newer versions (Ubuntu 18.04 and Ubuntu 20.04). The addition is for
on-link: true in the cloud-init section in the LXD profile. This post has been updated to cover the addition of
You are using LXD containers and you want a container (or more) to get an IP address from the LAN (or, get an IP address just like the host does).
LXD currently supports four ways to do that, and depending on your needs, you select the appropriate way.
macvlan. See https://blog.simos.info/how-to-make-your-lxd-container-get-ip-addresses-from-your-lan/
bridged. See https://blog.simos.info/how-to-make-your-lxd-containers-get-ip-addresses-from-your-lan-using-a-bridge/
routed. It is this post, read on.
ipvlan. This tutorial is pending.
Why use the
You would use the
routed network if you want to expose containers to the local network (LAN, or the Internet if you are using an Internet server, and have allocated several public IPs).
Any containers with
routed will appear on the network to have the MAC address of the host. Therefore, this will work even when you use it on your laptop that is connected to the network over WiFi (or any router with port security). That is, you can use
bridged cannot work.
You have to use static network configuration for these containers. Which means,
- You need to make sure that the IP address on the network that you give to the
routedcontainer, will not be assigned by the router in the future. Otherwise, there will be an IP conflict. You can do so if you go into the configuration of the router, and specify that the IP address is in use.
- The container (i.e. the services running in the container) should not be performing changes to the network interface, as it may mess up the setup.
Requirements for Ubuntu containers
The default network configuration in Ubuntu 18.04 or newer is to use
netplan and get
eth0 to use DHCP for the configuration. The way
netplan does this, messes up with
routed, so we are using a workaround. This workaround is required only for the Ubuntu container images. Other distributions like CentOS do not require it. The workaround is based on
cloud-init, so it is the whole section for
cloud-init in the profile below.
routed LXD profile
Here is the
routed profile, which has been tested on Ubuntu. Create a profile with this name. Then, for each container that uses the
routed network, we will be creating a new individual profile based on this initial profile. The reason why we create such individual profiles, is that we need to hard-code the IP address in them. Below, in bold, you can see the values that can be changes, specifically, the IP address (in two locations, replace with your own public IP addresses), the parent interface (on the host), and the nameserver IP address (that one is a public DNS server from Google). You can create an empty profile, then edit it and replace the existing content with the following (
lxc profile create routed,
lxc profile edit routed).
config: user.network-config: | version: 2 ethernets: eth0: addresses: - 192.168.1.200/32 nameservers: addresses: - 184.108.40.206 search:  routes: - to: 0.0.0.0/0 via: 169.254.0.1 on-link: true description: Default LXD profile devices: eth0: ipv4.address: 192.168.1.200 nictype: routed parent: enp6s0 type: nic name: routed_192.168.1.200 used_by:
We are going to make copies of the
routed profile to individual new ones, one for each IP address. Therefore, let’s create the LXD profiles for
192.168.1.201. When you edit them
$ lxc profile copy routed routed_192.168.1.200 $ EDITOR=nano lxc profile edit routed_192.168.1.200 $ lxc profile copy routed routed_192.168.1.201 $ EDITOR=nano lxc profile edit routed_192.168.1.201
We are ready to test the profiles.
(alternative) The routed LXD profile for Debian
The following is an alternative LXD
routed profile that can be used on Debian and was created by tomp. It might be useful for other Linux distributions as well. If this specific LXD profile works for a distribution other than Debian, please report it below so that I can update the post. It explicitly makes the container not to set network configuration through DHCP. It further uses
cloud-init instructions to manually create a
/etc/resolv.conf because without DHCP there wouldn’t be such a file in the container. The suggested DNS server is 220.127.116.11 (Google), and you may change if you would like. In bold, you can see the two items that you need to update for your case; the IP address for the container, and the network interface of the host that this container will attach to (through
config: user.network-config: | #cloud-config version: 2 ethernets: eth0: dhcp4: false dhcp6: false routes: - to: 0.0.0.0/0 via: 169.254.0.1 on-link: true user.user-data: | #cloud-config bootcmd: - echo 'nameserver 18.104.22.168' > /etc/resolvconf/resolv.conf.d/tail - systemctl restart resolvconf description: Default LXD profile devices: eth0: ipv4.address: 192.168.1.201 name: eth0 nictype: routed parent: enp3s0 type: nic name: routed_debian
(alternative) The routed LXD profile for Fedora
The following is an alternative LXD
routed profile that can be used on Fedora and was created by tomp. It might be useful for other Linux distributions as well. If this specific LXD profile works for a distribution other than Fedora, please report it below so that I can update the post. The profile has two sections; the
cloud-init section that configures once the networking in the container using NetworkManager, and the LXD network configuration that directs LXD on how to setup the
routed networking on the host. The suggested DNS server is 22.214.171.124 (Google), and you may change if you would like with other free public DNS servers. In bold, you can see the two items that you need to update for your case; the IP address for the container, and the network interface of the host that this container will attach to (through
Note that you would launch the container with a command line
lxc launch images:fedora/33/cloud fedora --profile default --profile routed_for_fedora
config: user.user-data: | #cloud-config bootcmd: - nmcli connection modify "System eth0" ipv4.addresses 192.168.1.201/32 - nmcli connection modify "System eth0" ipv4.gateway 169.254.0.1 - nmcli connection modify "System eth0" ipv4.dns 126.96.36.199 - nmcli connection modify "System eth0" ipv4.method manual - nmcli connection down "System eth0" - nmcli connection up "System eth0" description: Default LXD profile devices: eth0: ipv4.address: 192.168.1.201 name: eth0 nictype: routed parent: enp3s0 type: nic name: routed_for_fedora
routed network in LXD
We create a container called myrouted using the
default profile and on top of that the
$ lxc launch ubuntu:18.04 myrouted --profile default --profile routed_192.168.1.200 Creating myrouted Starting myrouted $ lxc list -c ns4t +------+---------+----------------------+-----------+ | NAME | STATE | IPV4 | TYPE | +------+---------+----------------------+-----------+ | myr..| RUNNING | 192.168.1.200 (eth0) | CONTAINER | +------+---------+----------------------+-----------+ $
According to LXD, the container has configured its IP address that was packaged into the cloud-init configuration.
Get a shell into the container and ping
- your host
- your router
- an Internet host such as
All of the above should work. Finally, ping from the host to the IP address of the container. It should work as well.
You have configured
routed in LXD so that one or more containers can get IP addresses from the network. Using a profile helps to automate the process. Still, if you want to setup manually, see the references above for instructions.