[libvirt] [PATCH] network: don't use dhcp-authoritative on static networks

[Martin Wilck]

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 at suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)