How to get LXD containers get IP from the LAN with routed network

UPDATE 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 on-link: true.

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.

  1. Using macvlan. See https://blog.simos.info/how-to-make-your-lxd-container-get-ip-addresses-from-your-lan/
  2. Using bridged. See https://blog.simos.info/how-to-make-your-lxd-containers-get-ip-addresses-from-your-lan-using-a-bridge/
  3. Using routed. It is this post, read on.
  4. Using ipvlan. This tutorial is pending.

For more on the routed network option, see the LXD documentation on routedand this routed thread on the LXD discussion forum.

Why use the routed network?

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 routed when macvlan and bridged cannot work.

You have to use static network configuration for these containers. Which means,

  1. You need to make sure that the IP address on the network that you give to the routed container, 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.
  2. 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.

The routed LXD profile

Here is the routed profile. 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:
                - 8.8.8.8
                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.200 and 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.

Using the routed network in LXD

We create a container called myrouted using the default profile and on top of that the routed_192.168.1.200 profile.

$ 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

  1. your host
  2. your router
  3. an Internet host such as www.google.com.

All of the above should work. Finally, ping from the host to the IP address of the container. It should work as well.

Conclusion

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.

Permanent link to this article: https://blog.simos.info/how-to-get-lxd-containers-get-ip-from-the-lan-with-routed-network/

23 comments

