[SOLVED] LXC Netmask strangeness

jlar310

Renowned Member
Jun 27, 2007
36
0
71
In the container config file I have

net0: name=eth0,bridge=vmbr0,firewall=0,gw=192.168.99.1,hwaddr=56:C9:75:FB:4E:8F,ip=192.168.99.40/24,type=veth

But in the container, I get

root@pihole:~# ip addr show dev eth0
43: eth0@if44: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 56:c9:75:fb:4e:8f brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.99.40/32 brd 192.168.99.40 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::54c9:75ff:fefb:4e8f/64 scope link
valid_lft forever preferred_lft forever

Note the resulting /32 netmask despite the configured /24. So the host can reach the gateway, and the Internet, but can not communicate on the LAN

Proxmox VE 6.1-5
 
This is getting more strange. I reconfigured the container to use DHCP just to see what would happen. Now it shows the DHCP assigned address and still shows the static 192.168.99.40/32

root@proxmox$ pct config 140
arch: amd64
cores: 1
hostname: pihole
memory: 512
net0: name=eth0,bridge=vmbr0,hwaddr=56:C9:75:FB:4E:8F,ip=dhcp,type=veth
onboot: 1
ostype: ubuntu
rootfs: local:140/vm-140-disk-0.raw,size=8G
swap: 512

root@pihole:~# ip addr show dev eth0
45: eth0@if46: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 56:c9:75:fb:4e:8f brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.99.178/24 brd 192.168.99.255 scope global dynamic eth0
valid_lft 86202sec preferred_lft 86202sec
inet 192.168.99.40/32 brd 192.168.99.40 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::54c9:75ff:fefb:4e8f/64 scope link
valid_lft forever preferred_lft forever

Somewhere that ip configuration is "stuck". But is it in the guest or the host? What other config files are there? In the guest we have this in /etc/systemd/network/eth0.network:

root@pihole:/etc/systemd/network# cat eth0.network
[Match]
Name = eth0

[Network]
Description = Interface eth0 autoconfigured by PVE
DHCP = v4
IPv6AcceptRA = false


So where else could this be coming from?
 
SOLVED: I discovered that there was a dhcpcd5 package installed inside the container in addition to the standard isc-dhcp-client and isc-dhcp-common. After removing dhcpcd5, everything started to behave as expected.