vethXXXXX interfaces are not removed when lxc container is stopped


(Michael) #1

Hallo! I am now observing strange behaviour in lxc containers networking. I use my custom bridge device (br0) to provide network connection as follows:

    lxc.net.0.type = veth
    lxc.net.0.name = eth0
    lxc.net.0.hwaddr = 00:16:3e:6e:13:a9
    lxc.net.0.link = br0
    lxc.net.0.ipv4.address = 10.194.15.7/16
    lxc.net.0.ipv4.gateway = 10.194.99.70
    lxc.net.0.ipv6.address = 2001:db8:0:300::15:7/64
    lxc.net.0.ipv6.gateway = 2001:db8:0:300::70
    lxc.net.0.flags = up

When container is started, vethXXXXXX interface is created and added to br0 bridge.
So far so good.
When I stop the container, this interface is not deleted and on next startup a new one is created. After that weird things start to happen: duplicate ipv6 ip addresses are reported, when container is stopped it’s ipv6 address can still be pinged, though nmap does not discover any port on it. Connectivity to container via ipv6 is lost after such restart.
When I manually identify and remove (using brctl delif and ip link del commands) all leftover interfaces, container starts working properly.

I am using lxc 3.1.0+really3.0.3-8 version from debian sid.

Best regards,


(Stéphane Graber) #2

That sounds like a kernel bug.

Normally when the last process in a container dies, the kernel destroys all the namespaces, including the network namespace which contains the container side interface of the veth pair used to give your container connectivity.

In your case, something is keeping that network namespace active, which then keeps that veth device active in the container including its IP address.

Unfortunately you deleting the host side device just papers over the issue, you’re still leaking kernel resources in the background with little you can really do to track and fix this.

We have planned kernel work which should make it easier to identify such issues in the future.