On Sun, 2016-12-18 at 20:37 -0500, Laine Stump wrote: > > > On 12/16/2016 11:58 AM, Martin Wilck wrote: > > "Static" DHCP networks are those where no dynamic DHCP range is > > defined, only a list of host entries is used to serve permanent > > IP addresses. On such networks, we don't want dnsmasq to reply > > to other requests than those statically defined. But > > "dhcp-authoritative" will cause dnsmasq to do just that. > > Therefore we can't use "dhcp-authoritative" for static networks. > > Not surprising that this simple change would have unexpected > consequences - that seems to be a basic law of the universe :-) > > ACK to this, but it has me wondering 1) what is the range for which > it > returns a positive response? Is it for anything within the IP > address/netmask of the interface it's listening on? Or something > larger > than that? (Does it just blindly ACK any request it gets?) and 2) Do > we > know for certain that the same thing doesn't happen when there is > also a > dhcp range defined? > > I'll wait for an answer to these before I push. > Here is a summary of how dnsmasq behaves: A) without "dhcp-authoritative", it only responds to DHCPREQUEST messages after a preceding DHCPDISCOVER/DHCPOFFER, or if a non-expired lease for the requesting MAC address is found. This holds also for clients with static host entries. B) with "dhcp-authoritative", dnsmasq always replies to DHCPREQUEST messages. It will send DHCPNAK if the lease is currently taken by a different MAC address (either via a static entry or via a non-expired lease), and DHCPACK otherwise. Independent of dhcp-authoritative, dnsmasq responds to DHCPDISCOVER if and only if it has addresses to hand out, thus either the MAC address of the client matches a static entry or there are free addresses in the dynamic pool. I can see no difference between a "static" configuration and a configuration with zero-length or exhausted dynamic pool. In case A), every attempt to re-obtain a previous IP address is delayed because the client needs to wait for several DHCPREQUEST messages to time out before it sends a new DHCPDISCOVER. In case B) it will receive either ACK or NAK immediately. This seems to be an advantage of "dhcp- authoritative". So the answer to 1)/2) above is "positive response only in the defined dynamic dhcp range". If there's no dynamic range, no positive responses will be sent to unkown clients. *But* in authoritative mode it will send DHCPNAKs, which may confuse clients. If there's another DHCP server on the virtual network, properly configured (no overlap between dynamic ranges), and the client sends a DHCPREQUEST, it may get an DHCPNAK from the libvirt dnsmasq and DHCPACK from the other DHCP server. What then happens is probably dependent on timing (which response is received first). RFC2131 is not clear about this scenario, AFAICS. Sooo, if customers run DHCP servers in VMs concurrently with the libvirt DHCP server, problems may arise with "dhcp-authoritative". My "don't use dhcp-authoritative on static networks" patch fixes this for cases where the libvirt network is "static", but problems may remain for cases with non-overlapping dynamic DHCP ranges. It's not an easy question whether or not this outweighs the benefits of using "dhcp- authoritative". Of course I'd hate to have my previous patch introducing "dhcp-authoritative" reverted :-) Maybe we need yet another config option for the network XML. I'm unsure whether this should be an attribute of the "<network>, <ip>, or <dhcp> element, or something else. There is a relationship to the "localOnly" attribute of "<domain>", but I think the two should still be independent settings. Anyway, I'll wait what you're saying. Regards, Martin -- Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
