0

I'm using Debian Bullseye to run KVM (Kernel-based Virtual Machine) with two guests vdeb02-10-base and vdeb03-10-base. Both guests have Debian Buster installed. For testing purposes vdeb03-10-base is just a clone of vdeb02-10-base, using the virt-clone utility to ensure that is has unique system parameter like mac address etc. On all devices (host, guests) I use systemd-networkd.

If I start vdeb02-10-base with DHCP enabled to get an ip address from my ISC-DHCP-Server everything works fine as shown by the log of the DHCP-Server:

Oct 05 18:43:49 vnetsvr30-10 dhcpd[1534]: DHCPDISCOVER from 52:54:00:ee:f5:0a via ens1
Oct 05 18:43:50 vnetsvr30-10 dhcpd[1534]: DHCPOFFER on 192.168.30.104 to 52:54:00:ee:f5:0a (vdeb02-10-base) via ens1
Oct 05 18:43:50 vnetsvr30-10 dhcpd[1534]: DHCPREQUEST for 192.168.30.104 (192.168.30.10) from 52:54:00:ee:f5:0a (vdeb02-10-base) via ens1
Oct 05 18:43:50 vnetsvr30-10 dhcpd[1534]: Wrote 56 leases to leases file.
Oct 05 18:43:50 vnetsvr30-10 dhcpd[1534]: DHCPACK on 192.168.30.104 to 52:54:00:ee:f5:0a (vdeb02-10-base) via ens1
Oct 05 18:43:50 vnetsvr30-10 dhcpd[1534]: Added new forward map from vdeb02-10-base.home.hoeft-online.de. to 192.168.30.104
Oct 05 18:43:50 vnetsvr30-10 dhcpd[1534]: Added reverse map from 104.30.168.192.in-addr.arpa. to vdeb02-10-base.home.hoeft-online.de.

The dynamic DNS name is mapped to the DNS server so I can query for it with

~$ dig +search +noall +answer vdeb02-10-base
vdeb02-10-base.home.hoeft-online.de. 3600 IN A  192.168.30.104

If I start then vdeb03-10-base the DHCP-Server log shows me this:

Oct 05 18:44:55 vnetsvr30-10 dhcpd[1534]: DHCPDISCOVER from 52:54:00:ed:c5:df (vdeb02-10-base) via ens1
Oct 05 18:44:55 vnetsvr30-10 dhcpd[1534]: ICMP Echo reply while lease 192.168.30.104 valid.
Oct 05 18:44:55 vnetsvr30-10 dhcpd[1534]: Abandoning IP address 192.168.30.104: pinged before offer
Oct 05 18:44:55 vnetsvr30-10 dhcpd[1534]: Removed forward map from vdeb02-10-base.home.hoeft-online.de. to 192.168.30.104
Oct 05 18:44:55 vnetsvr30-10 dhcpd[1534]: Removed reverse map on 104.30.168.192.in-addr.arpa.
Oct 05 18:44:57 vnetsvr30-10 dhcpd[1534]: DHCPDISCOVER from 52:54:00:ed:c5:df via ens1
Oct 05 18:44:58 vnetsvr30-10 dhcpd[1534]: DHCPOFFER on 192.168.30.95 to 52:54:00:ed:c5:df (vdeb03-10-base) via ens1
Oct 05 18:44:58 vnetsvr30-10 dhcpd[1534]: DHCPREQUEST for 192.168.30.95 (192.168.30.10) from 52:54:00:ed:c5:df (vdeb03-10-base) via ens1
Oct 05 18:44:58 vnetsvr30-10 dhcpd[1534]: DHCPACK on 192.168.30.95 to 52:54:00:ed:c5:df (vdeb03-10-base) via ens1
Oct 05 18:44:58 vnetsvr30-10 dhcpd[1534]: Added new forward map from vdeb03-10-base.home.hoeft-online.de. to 192.168.30.95
Oct 05 18:44:58 vnetsvr30-10 dhcpd[1534]: Added reverse map from 95.30.168.192.in-addr.arpa. to vdeb03-10-base.home.hoeft-online.de.

Why does the DHCP-Server mean that the DHCPDISCOVER comes from vdeb02-10-base and not from vdeb03-10-base? Mac address and hostname are different. Of course the DHCP-Server then means there is an ip address conflict on the network using the ping test. Then it removes the DNS mapping for vdeb02-10-base and replaces it with the mapping for vdeb03-10-base with the result that I cannot resolve the name for vdeb02-10-base anymore.

What's going on here? Why does the DHCP-Server replaces the hostname on the DNS-Server instead of just adding the name of the second guest? Where could be the problem? At the guests, or at the host with a standard network bridge for the guests, or at the DHCP-Server, or by using systemd-networkd? Maybe there is an option to be used in /etc/dhcp/dhcpd.conf?

0

From the logs of the DHCP-Server it seems that it cannot distinguish between the two different devices although they have different names and mac addresses. Obviously this isn't used to identify the devices on the network. Because vdeb03-10-base is a clone of vdeb02-10-base there must be a different identification that hasn't changed after cloning (name and mac address are changed).

Looking at man systemd.network what this could be I found the option ClientIdentifier= that can be set to "mac" or "duid". If setting this to mac both device names are dynamically correct mapped to the DNS-Server but it doesn't solve the source of the problem. There must be a DUID that is still equal on both devices and may cause other problems.

I found that the DUID for DHCP can be set in /etc/systemd/networkd.conf but the next question is how to calculate it? In man networkd.conf I found:

If "DUIDType=vendor", then the DUID value will be generated using "43793" as the vendor identifier (systemd) and hashed contents of machine-id(5). This is the default if DUIDType= is not specified.

So the source of the problem is that the machine-id is the same on both guests.

But there are some trouble to change it. How to do it I found at: Is it OK to change /etc/machine-id?. In short you have to do:

~$ sudo rm -f /etc/machine-id
~$ sudo dbus-uuidgen --ensure=/etc/machine-id
~$ sudo rm /var/lib/dbus/machine-id
~$ sudo dbus-uuidgen --ensure

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.