From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 4B4A1997CF for ; Thu, 16 Nov 2023 13:53:47 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 302EF1376A for ; Thu, 16 Nov 2023 13:53:47 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 16 Nov 2023 13:53:46 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 167A94386C; Thu, 16 Nov 2023 13:53:46 +0100 (CET) From: Stefan Lendl To: "DERUMIER, Alexandre" Cc: "pve-devel@lists.proxmox.com" In-Reply-To: <224f6b39b0d45e386dd32b1881169c17a89b2917.camel@groupe-cyllene.com> References: <20231115151350.596552-1-aderumier@odiso.com> <509c039d71f3c4c5edf8ebd24529b0d12af74434.camel@groupe-cyllene.com> <87il632clh.fsf@gmail.com> <224f6b39b0d45e386dd32b1881169c17a89b2917.camel@groupe-cyllene.com> Date: Thu, 16 Nov 2023 13:53:45 +0100 Message-ID: <87bkbt3lly.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-SPAM-LEVEL: Spam detection results: 0 AWL 0.073 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH pve-network] dnsmasq: configure static range for each subnet X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2023 12:53:47 -0000 "DERUMIER, Alexandre" 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*.