Should lxc start network with lxc.net.0.flags = up and without any net init script inside CT?

LXC
1

Something went wrong again :frowning:

lxc-create -n test-1 -t download -B loop --fssize 5G --fstype ext4 -- -d centos -r 7 -a amd64

cat <<EOF >/var/lib/lxc/test-1/config
# Template used to create this container: /usr/share/lxc/templates/lxc-download
# Parameters passed to the template: -d centos -r 7 -a amd64
# Template script checksum (SHA-1): 273c51343604eb85f7e294c8da0a5eb769d648f3
# For additional config options, please look at lxc.container.conf(5)

# Uncomment the following line to support nesting containers:
#lxc.include = /usr/share/lxc/config/nesting.conf
# (Be aware this has security implications)

# Distribution configuration
lxc.include = /usr/share/lxc/config/common.conf
lxc.arch = x86_64

# Container specific configuration
lxc.rootfs.path = loop:/var/lib/lxc/test-1/rootdev
lxc.uts.name = test-1

# Network configuration
lxc.net.0.flags = up
lxc.net.0.ipv4.address = 192.168.51.208/22
lxc.net.0.ipv4.gateway = 192.168.50.250
lxc.net.0.link = br0
lxc.net.0.name = eth0
lxc.net.0.type = veth
EOF

lxc-start test-1
lxc-attach test-1

now what we see: ip a says us eth0 is in UP state with correct address 192.168.51.208 but ip r says - there is no default gateway. Ok, here is default net script /etc/sysconfig/network-scripts/ifcfg-eth0 trying to get dhcp, lets remove it. rm -rf /etc/sysconfig/network-scripts/ifcfg-eth0 ; shutdown -h now . Start CT again lxc-start test-1 , and now eth0 with correct address 192.168.51.208 but in DOWN state and there is still no default gateway. BTW with lxc.net.1... (eth1) all works fine. What i broke on this time? :’(

2

First, for future proofing, please ensure the lxc.net.0.type = veth is first before any other lxc.net.0.* lines.

You mention that lxc.net.1 is working ok, does that mean you’ve specified a gateway on both nics, as you cannot have 2 default gateways.

3

hey @tomp ! Glad to see you again!
Tried to set lxc.net.0.type = veth before others lxc.net.0.* - it has no effect.
No, i removed default gateway from lxc.net.0 and then set it to lxc.net.1 and lxc.net.1 (eth1) works as expected (state UP and with default getaway)

4

Current versions of LXC will require you to set type first before other config, so just a heads up to start doing that to avoid problems in the future.

If it works when passing the NIC in as eth1 then it means some network config inside the container is wiping the default route. This will be distro dependent. It may be trying to do a DHCP request, so ensuring that DHCP client is disabled in network config would be a good start.

5

Yes, i tried to move lxc.net.0.type = veth to config’s head - but it has no effect.
And yes there is a config /etc/sysconfig/network-scripts/ifcfg-eth0 who ttried to get ippadr with DHCP, but as i said - i tried to del it, and it didn’t help too.
I have no idea what might be wrong with default centos template :frowning:

6

I wouldn’t expect it to have any effect, not yet anyway. But in the future itll save it from breaking.

My suggestion would be to run tcpdump on the host-side of the veth pair and check no DHCP requests are coming from the container, if they are, then its still enabled somehow.

7

But how i can do that, if after remove /etc/sysconfig/network-scripts/ifcfg-eth0 eth0 is in DOWN state? As i asked in title: shouldn’t lxc.net.0.flags = up UP interface on container start?

8

Looks like the commit by @monstermunchkin is the problem here:

You can fix it by doing systemctl disable network-device-down.service.
And then I set the network config to:

/etc/sysconfig/network-scripts/ifcfg-eth0 
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
HOSTNAME=test-1
NM_CONTROLLED=no
TYPE=Ethernet
MTU=
9

Have opened issue to see if we can fix it without breaking something else:

10

wow, @tomp u are too fast 4 me :slight_smile:
Yeah, i remembered that i have an old build (20200427_07:08) , so i find commit before this date, built it with distrobuilder build-lxc centos.yaml -o image.architecture=x86_64 -o image.release=7 and there is no such problem!

1 Like