On Sun, Sep 25, 2016 at 12:58 AM, Laine Stump <laine@xxxxxxxxx> wrote:
> On 09/24/2016 10:51 AM, Nehal J Wani wrote:
>>
>> On Sat, Sep 24, 2016 at 3:01 AM, Laine Stump <laine@xxxxxxxxx> 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 :'(
>
>
>
> But when it does, it again gets the address it previously had, rather than
> some different address.
>
In the previous test, there was only one VM in that network at all time.
>
>>
>> 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?
>
>
> Well it least *appears* that dnsmasq ended up giving out the same IP address
> once the client sent a DHCPDISCOVER. We should find out if that's a happy
> accident, or it it happens on purpose. (in other words, does dnsmasq try to
> *not* give out addresses that were previously in use but now expired unless
> the original owner comes back (or all the other addresses are in use), or
> was this just coincidental because nobody else had requested an address in
> the meantime?)
I did another experiment. My network xml limited the range to:
<ip address='192.168.123.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.123.2' end='192.168.123.6'/>
</dhcp>
</ip>
So, we can safely assume that, if, at any given point of time, there
are two virtual machines with different mac addresses, connected to
this network, they should have been leased different IP addresses.
VM1 is spawned with -net nic,macaddr=52:54:00:69:09:b6 -net bridge,br=virbr1
VM1 is assigned 192.168.123.4 with lease time of 2 mins.
Sep 27 08:53:32 lenovo dnsmasq-dhcp[12156]: DHCPDISCOVER(virbr1)
52:54:00:69:09:b6
Sep 27 08:53:32 lenovo dnsmasq-dhcp[12156]: DHCPOFFER(virbr1)
192.168.123.4 52:54:00:69:09:b6
Sep 27 08:53:32 lenovo dnsmasq-dhcp[12156]: DHCPREQUEST(virbr1)
192.168.123.4 52:54:00:69:09:b6
Sep 27 08:53:32 lenovo dnsmasq-dhcp[12156]: DHCPACK(virbr1)
192.168.123.4 52:54:00:69:09:b6
VM1 is paused.
VM1's lease expires.
VM2 is spawned with -net nic,macaddr=52:54:00:69:09:b1 -net bridge,br=virbr1
VM2 is assigned 192.168.123.4 with lease time of 2 mins. :-'(
Sep 27 08:56:04 lenovo dnsmasq-dhcp[12156]: DHCPDISCOVER(virbr1)
52:54:00:69:09:b1
Sep 27 08:56:04 lenovo dnsmasq-dhcp[12156]: DHCPOFFER(virbr1)
192.168.123.4 52:54:00:69:09:b1
Sep 27 08:56:04 lenovo dnsmasq-dhcp[12156]: DHCPREQUEST(virbr1)
192.168.123.4 52:54:00:69:09:b1
Sep 27 08:56:04 lenovo dnsmasq-dhcp[12156]: DHCPACK(virbr1)
192.168.123.4 52:54:00:69:09:b1
Seems like the previous experiment involved a happy accident indeed.
--
Nehal J Wani
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list