[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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


Dr. Martin Wilck <mwilck suse com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]