[SOLVED] Debian 13 LXC networking.service failed

D

devilkin

Well-Known Member
May 11, 2020
42
6
48
I'm trying to figure out why on an older debian LXC (now version 12, but it has had atleast 2 major updates) the network.service comes back failed after bootup

Code: 
ug 08 10:34:24 metricsbox systemd[1]: Starting networking.service - Raise network interfaces...
Aug 08 10:34:24 metricsbox dhclient[106]: Internet Systems Consortium DHCP Client 4.4.3-P1
Aug 08 10:34:24 metricsbox ifup[106]: Internet Systems Consortium DHCP Client 4.4.3-P1
Aug 08 10:34:24 metricsbox dhclient[106]: Copyright 2004-2022 Internet Systems Consortium.
Aug 08 10:34:24 metricsbox ifup[106]: Copyright 2004-2022 Internet Systems Consortium.
Aug 08 10:34:24 metricsbox dhclient[106]: All rights reserved.
Aug 08 10:34:24 metricsbox ifup[106]: All rights reserved.
Aug 08 10:34:24 metricsbox dhclient[106]: For info, please visit https://www.isc.org/software/dhcp/
Aug 08 10:34:24 metricsbox ifup[106]: For info, please visit https://www.isc.org/software/dhcp/
Aug 08 10:34:24 metricsbox dhclient[106]:
Aug 08 10:34:24 metricsbox dhclient[106]: Listening on LPF/eth0/12:44:5b:cc:ac:12
Aug 08 10:34:24 metricsbox ifup[106]: Listening on LPF/eth0/12:44:5b:cc:ac:12
Aug 08 10:34:24 metricsbox ifup[106]: Sending on   LPF/eth0/12:44:5b:cc:ac:12
Aug 08 10:34:24 metricsbox ifup[106]: Sending on   Socket/fallback
Aug 08 10:34:24 metricsbox ifup[106]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Aug 08 10:34:24 metricsbox dhclient[106]: Sending on   LPF/eth0/12:44:5b:cc:ac:12
Aug 08 10:34:24 metricsbox dhclient[106]: Sending on   Socket/fallback
Aug 08 10:34:24 metricsbox dhclient[106]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Aug 08 10:34:24 metricsbox dhclient[106]: DHCPOFFER of 192.168.34.47 from 192.168.34.1
Aug 08 10:34:24 metricsbox ifup[106]: DHCPOFFER of 192.168.34.47 from 192.168.34.1
Aug 08 10:34:24 metricsbox ifup[106]: DHCPREQUEST for 192.168.34.47 on eth0 to 255.255.255.255 port 67
Aug 08 10:34:24 metricsbox dhclient[106]: DHCPREQUEST for 192.168.34.47 on eth0 to 255.255.255.255 port 67
Aug 08 10:34:24 metricsbox dhclient[106]: DHCPACK of 192.168.34.47 from 192.168.34.1
Aug 08 10:34:24 metricsbox ifup[106]: DHCPACK of 192.168.34.47 from 192.168.34.1
Aug 08 10:34:24 metricsbox dhclient[106]: bound to 192.168.34.47 -- renewal in 2947 seconds.
Aug 08 10:34:24 metricsbox ifup[106]: bound to 192.168.34.47 -- renewal in 2947 seconds.
Aug 08 10:34:25 metricsbox dhclient[156]: Internet Systems Consortium DHCP Client 4.4.3-P1
Aug 08 10:34:25 metricsbox ifup[156]: Internet Systems Consortium DHCP Client 4.4.3-P1
Aug 08 10:34:25 metricsbox ifup[156]: Copyright 2004-2022 Internet Systems Consortium.
Aug 08 10:34:25 metricsbox ifup[156]: All rights reserved.
Aug 08 10:34:25 metricsbox ifup[156]: For info, please visit https://www.isc.org/software/dhcp/
Aug 08 10:34:25 metricsbox dhclient[156]: Copyright 2004-2022 Internet Systems Consortium.
Aug 08 10:34:25 metricsbox dhclient[156]: All rights reserved.
Aug 08 10:34:25 metricsbox dhclient[156]: For info, please visit https://www.isc.org/software/dhcp/
Aug 08 10:34:25 metricsbox dhclient[156]:
Aug 08 10:34:25 metricsbox dhclient[156]: Can't bind to dhcp address: Cannot assign requested address
Aug 08 10:34:25 metricsbox ifup[156]: Can't bind to dhcp address: Cannot assign requested address
Aug 08 10:34:25 metricsbox ifup[156]: Please make sure there is no other dhcp server
Aug 08 10:34:25 metricsbox ifup[156]: running and that there's no entry for dhcp or
Aug 08 10:34:25 metricsbox ifup[156]: bootp in /etc/inetd.conf.   Also make sure you
Aug 08 10:34:25 metricsbox ifup[156]: are not running HP JetAdmin software, which
Aug 08 10:34:25 metricsbox ifup[156]: includes a bootp server.
Aug 08 10:34:25 metricsbox ifup[156]: If you think you have received this message due to a bug rather
Aug 08 10:34:25 metricsbox ifup[156]: than a configuration issue please read the section on submitting
Aug 08 10:34:25 metricsbox ifup[156]: bugs on either our web page at www.isc.org or in the README file
Aug 08 10:34:25 metricsbox ifup[156]: before submitting a bug.  These pages explain the proper
Aug 08 10:34:25 metricsbox ifup[156]: process and the information we find helpful for debugging.
Aug 08 10:34:25 metricsbox ifup[156]: exiting.
Aug 08 10:34:25 metricsbox dhclient[156]: Please make sure there is no other dhcp server
Aug 08 10:34:25 metricsbox dhclient[156]: running and that there's no entry for dhcp or
Aug 08 10:34:25 metricsbox dhclient[156]: bootp in /etc/inetd.conf.   Also make sure you
Aug 08 10:34:25 metricsbox dhclient[156]: are not running HP JetAdmin software, which
Aug 08 10:34:25 metricsbox dhclient[156]: includes a bootp server.
Aug 08 10:34:25 metricsbox dhclient[156]:
Aug 08 10:34:25 metricsbox dhclient[156]: If you think you have received this message due to a bug rather
Aug 08 10:34:25 metricsbox dhclient[156]: than a configuration issue please read the section on submitting
Aug 08 10:34:25 metricsbox dhclient[156]: bugs on either our web page at www.isc.org or in the README file
Aug 08 10:34:25 metricsbox dhclient[156]: before submitting a bug.  These pages explain the proper
Aug 08 10:34:25 metricsbox dhclient[156]: process and the information we find helpful for debugging.
Aug 08 10:34:25 metricsbox dhclient[156]:
Aug 08 10:34:25 metricsbox dhclient[156]: exiting.
Aug 08 10:34:25 metricsbox ifup[83]: ifup: failed to bring up eth0
Aug 08 10:34:25 metricsbox systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Aug 08 10:34:25 metricsbox systemd[1]: networking.service: Failed with result 'exit-code'.
Aug 08 10:34:25 metricsbox systemd[1]: Failed to start networking.service - Raise network interfaces.

