[SOLVED] LXC hostname refuses to resolve on the network

[Joris L.]

Dear,

For all proxmox VM i simply configure the hostname and the DHCP service maps it to an FQDN so i can ping myhost.sub.sub.mydom.tld

Except for the one container i'm running, that does not work at all, whatever i try. The only difference i notice is the dhcp client here is udhcpc but i've seen this work well in other places before.

The hostname is set in the lxc configuration file and a dhcp lease is obtained from the same dhcp server others hosts obtain one from and do resolve correctly.


Br,

JL

 

[Joris L.]

this was solved by not using udhcpc as the dhcp client, it is unclear how to configure udhcpc to use -F $HOSTNAME to propagate the hostname in the dhcp lease request, using a different dhcp client fixes this terrible issue

 

[openminded]

this was solved by not using udhcpc as the dhcp client, it is unclear how to configure udhcpc to use -F $HOSTNAME to propagate the hostname in the dhcp lease request, using a different dhcp client fixes this terrible issue

hi, can you explain with which client and settings / command ?
Because I get eg:
root@giteact ~# dhcpcd eth1
dhcpcd-9.4.1 starting
DUID 00:04:03:00:02:00:04:00:05:00:00:06:00:07:00:08:00:09
eth1: IAID 11:d4:ca:ae
eth1: soliciting a DHCP lease
eth1: soliciting an IPv6 router
eth1: probing for an IPv4LL address
eth1: using IPv4LL address 169.254.223.96
eth1: adding route to 169.254.0.0/16
eth1: adding default route
forked to background, child pid 7754

So dhcpcd does not work for me either. more details:
https://forum.proxmox.com/threads/vm-do-not-get-ip-from-udhcpd-in-lxc.81933/

 

[openminded]

on the OPNsense side :

2024-10-12T00:12:17

Informational

dhcpd

DHCPOFFER on 192.168.1.165 to bc:24:11:f6:9e:93 via vtnet1

2024-10-12T00:12:17	Informational	dhcpd	DHCPDISCOVER from bc:24:11:f6:9e:93 via vtnet1
2024-10-12T00:12:08	Informational	dhcpd	DHCPOFFER on 192.168.1.165 to bc:24:11:f6:9e:93 via vtnet1
2024-10-12T00:12:08	Informational	dhcpd	DHCPDISCOVER from bc:24:11:f6:9e:93 via vtnet1
2024-10-12T00:12:06	Informational	dhcpd	DHCPOFFER on 192.168.1.165 to bc:24:11:f6:9e:93 via vtnet1
2024-10-12T00:12:05	Informational	dhcpd	DHCPDISCOVER from bc:24:11:f6:9e:93 via vtnet1

 

[Joris L.]

@openminded do you still have a question ? the last post shows leases being offered in response to DHCP discover, so that's fixed?

 

[openminded]

finally found a way.
Indeed a vlan issue it seems.
So this fixed it for me:

https://wiki.debian.org/LXC/VlanNetworking

In my case , snippet from /etc/network/interfaces:
allow-hotplug eth1
auto eth1
iface eth1 inet dhcp

iface eth1.111 inet manual

auto br0.111
iface br0.111 inet manual
bridge_ports eth1.111
bridge_fd 0
bridge_maxwait 0

then dhcpcd eth1 and the route is added and all works.

@openminded do you still have a question ? the last post shows leases being offered in response to DHCP discover, so that's fixed?

hi, it works indeed, but only if I configure it like described here above.
A remaining question I have is if this is the way that is expected to be used? Some explanation on why the container doesn´t work as the VM would be useful too and I guess an explanation in docs. I have seen this being an issue on many posts across the net.

On you note, the DHCP logs were from the DHCP server, but the container never got an address without the VLAN setup inside the container.

 

[Joris L.]

finally found a way.
Indeed a vlan issue it seems.
So this fixed it for me:

https://wiki.debian.org/LXC/VlanNetworking

In my case , snippet from /etc/network/interfaces:
allow-hotplug eth1
auto eth1
iface eth1 inet dhcp

iface eth1.111 inet manual

auto br0.111
iface br0.111 inet manual
bridge_ports eth1.111
bridge_fd 0
bridge_maxwait 0

then dhcpcd eth1 and the route is added and all works.

hi, it works indeed, but only if I configure it like described here above.
A remaining question I have is if this is the way that is expected to be used? Some explanation on why the container doesn´t work as the VM would be useful too and I guess an explanation in docs. I have seen this being an issue on many posts across the net.

On you note, the DHCP logs were from the DHCP server, but the container never got an address without the VLAN setup inside the container.

the VLAN set-up would only be required if the bridge had been made VLAN aware and had VLAN assigned to it
it may be the vlan is assigned to the external interface and thus has to 'stretched' onto the bridge