Different behaviors with nictype ipvlan depending on Ubuntu images

LXD
1

Hello,

I am having trouble understanding the behavior of the ipvlan device. My goal is to get a container with another IP and the same MAC Address as the host.

My container is configured as follow:

architecture: x86_64
config:
  image.architecture: amd64
  image.description: ubuntu 19.04 amd64 (release) (20200109)
  image.label: release
  image.os: ubuntu
  image.release: disco
  image.serial: "20200109"
  image.type: squashfs
  image.version: "19.04"
  limits.cpu: "1"
  limits.memory: 2GB
  volatile.base_image: acb8f742bfffa41f924939857b470b1ee6b55314e7219c65a7e982e0319ef3c5
  volatile.eth0.last_state.created: "false"
  volatile.eth0.name: eth0
  volatile.eth1.host_name: vethffe9c106
  volatile.eth1.hwaddr: 00:16:3e:9b:b4:09
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.power: RUNNING
devices:
  eth0:
    ipv4.address: XX.XX.XX.XX
    nictype: ipvlan
    parent: ens5f0
    type: nic
  eth1:
    name: eth1
    nictype: bridged
    parent: lxdbr1vlan10
    type: nic
ephemeral: false
profiles:
- default
stateful: false
description: ""

With the ubuntu:19.04, it works and the container is able to get the requested IP:

ubuntu@n4:~$ lxc ls loadbalancer
+-------------------+---------+----------------------+------+-----------+-----------+----------+
|       NAME        |  STATE  |         IPV4         | IPV6 |   TYPE    | SNAPSHOTS | LOCATION |
+-------------------+---------+----------------------+------+-----------+-----------+----------+
| loadbalancer      | RUNNING | XX.XX.XX.XX   (eth0) |      | CONTAINER | 0         | n4       |
|                   |         | 10.0.0.73 (eth1)     |      |           |           |          |
+-------------------+---------+----------------------+------+-----------+-----------+----------+

But with every other images I tried (including ubuntu:19.10, ubuntu:20.04, ubuntu:20.10, ubuntu:18.04), the container fails to get an IP:

xc ls loadbalancer
+-------------------+---------+------------------+------+-----------+-----------+----------+
|       NAME        |  STATE  |       IPV4       | IPV6 |   TYPE    | SNAPSHOTS | LOCATION |
+-------------------+---------+------------------+------+-----------+-----------+----------+
| loadbalancer      | RUNNING | 10.0.0.73 (eth1) |      | CONTAINER | 0         | n4       |
+-------------------+---------+------------------+------+-----------+-----------+----------+

I have not been able to find out why 19.04 is the only image with which it worked (I was lucky to try with this one on 2nd attempt).

I am on LXD 4.1 and host is Ubuntu 19.10.

Thanks for your help.

2

So ipvlan works by pre-configuring the network interface with an IP address before moving it into the container at startup. If anything inside the container then resets the interface, then the IP will go.

This is commonly caused by networkd or netplan.

Just a hunch, but have you tried swapping the eth0 and eth1 devices around (i.e ipvlan as eth1 and bridge as eth0) as the ubuntu images usually have eth0 setup inside to use dhcp (which would cause the reset mentioned above).

If you moved it to eth1 you may find it is left alone.

1 Like
3

@tomp thanks for the explanation, indeed it was netplan with the /etc/netplan/50-cloud-init.yaml file that modified the interface after startup:

# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        eth0:
            dhcp4: true

After removing the file and restarting the container, the IP is obtained and remains up.

I still don’t know why 19.04’s netplan behaved differently but I guess that’s an Ubuntu question.

Thanks again for your help :slight_smile:

1 Like