[libvirt] [PATCH] network: don't use dhcp-authoritative on static networks
"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@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
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@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
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@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
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@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
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@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
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@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
participants (2)
-
Laine Stump -
Martin Wilck