[pve-devel] [PATCH pve-network] dnsmasq: configure static range for each subnet

[Stefan Lendl]

"DERUMIER, Alexandre" <alexandre.derumier at groupe-cyllene.com> writes:

>
> I can reproduce easily 100%:
>
>
> - create a nic with mac:xx:xx:xx:xY  ip: 192.168.0.10
> - start vm. (the ether file is filed + reload)
> - the guest do a dhcp request, the dnsmasq respond  a store the lease
> in /var/lib/misc/zone.lease
>
> - delete the nic
>
>
> - add a new nic in same vm or another vm,  free found ip is
> 192.168.0.10  (because it was removed)
>
>
> - start the vm (the ether file is upgrade with the new ip mac + reload)
>
> - the guest do a dhcp request: the dnsmasq can't respond (with my last
> patch) or give a dynamic ip in the range (with current implementation)
> because it's still see his lease file the old mac:ip assocation
>

I experimented with several approaches with dnsmasq leases.
I cannot reproduce your example because it works in my examples.
My procedure:

dnsmasq config:
dhcp-range=set:DHCPNAT-10.1.0.0-16,10.1.0.0,static,255.255.0.0,infinite

VM 108 net1: MAC: bc:24:11:ad:0e:2e

qm set 108 --delete net1

dnsmasq lease file still contains the lease for MAC bc:24:11:ad:0e:2e

qm set 108 --net1 model=virtio,bridge=dhcpnat

- ethers file gets updated to new mac: BC:24:11:51:10:AD
- soon after dnsmasq lease gets updated to the new lease as well!
- correct IP assigned in the VM

I also tried:
- ip link set down > ip link set upi
- reboot
- force Stop the VM

So far, *this all works!*


I also tried with a short dhcp lease in dnsmasq. With this
configuration, the new IP will even propagate to the VM and set
correctly after IPAM update.

In my tests I used 30s but something like 5 or 10min should be fine as well.

dhcp-range=set:DHCPNAT-10.1.0.0-16,10.1.0.0,static,255.255.0.0,30

The VM is polling every ~60s as seen on the wire with tcpdump:

tcpdump -i dhcpnat -n port 67 or port 68

After I manually update the ethers file and `systemctl *reload*
dnsmasq`, it will respond with the new IP.

dnsmasq is running *locally only* so any DHCP queries are limited to the
local bridge.

The biggest problem and for me the reason I think it's not a feasible
solution, is that dnsmasq becomes a single point of failure.
If dnsmasq is offline, all of the VMs will have *NO IP*.