Debian LXC container not getting an IP

[inxsible]

I have 3 containers -- 2 Arch based and 1 Debian based. They all startup on boot (of the proxmox host) but for some reason, the debian container will not be assigned an IP address. No issues with the Arch based containers. All my containers and VMs are setup as DHCP and are assigned a specific IP by the pfSense router.

I did disable the ipv6 for the debian container because it was taking 8+ minutes for the login prompt to show up when restarting the container. Again, I did NOT have this issue with the Arch based containers.

The weird thing is that if I manually restart the Debian container from the Proxmox Web UI, I can see the IP get assigned and

ip addr

shows me the IP that I have specified in the router. It's only at reboot of the proxmox host that I get this issue ( I have another thread where my VMs don't start up on reboot of the host --but it's awaiting moderation before being public -- possibly because I put in a couple of screenshots.)

 

[oguz]

hi,

please post:

* pct config CTID
* ip a && ip r inside container (when it boots and doesn't work)

All my containers and VMs are setup as DHCP and are assigned a specific IP by the pfSense router.

i assume you gave the correct MAC of the CT to the pfsense, but it doesn't hurt to check that as well.

It's only at reboot of the proxmox host that I get this issue

if your pfsense is virtualized, then maybe the dhcp server doesn't come up in time for the CTs to get an IP?

 

[inxsible]

hi,

please post:

* pct config CTID
* ip a && ip r inside container (when it boots and doesn't work)

container config -- i added a nas mount so I could copy over my zsh and vim configs. this container doesn't need nas access, and I intend to remove the mount point once I have the container working as expected.

arch: amd64
cores: 1
hostname: heimdall
memory: 512
mp0: /mnt/pve/media/downloads,mp=/mnt/freenas
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BA:C6:85:59:43:30,ip=dhcp,ip6=dhcp,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-103-disk-0,size=4G
swap: 512
unprivileged: 1
lxc.mount.auto: sys

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
38: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ba:c6:85:59:43:30 brd ff:ff:ff:ff:ff:ff link-netnsid 0

No output for ipr

i assume you gave the correct MAC of the CT to the pfsense, but it doesn't hurt to check that as well.


if your pfsense is virtualized, then maybe the dhcp server doesn't come up in time for the CTs to get an IP?

Yes, I did double check the MAC. Again, if I start the container manually from the WebUI, then it gets the IP assigned without any problem, so the setup in the router must be correct.

My pfSense is not virtualized. It's on bare metal in a separate box.

Just FYI, this only happens to my 1 Debian container -- my other 3 Archlinux container have no problems. I had to use Debian for the Heimdall, as the latest php version in Arch (7.4) is incompatible with heimdall which requires 7.1 -7.3.

 

[oguz]

I did disable the ipv6 for the debian container

ip=dhcp,ip6=dhcp,type=veth

ipv6 isn't disabled. select 'static' and leave it empty on the network settings.

then try stop/starting the container and check the ip a && ip r output again. post it if it's any different but still doesn't work

 

[inxsible]

ipv6 isn't disabled.

I didn't mention this earlier, sorry. But I disabled it inside the container by adding the following 3 lines in the sysctl.conf :

net.ipv6.conf.all.disable_ipv6 =1
net.ipv6.conf.default.disable_ipv6 =1
net.ipv6.conf.lo.disable_ipv6 =1

Do I need to disable it in the proxmox container config too ?

 

[oguz]

Do I need to disable it in the proxmox container config too ?

yes

 

[inxsible]

because ip a didn't display an inet6 address, I thought it wouldn't matter if the CT config had ipv6 enabled or not.

ok. let me disable it in CT config and test it out again. Thank you.

 

[inxsible]

I just realized that the debian container was losing the ip assigned after some time.

I had manually started the container and had an IP, but now when I went in to disable the IPv6, I just checked ip a and I had no IP assigned. So it seems that the container was losing IP address.

I have now disabled IPv6 from the container config and restarted networking.service --- which has given me the IP again. Will wait to see if it loses it again.

 

[oguz]

I have now disabled IPv6 from the container config and restarted networking.service --- which has given me the IP again. Will wait to see if it loses it again.

did that work?

 

[inxsible]

Sorry for the delayed reply. But I didn't have a chance to do multiple reboots of the server. However, ever since I disabled the IPv6 in the container conf file, I haven't seen any loss of IP address in that container. So the problem seems to be resolved.

However, I still don't know why Debian containers lose an IPv4 address when looking for an IPv6 address when I have no such problem with my 5 Archlinux containers. I never bothered to shut off IPv6 in my Archlinux containers even though my network router/dhcp server, pfSense, has IPv6 disabled.

 

[luciferlu]

Yes I have the same problem with lxc debian 10.
I need ipv6 so I let ipv4 & v6 both dhcp.
But ipv4 will lose its ip addr so I have to let the networking service restart to temp solve this problem.

 

[TonyArr]

So this still seems to be a problem, I'm having the same loss of IPv4 addresses in LXC Debian containers. I've just changed IPv6 from DHCP (seems to be the default) to static and left the details blank, and have't lost the IPv4 address over the last 24 hours like has been happening so far.
Anyone know the why of this happening? I might end up needing to use IPv6 addresses in the future so it would be good to know if the root cause of this can be solved rather than having to remember to set up a workaround whenever using Debian containers...