Skip to comment form

    • Brudi on May 9, 2020 at 10:15

    lmao Im pretty sure your blog is far more useful and comprehensive than the LXD documentation itself

    • Aanjaneya on May 25, 2020 at 17:25

    This does not work with Ubuntu 20.04. While it does work with Ubuntu 18.04 but is very picky or sensitive meaning that I do get the required IP but cannot ping. Once I delete the container and launch again with a different routed profile (with different IP). I have not tested further than ping on 18.04.

    • Aanjaneya on May 25, 2020 at 20:37

    By the way I am using archlinux based Manjaro Linux as host and ubuntu 20.04 as lxc container. but then it worked with ubuntu 18.04 even though a bit unpredictable.

    • Aanjaneya on May 25, 2020 at 22:02

    After some digging. I found that in Ubuntu 20.04 something has changed. Here are the results of relevant network commands after creating and launching the 20.04 and 18.04 containers:

    Ubuntu 20.04:


    ip route
    default via 192.168.0.1 dev wlp2s0 proto static metric 600
    10.10.10.0/24 dev lxdbr0 proto kernel scope link src 10.10.10.1 linkdown
    192.168.0.0/24 dev wlp2s0 proto kernel scope link src 192.168.0.2 metric 600
    192.168.0.51 dev vethe1bcc11c scope link
    192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

    ip neigh show proxy
    169.254.0.1 dev vethe1bcc11c proxy
    192.168.0.51 dev wlp2s0 proxy

    lxc exec focalheadless-1 ip r

    No on Ubuntu 18.04


    ip route
    default via 192.168.0.1 dev wlp2s0 proto static metric 600
    10.10.10.0/24 dev lxdbr0 proto kernel scope link src 10.10.10.1 linkdown
    192.168.0.0/24 dev wlp2s0 proto kernel scope link src 192.168.0.2 metric 600
    192.168.0.51 dev veth8b310893 scope link
    192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

    ip neigh show proxy
    169.254.0.1 dev veth8b310893 proxy
    192.168.0.51 dev wlp2s0 proxy

    lxc exec bionic-1 ip r
    default via 169.254.0.1 dev eth0 ----> we receive result here in side the container

    Also you may notice a slight difference in vethe1bcc11c and veth8b310893. Though I am not sure about this.

    • sdfsasfsda on July 2, 2020 at 13:44

    For years I’m been coming to your blog for guidance on this LXD exposing to LAN issue. Thank you so much

    1. Thank you for your kind words!

    • Ponder Muse on August 9, 2020 at 12:55

    I am new to lxc and I am trying to setup a routed profile for an lxc container in order to make the container reachable from the host as well as other servers on the local network over a wifi interface.

    I am following the steps in this page and although the profile created successfully, when I add it to the lxc container and restart the container, no IP address is ever assigned to the container.

    Where would I need to look for logs to get an idea of where the setup is going wrong?

    I am trying this on Ubuntu 20.04 using lxc version 4.0.2.

    Thanks in advance,
    PM

    1. Hi!

      You mention the version 4.0.2. Do you use the lxd snap package and are tracking the 4.0/stable channel?

      If instead you are using LXC (see https://blog.simos.info/comparison-between-lxc-and-lxd/), then this post does not apply there.

      You can show the full LXD profile for the routed network, plus the command you use to launch the LXD container.
      You can view any container errors by running the command lxc info --show-log myrouted.

        • Ponder Muse on August 9, 2020 at 18:12

        Hello Simos,

        Sorry, yes. I am using lxd snap package 4.0/stable.

        Profile for routed network:

        $ lxc profile show testRoutedProfile
        config:
          user.network-config: |
            version: 2
            ethernets:
              eth0:
                addresses:
                - 192.168.1.100/32
                nameservers:
                  addresses:
                  - 8.8.8.8
                    search: []
                routes:
                - to: 0.0.0.0/0
                  via: 192.168.1.1
        description: Test Server Routed Profile
        devices:
          eth0:
            ipv4.address: 192.168.1.100
            nictype: routed
            parent: wlo1
            type: nic
        name: testRoutedProfile
        used_by:
        - /1.0/instances/test-server
        

        Command to add the created routed network profile:

        $ lxc profile add test-server testRoutedProfile
        

        Command to launch the LXD container:

        $ lxc start test-server</code>
        

        Command to show container log:

        $ lxc info --show-log test-server
        Name: test-server
        Location: none
        Remote: unix://
        Architecture: x86_64
        Created: 2020/08/08 18:03 UTC
        Status: Running
        Type: container
        Profiles: default, testRoutedProfile
        Pid: 38634
        Ips:
          lo:   inet    127.0.0.1
          lo:   inet6   ::1
          eth0: inet6   fe80::cc47:37ff:febc:933e   veth67de2a5b
        Resources:
          Processes: 45
          CPU usage:
            CPU usage (in seconds): 4
          Memory usage:
            Memory (current): 135.88MB
            Memory (peak): 167.17MB
          Network usage:
            lo:
              Bytes received: 316B
              Bytes sent: 316B
              Packets received: 4
              Packets sent: 4
            eth0:
              Bytes received: 7.48kB
              Bytes sent: 4.49kB
              Packets received: 47
              Packets sent: 24
        

        Log:

        lxc test-server 20200809165847.736 WARN cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - File exists - Failed to create directory "/sys/fs/cgroup/cpuset//lxc.monitor.test-server"
        lxc test-server 20200809165847.738 WARN cgfsng - cgroups/cgfsng.c:mkdir_eexist_on_last:1152 - File exists - Failed to create directory "/sys/fs/cgroup/cpuset//lxc.payload.test-server"
        lxc test-server 20200809165847.741 WARN cgfsng - cgroups/cgfsng.c:fchowmodat:1573 - No such file or directory - Failed to fchownat(17, memory.oom.group, 1000000000, 0, AT_EMPTY_PATH | AT_SYMLINK_NOFOLLOW )

        Command showing container list:

        $ lxc list
        +-------------+---------+------+------+-----------+-----------+
        |    NAME     |  STATE  | IPV4 | IPV6 |   TYPE    | SNAPSHOTS |
        +-------------+---------+------+------+-----------+-----------+
        | test-server | RUNNING |      |      | CONTAINER | 0         |
        +-------------+---------+------+------+-----------+-----------+
        

        Command showing profiles used:

        $ lxc profile list
        +-------------------+---------+
        |       NAME        | USED BY |
        +-------------------+---------+
        | default           | 1       |
        +-------------------+---------+
        | testRoutedProfile | 1       |
        +-------------------+---------+
        

        There isn’t much shown in the log in terms of networking errors as far as I can see.

        Thanks in advance,
        PM

      1. The difference that I notice, is that in the profile the via: has a different IP address from the one I give above. The 169.x.x.x that I give in the post, is a workaround around an issue in the configuration of the Linux distribution in the container. Perhaps the 192.168.1.1 is a valid IP address, hence it causes an issue.

        • Ponder Muse on August 11, 2020 at 12:36

        When I first configured the routed profile I wasn’t clear on the meaning of the address 169.254.0.1 so I was incorrectly guessing it maybe needed to be my network’s gateway address. I have since corrected it and now it is set back to via: 169.254.0.1. I am learning about networking in general at the same time as I am learning all about lxc.

      2. I have updated this post with information about the issue with Ubuntu 20.04 LTS in the routed_ container. There is a need for an additional line in the LXD profile to make it work with Ubuntu 20.04 LTS. Requires the addition of the line on-link: true in the LXD profile.

    • bmullan on August 10, 2020 at 00:22

    @simos

    In your routed config there is a line:

    via: 169.254.0.1

    But that IP is not highlighted and nowhere does it say what it is or where its from?

    Thanks for any info

    Brian Mullan

      • bmullan on August 10, 2020 at 01:03

      @simos
      Never mind I searched and found out 169.254.0.1 gets assigned by lxd for the routed inteface

    • bmullan on August 10, 2020 at 02:22

    Simos

    I am on Ubuntu 20.04 system with my Wifi Interface on Host = wlp3s0

    whose IP is 192.168.1.81

    I tried your Profile but changed the Parent to wlp3s0

    = = = = = = =

    config:
    user.network-config: |
    version: 2
    ethernets:
    eth0:
    addresses:
    – 192.168.1.200/32
    nameservers:
    addresses:
    – 8.8.8.8
    search: []
    routes:
    – to: 0.0.0.0/0
    via: 169.254.0.1
    description: Default LXD profile
    devices:
    eth0:
    ipv4.address: 192.168.1.200
    nictype: routed
    parent: wlp3s0
    type: nic
    name: routed
    used_by:

    = = = = = = =

    Created a test Ubuntu 20.04 container naamed “test”

    $ lxc launch ubuntu:18.04 test –profile default –profile routed_200

    $ lxc list
    shows Container test has IP address 192.168.1.200

    From HOST I can PING container’s IP 192.168.1.200

    From Container TEST I can Ping my Host: 192.168.1.81

    From Container TEST I can Ping my Router: 192.168.1.1

    From my Container I CANNOT Ping http://www.google.com or any other Internet site or IP.

    Any ideas?

    Thanks
    Brian Mullan

    1. I also have tested this post on Ubuntu 18.04 with a WiFi interface. And it worked for me.

      Have a look at /etc/resolv.conf in the container. It should mention the stub resolver IP address, 127.0.0.53.

      Then, run systemd-resolve --status and verify there that the actual DNS server is 8.8.8.8. Should look like

      Link 2 (eth0)
            Current Scopes: DNS
             LLMNR setting: yes
      MulticastDNS setting: no
            DNSSEC setting: no
          DNSSEC supported: no
               DNS Servers: 8.8.8.8
      
    2. Apparently, the failure to work was related to newer container images, based on Ubuntu 20.04 LTS. The host being 20.04 LTS does not appear to affect here (correct me if I am wrong).

      I have updated the post per discussion on DLO (discuss.linuxcontainers.org) that Ubuntu 20.04 (in container) requires on-link: true.

    • Ponder Muse on August 10, 2020 at 13:17

    @simos, @bmullan,

    Having re-read this blog and having read bmullan’s comments, I have now been able to get the container networked over wifi using the routed profile. I can list two things that I have changed that made things work but, I don’t know what it is in particular about each one of them that was causing the issues beforehand.

    Issue 1 – My container existed before creating the routed profile so, after creating the routed profile, I was simply stopping the container (lxc stop test-server) adding the routed profile to the container (lxc profile add test-server testRoutedProfile) and thereafter starting the container (lxc start test-server). This was causing the container to never pick up the routed profile’s configuration for some reason so, I then stopped and deleted the container altogether (lxc stop test-server, lxc delete test-server) and I then recreated it using the command included in this blog page (lxc launch ubuntu:20.04 test-server –profile default –profile testRoutedProfile). Using the launch command, the container then did get the IP address assigned but, exec-ing into the container I could still not ping the host from the container. But it was progress at least…

    Issue 2 – as bmullan pointed out, he mentioned something not quite right with his setup using ubuntu 20.04 so I followed the advice given and I recreated the container using ubuntu 18.04 instead (lxc launch ubuntu:18.04 test-server –profile default –profile testRoutedProfile). I can confirm that with ubuntu 18.04 the networking is setup correctly and I can now ping the host, my gateway and the web (e.g. http://www.google.com) from inside the container. Any ideas why ubuntu 18.04 container works with routed profile but not ubuntu 20.04?

    Cheers,
    PM

    1. Regarding the first issue: The configuration in the cloud-init section only runs when the container starts for the first time. Therefore, it is expected not to run when you apply the profile to an existing container. There are some instructions on how to reset a container/VM so that cloud-init will run again on the next restart.

      Regarding the second issue: I launch a routed 20.04 container on Ubuntu 18.04, and got the same issue. There is no default route, hence the issue. The DNS server is configured properly, so if the default route where to get set, the DNS would work fine.
      Still investigating this.

      1. I have updated this post with the fix for Ubuntu 20.04 LTS in the container. You would need to update your routed profile by adding a line shown in the post, then recreate the container.
        If you already have a container and you do not want to recreate it, you can edit /etc/netplan/50-cloud-init.yaml and add there the line. Finally, restart the container.

    • Ponder Muse on August 17, 2020 at 17:34

    Hello @simos,

    updated the profiles to include on-link: true as you suggested and I can confirm that Ubuntu 20.04 containers using routed profiles are now networked as expected.

    Cheers,
    PM

  1. @Ponder Muse: Thanks for verifying!

    • bmullan on August 18, 2020 at 19:36

    @Ponder Muse does your host use wifi or eth ?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: