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

[Martin Wilck]

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