IPAM Reserving DHCP leases via MAC addresses

[pgiav]

I am using the default PVE IPAM plugin with DHCP. I have one zone with a couple of VNets defined, each with separate subnets and certain reserved IPs:



For the sake of this post, assume these are all VMs that are configured with DHCP, so they ask for a lease and normally get those static IPs. However, what I have done now is turned those VMs into templates. When I then clone said templates into VMs again (Linked Clones in this case), and set the **same** MAC address in their assigned NIC, they still end up getting different IPs than those defined above. More bizarrely, the same MAC address shows up twice. Here is what happens when I clone the VM that previously had 172.19.0.5, with MAC address BC:24:11:CE:9A:29:




As you can see, VM 122 is cloned, gets the IP 172.19.0.235 (automatically), despite having the same MAC address as the existing entry. How come IPAM doesn't _think_ that this VM is the same device that ought to get the defined lease? It seems to me that more than the MAC address must be used to distinguish between VMs, then. Is there a workaround for this?

Interestingly, if I delete the new entry (.235) and boot the VM, it gets the intended IP address of .5. So I wonder why it gets a separate IPAM entry in the first place.


I've scoured this forum and haven't found an answer to this, so any help is greatly appreciated.

Edit: I am actually surprised to see that there are no checks in the IPAM module for whether a duplicate MAC address is being added. I see a check for an existing IP, but nothing regarding MAC addresses. Is this intentional?

 

[bl1mp]

Hi pgiav,

some operating systems do not (only) use the Macaddress to register for DHCP-Addresses. (https://askubuntu.com/questions/149...ad-of-mac-addresses-cant-change-this-behavior)

Maybe this information helps you to determ the behaviour.

BR, Lucas

 

[pgiav]

Thanks Lucas.

I don't think this is an OS-level problem, though. The crux of the matter is that when I delete the "new" lease (.235 in the above example) and boot the VM, it gets the correct lease (.5). Given the lack of MAC validation in the IPAM module code, this seems like a bug to me to allow a machine with a MAC address that is already defined in IPAM to get a new/different lease.