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? 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