It's configured to use dhcp for ipv4 and dhcp for ipv6 (both of which are available on my network)

Restarting networking.service fixes this issue, but a reboot later it's back.

A newly installed Debian 12 LXC does not face this issue. Once upgraded to 13 it shows up.

I'm really curious what exactly is causing this issue.
 
Last edited:
could you post the container config, as well as the contents of /etc/network/interfaces and /etc/network/interfaces.d/* from within the container?
 
Hi @fabian - I have to slightly correct myself: It started after upgrading to Trixie - I was comparing apples with oranges for a moment. I've upgraded the test-LXC also to Trixie, and this shows now the same behaviour.

The test LXC
Code: 
# cat 111.conf
arch: amd64
cores: 1
features: nesting=1
hostname: test
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:67:20:59,ip=dhcp,ip6=dhcp,tag=134,type=veth
ostype: debian
rootfs: local-zfs:subvol-111-disk-0,size=8G
swap: 512
unprivileged: 1

Code: 
# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

iface eth0 inet6 dhcp

No files in /etc/network/interfaces.d

To reproduce:

Install debian 12 LXC from the standard templates (which is a 12.7)
dist-upgrade to 13
Reboot.
 
Last edited:
it seems you can workaround this by

- making the network interfaces file in the container unmanaged ("touch /etc/network/.pve-ignore.interfaces")
- removing the inet6 line
- installing dhcpcd-base and removing isc-dhcp-client

could you verify this is the case? then we could stop generating the inet6 dhcp line for trixie+ in pve-container (which would then mean no longer requiring the .pve-ignore workaround)
 
  • Like
Reactions: azuriye, lildadou and devilkin
@fabian

This seems to work well. ipv4 + ipv6 are being assigned.

Code: 
Aug 08 12:08:30 test systemd[1]: Starting networking.service - Raise network interfaces...
Aug 08 12:08:30 test ifup[101]: dhcpcd-10.1.0 starting
Aug 08 12:08:30 test dhcpcd[101]: dhcpcd-10.1.0 starting
Aug 08 12:08:30 test ifup[104]: eth0: waiting for carrier
Aug 08 12:08:30 test ifup[104]: eth0: carrier acquired
Aug 08 12:08:30 test dhcpcd[104]: eth0: waiting for carrier
Aug 08 12:08:30 test dhcpcd[104]: eth0: carrier acquired
Aug 08 12:08:30 test ifup[104]: DUID 00:01:00:01:30:28:a5:3e:bc:24:11:67:20:59
Aug 08 12:08:30 test ifup[104]: eth0: IAID 11:67:20:59
Aug 08 12:08:30 test dhcpcd[104]: DUID 00:01:00:01:30:28:a5:3e:bc:24:11:67:20:59
Aug 08 12:08:30 test dhcpcd[104]: eth0: IAID 11:67:20:59
Aug 08 12:08:30 test ifup[104]: eth0: adding address fe80::ed20:e783:3c0b:50d0
Aug 08 12:08:30 test dhcpcd[104]: eth0: adding address fe80::ed20:e783:3c0b:50d0
Aug 08 12:08:31 test ifup[104]: eth0: soliciting a DHCP lease
Aug 08 12:08:31 test dhcpcd[104]: eth0: soliciting a DHCP lease
Aug 08 12:08:32 test ifup[104]: eth0: offered 192.168.34.224 from 192.168.34.1
Aug 08 12:08:32 test dhcpcd[104]: eth0: offered 192.168.34.224 from 192.168.34.1
Aug 08 12:08:32 test ifup[104]: eth0: probing address 192.168.34.224/24
Aug 08 12:08:32 test dhcpcd[104]: eth0: probing address 192.168.34.224/24
Aug 08 12:08:32 test ifup[104]: eth0: soliciting an IPv6 router
Aug 08 12:08:32 test dhcpcd[104]: eth0: soliciting an IPv6 router
Aug 08 12:08:32 test ifup[104]: eth0: Router Advertisement from fe80::20d:b9ff:fe58:a7b9
Aug 08 12:08:32 test dhcpcd[104]: eth0: Router Advertisement from fe80::20d:b9ff:fe58:a7b9
Aug 08 12:08:32 test ifup[104]: eth0: adding address 2a02:xxxx:yyyy:5484:8d27:49b8:bf0b:4202/64
Aug 08 12:08:32 test dhcpcd[104]: eth0: adding address 2a02:xxxx:yyyy:5484:8d27:49b8:bf0b:4202/64
Aug 08 12:08:32 test ifup[104]: eth0: adding address fddf:5ce6:c79:34:63e7:7c40:be6d:790a/64
Aug 08 12:08:32 test ifup[104]: eth0: adding route to 2a02:xxxx:yyyy:5484::/64
Aug 08 12:08:32 test dhcpcd[104]: eth0: adding address fddf:5ce6:c79:34:63e7:7c40:be6d:790a/64
Aug 08 12:08:32 test dhcpcd[104]: eth0: adding route to 2a02:xxxx:yyyy:5484::/64
Aug 08 12:08:32 test ifup[104]: eth0: adding route to fddf:5ce6:c79:34::/64
Aug 08 12:08:32 test ifup[104]: eth0: adding default route via fe80::20d:b9ff:fe58:a7b9
Aug 08 12:08:32 test ifup[104]: eth0: soliciting a DHCPv6 lease
Aug 08 12:08:32 test dhcpcd[104]: eth0: adding route to fddf:5ce6:c79:34::/64
Aug 08 12:08:32 test dhcpcd[104]: eth0: adding default route via fe80::20d:b9ff:fe58:a7b9
Aug 08 12:08:32 test dhcpcd[104]: eth0: soliciting a DHCPv6 lease
Aug 08 12:08:33 test ifup[104]: eth0: ADV 2a02:xxxx:yyyy:5484:ffff:ffff:ffff:fe8f/128 from fe80::20d:b9ff:fe58:a7b9>
Aug 08 12:08:33 test dhcpcd[104]: eth0: ADV 2a02:xxxx:yyyy:5484:ffff:ffff:ffff:fe8f/128 from fe80::20d:b9ff:fe58:a7>
Aug 08 12:08:34 test systemd[1]: Finished networking.service - Raise network interfaces.
Aug 08 12:08:34 test dhcpcd[104]: eth0: REPLY6 received from fe80::20d:b9ff:fe58:a7b9
Aug 08 12:08:34 test dhcpcd[104]: eth0: adding address 2a02:xxxx:yyyy:5484:ffff:ffff:ffff:fe8f/128
Aug 08 12:08:34 test dhcpcd[104]: eth0: renew in 2250, rebind in 3600, expire in 7200 seconds
Aug 08 12:08:37 test dhcpcd[104]: eth0: leased 192.168.34.224 for 7200 seconds
Aug 08 12:08:37 test dhcpcd[104]: eth0: adding route to 192.168.34.0/24
Aug 08 12:08:37 test dhcpcd[104]: eth0: adding default route via 192.168.34.1

/etc/network/interfaces:
Code: 
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

Code: 
ls -l /etc/network/.pve-ignore.interfaces
-rw-r--r-- 1 root root 0 Aug  8 12:08 /etc/network/.pve-ignore.interfaces
 
Last edited:
The workaround with dhcpcd-base seems to be only a 50% solution.
Just tried it out and my IPv6 routing to the Debian 13 LXC container has not been fixed with it.
From within the LXC IPv6 is working properly. But not when using IPv6 to access a service on that LXC.
My PVE is configured as a router. With the Debian 12 LXC’s the routing to them is still working properly.

Edit: The routing got not broken from switching to dhcpcd-base. I Found out that my Wireguard VPN config is making the trouble. So please forget my notice.
 
Last edited:
[solved]
TL:DR turn on datacentre firewall and open access from there.

I tried swapping to dhcpd-base and removing isc-dhcp-client but all that happened is that a temporary 168 address was assigned until the dhcp did succeed eventually, a few minutes later.
I ensured I didn't have firewall rules turned on within the LXC configuration, but that made non difference.
I added rules to accept DHCP traffic in the datacentre firewall rules without turning the firewall on. That made no difference.

After exhausting the possibilities above, and snooping traffic to validate that the LXC network instance and the proxmox host interface were not seeing the DHCP messages that were obviously working fine with other devices on my network I turned on the datacentre firewall, with all traffic permitted (to replicate the behaviour of my intent that the proxmox firewall wasn't part of my security layering) and immediately the DHCP responses worked.
 
Grimwiz said:
[solved]
TL:DR turn on datacentre firewall and open access from there.

I tried swapping to dhcpd-base and removing isc-dhcp-client but all that happened is that a temporary 168 address was assigned until the dhcp did succeed eventually, a few minutes later.
I ensured I didn't have firewall rules turned on within the LXC configuration, but that made non difference.
I added rules to accept DHCP traffic in the datacentre firewall rules without turning the firewall on. That made no difference.

After exhausting the possibilities above, and snooping traffic to validate that the LXC network instance and the proxmox host interface were not seeing the DHCP messages that were obviously working fine with other devices on my network I turned on the datacentre firewall, with all traffic permitted (to replicate the behaviour of my intent that the proxmox firewall wasn't part of my security layering) and immediately the DHCP responses worked.
Click to expand...
DHCPv6 firewall rules is only half. You need to add IPv6 ICMP rules as well. Then the Datacenter Firewall turning on with default block is absolutely no problem.
IPv6 DHCP is still relying on router advertisements.
 
Last edited:
For some reason the LXCs I had upgraded from 12 to 13 work just fine with isc-dhcp-client but when downloading a fresh Debian 13 image for my container it failed until I attempted the fix provided by fabian.

EDIT: Looks like after a day the LXCs upgraded from 12 to 13 started facing the same issues.
 
Last edited:
For me, systemctl status networking shows that it could not start at startup, but then running systemctl start networking is able to start it just fine. A "crude" workaround for those who don't want to really mess with their containers could use a cron @reboot sleep 5 && systemctl start networking.
 
Unspec said:
For me, systemctl status networking shows that it could not start at startup, but then running systemctl start networking is able to start it just fine. A "crude" workaround for those who don't want to really mess with their containers could use a cron @reboot sleep 5 && systemctl start networking.
Click to expand...
Isn't isc-dhcp-client depreceated? I think a better approach would be to move over to dhcpcd-base unless it might break some configs for others.
 
azuriye said:
Isn't isc-dhcp-client depreceated? I think a better approach would be to move over to dhcpcd-base unless it might break some configs for others.
Click to expand...

It is - which is why I'm just putting it out there specifically as a crude fix. I'd rather deal with removing the cron entry later when the issue is fixed compared to removing the hidden ignore interfaces file. Just a personal choice for me.
 
You must log in or register to reply here.
Top Bottom