Laine, Daniel, On Mon, 2017-02-13 at 13:34 +0100, Martin Wilck wrote: > Laine, Daniel, > > On Thu, 2017-01-05 at 16:32 +0100, Martin Wilck wrote: > > 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. > > have you made up your mind about this? may I ask again how to proceed? 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
