10:58 a.m.
"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.
Fixes: 4ac20b3ae "network: add dnsmasq option 'dhcp-authoritative'"
Signed-off-by: Martin Wilck <mwilck(a)suse.com>
---
src/network/bridge_driver.c | 9 ++++++++-
tests/networkxml2confdata/dhcp6host-routed-network.conf | 1 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index ae1589d8c..17c6f3a0f 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -1355,7 +1355,14 @@ networkDnsmasqConfContents(virNetworkObjPtr network,
if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET)) {
if (ipdef->nranges || ipdef->nhosts) {
virBufferAddLit(&configbuf, "dhcp-no-override\n");
- virBufferAddLit(&configbuf, "dhcp-authoritative\n");
+ /*
+ * Use "dhcp-authoritative" only for dynamic DHCP.
+ * In a static-only network, it would cause dnsmasq
+ * to reply to requests from other hosts than those
+ * statically defined.
+ */
+ if (ipdef->nranges || !ipdef->nhosts)
+ virBufferAddLit(&configbuf, "dhcp-authoritative\n");
}
if (ipdef->tftproot) {
diff --git a/tests/networkxml2confdata/dhcp6host-routed-network.conf
b/tests/networkxml2confdata/dhcp6host-routed-network.conf
index 87a149880..5728ee430 100644
--- a/tests/networkxml2confdata/dhcp6host-routed-network.conf
+++ b/tests/networkxml2confdata/dhcp6host-routed-network.conf
@@ -10,7 +10,6 @@ bind-dynamic
interface=virbr1
dhcp-range=192.168.122.1,static
dhcp-no-override
-dhcp-authoritative
dhcp-range=2001:db8:ac10:fd01::1,static,64
dhcp-hostsfile=/var/lib/libvirt/dnsmasq/local.hostsfile
addn-hosts=/var/lib/libvirt/dnsmasq/local.addnhosts
--
2.11.0
7:37 p.m.
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.
Fixes: 4ac20b3ae "network: add dnsmasq option 'dhcp-authoritative'"
Signed-off-by: Martin Wilck <mwilck(a)suse.com>
---
src/network/bridge_driver.c | 9 ++++++++-
tests/networkxml2confdata/dhcp6host-routed-network.conf | 1 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index ae1589d8c..17c6f3a0f 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -1355,7 +1355,14 @@ networkDnsmasqConfContents(virNetworkObjPtr network,
if (VIR_SOCKET_ADDR_IS_FAMILY(&ipdef->address, AF_INET)) {
if (ipdef->nranges || ipdef->nhosts) {
virBufferAddLit(&configbuf, "dhcp-no-override\n");
- virBufferAddLit(&configbuf, "dhcp-authoritative\n");
+ /*
+ * Use "dhcp-authoritative" only for dynamic DHCP.
+ * In a static-only network, it would cause dnsmasq
+ * to reply to requests from other hosts than those
+ * statically defined.
+ */
+ if (ipdef->nranges || !ipdef->nhosts)
+ virBufferAddLit(&configbuf, "dhcp-authoritative\n");
}
if (ipdef->tftproot) {
diff --git a/tests/networkxml2confdata/dhcp6host-routed-network.conf
b/tests/networkxml2confdata/dhcp6host-routed-network.conf
index 87a149880..5728ee430 100644
--- a/tests/networkxml2confdata/dhcp6host-routed-network.conf
+++ b/tests/networkxml2confdata/dhcp6host-routed-network.conf
@@ -10,7 +10,6 @@ bind-dynamic
interface=virbr1
dhcp-range=192.168.122.1,static
dhcp-no-override
-dhcp-authoritative
dhcp-range=2001:db8:ac10:fd01::1,static,64
dhcp-hostsfile=/var/lib/libvirt/dnsmasq/local.hostsfile
addn-hosts=/var/lib/libvirt/dnsmasq/local.addnhosts
7:40 a.m.
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 can't answer this for certain at the moment. I got a report from our
cloud people and this patch fixed their configuration; I haven't seen
it in my own environment.
Wrt 2), I'd bet that the same thing will happen with a DHCP range
defined. But would that be wrong? If dnsmasq is allowed to take IP
addresses from a dynamic range, why shouldn't it do so (*)? Several
DHCP servers in the same subnet are a strange configuration anyway. In
the case of the "static" network it makes a certain amount of sense (in
our case, the libvirt DHCP server was only used to serve the IP of a
single static host, which was then used as DHCP server for all other
hosts on the network), but if a "dynamic" dhcp service already exists,
adding another one looks like begging for trouble to me.
I can try to figure stuff out in more detail, but it'll take some time.
Regards,
Martin
(*) I can see a corner case: when libvirt dnsmasq's dynamic range was
depleted. Should it be allowed to respond to queries in that case?
Sorry, I don't know.
--
Dr. Martin Wilck <mwilck(a)suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
9:32 a.m.
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(a)suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
6:34 a.m.
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(a)suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
4:23 p.m.
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(a)suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
2816
days inactive
2897
days old
5 comments
2 participants
participants (2)
-
Laine Stump -
Martin Wilck