Re: [libvirt] [PATCH] network: Add support for configuring dhcp lease time

On Sat, Sep 24, 2016 at 3:01 AM, Laine Stump <laine(a)laine.org&gt; wrote: > On 09/23/2016 02:43 PM, Martin Wilck wrote: >> On Fri, 2016-09-23 at 11:56 -0400, Laine Stump wrote: >> >>> Martin's patch tries to solve the problem with "dhcp-authoritative" >>> which, as far as I understand, tells dnsmasq "you are the keeper of >>> *all* lease information on this network, so if you think the address >>> is >>> unused, it really is unused"; dnsmasq uses this information to >>> freely >>> grant a guest any address it asks for, as long as there is no >>> current >>> lease for it. This sounds troublesome to me - If client A's lease >>> has >>> expired (because it's turned off for a bit), is it okay for client B >>> to >>> come barging in and insist on grabbing the address that client A has >>> just lost even though there are many other addresses still >>> available? >>> Sure, technically it's legal, but it seems unnecessarily disruptive. >> I am not sure what you mean. What scenario would be "disrupted" by this >> approach? > > Disruptive may not have been the best word. What I mean is that an > unfriendly guest with proper information could take advantage of this "give > any currently-unused address to anyone who asks for it" policy by > purposefully taking over an IP address that it knew had previously been > leased to a different guest (and who was expecting on getting the address > back the next time it booted). Of course 1) it would take a lot of inside > knowledge / good timing / luck to make this happen, and 2) you can argue > that any guest who relied on a dhcp address remaining unchanged deserves > what it gets (and the same for any other machine trying to contact that > guest via the IP address). > >> Without dhcp_authoritative, client A will not get its lease back, > > Is that true even if dnsmasq isn't restarted, and even if leasefile-ro isn't > used? The Openstack discussion on this topic implies that the behavior only > exists because they aren't saving a leasefile, not just because the lease is > expired. > >> whether or not B applied for it in the meantime, and B wouldn't get the >> lease, either. The user wouldn't be able to ping either one. If >> dhcp_authoritative is used, at least one of them will get what it needs >> (and serving both is impossible - it's hard to tell what's the Right >> Thing in the situation you describe!). > > Well, I guess it's a policy decision, but I would tend toward *not* allowing > B to demand a particular IP address that it has never before been given. > >> Anyway, unless the virtual network is really crowded (in which case it >> might make sense for the admin to use a class B network instead) the >> probability of such clashes should be rather minimal in the real world. >> It's much more likely that A itself tries to reacquire the lease, and >> that situation is fixed by dhcp_authoritative. > > > Yeah, as long as the guests are all friendly. My concern is with unfriendly > guests. > > >>> I think the *real* solution is to fix the lease handling so that >>> dnsmasq >>> remembers leases after they've expired (assuming that can be done >>> once >>> leasefile-ro is set). They would be marked as "expired", and >>> probably >>> not even reported externally, but all their info would still be >>> there >>> internally for dnsmasq's use when considering what to do with >>> incoming >>> requests for specific IP addresses. >> Is that possible at all with the current leasehelper setup? > > "maybe"? See Nehal's recent email - we weren't notifying dnsmasq of expired > leases, and that could be the source of the problem (or not, I didn't > understand if he's verified whether doing so actually causes dnsmasq to > accept the requests for expired addresses). If that works, then the problem > is solved. If not, then we may need to consider using dhcp-authoritative. > I did a small test. I compiled the SHA b55c064f of libvirt with a small modification. I enforced the lease time to be 2mins. Then I spawned a VM, and did the following: $ sudo journalctl -f | grep dnsmasq-dhcp Sep 24 19:31:13 lenovo dnsmasq-dhcp[9093]: DHCPDISCOVER(virbr1) 52:54:00:12:34:56 Sep 24 19:31:13 lenovo dnsmasq-dhcp[9093]: DHCPOFFER(virbr1) 192.168.123.76 52:54:00:12:34:56 Sep 24 19:31:13 lenovo dnsmasq-dhcp[9093]: DHCPREQUEST(virbr1) 192.168.123.76 52:54:00:12:34:56 Sep 24 19:31:13 lenovo dnsmasq-dhcp[9093]: DHCPACK(virbr1) 192.168.123.76 52:54:00:12:34:56 --- Now I pause the VM by sending 'stop' on the qemu monitor and wait. --- As soon as lease expires, I go back to the qemu monitor and un-pause the VM by sending 'cont' on the qemu monitor. Sep 24 19:34:06 lenovo dnsmasq-dhcp[9093]: DHCPREQUEST(virbr1) 192.168.123.76 52:54:00:12:34:56 Sep 24 19:34:06 lenovo dnsmasq-dhcp[9093]: DHCPNAK(virbr1) 192.168.123.76 52:54:00:12:34:56 lease not found --- I haven't restarted dnsmasq in between, so clearly, it knows about the expired lease. But it still sends a DHCPNAK. Sep 24 19:34:22 lenovo dnsmasq-dhcp[9093]: DHCPDISCOVER(virbr1) 192.168.123.76 52:54:00:12:34:56 Sep 24 19:34:22 lenovo dnsmasq-dhcp[9093]: DHCPOFFER(virbr1) 192.168.123.76 52:54:00:12:34:56 Sep 24 19:34:22 lenovo dnsmasq-dhcp[9093]: DHCPREQUEST(virbr1) 192.168.123.76 52:54:00:12:34:56 Sep 24 19:34:22 lenovo dnsmasq-dhcp[9093]: DHCPACK(virbr1) 192.168.123.76 52:54:00:12:34:56 --- And the VM has to send a DHCPDISCOVER again :'(

Inside the VM, the version of dhclient used by the Network Manager was: isc-dhclient-4.3.3-P1 Gentoo-r0 So this begs the question. Does dnsmasq really do anything about the expired lease? Or does it simply forget about it no matter what?