Reviewed: https://review.opendev.org/725369 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f951871430ba59a148b8cb88e0d1b9e517c0a52e Submitter: Zuul Branch: master
commit f951871430ba59a148b8cb88e0d1b9e517c0a52e Author: Harald Jensås <[email protected]> Date: Mon May 4 20:01:35 2020 +0200 Use dhcp-host tag support when supported In dnsmasq 2.81 there is a regression (see [1] for details). Prior versions of dnsmasq would select a host record where: a) no address is present in the host record. b) an address matching address family of the client request is present in the host record. dnsmasq 2.81 will also use a host record where a only an address not matching the address family of the client request is present. The same issue is also backported to the dnsmasq-2.79-11.el8.x86_64 which is e.g. in RHEL 8.2 and Centos 8. dnsmasq version 2.81 also adds support for using tag's on host records. When a dhcpv6 request is received, dnsmasq automatically sets the tag 'dhcpv6'. This change adds a runtime check, testing for dnsmasq host entry tag support. And adds 'tag:dhcpv6' to all IPv6 host records when dnsmasq supports this. Adding the tag makes dnsmasq prefer the tagged host for dhcpv6 requests, i.e it's a workaround fix for the regression issue. [1] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q2/014051.html Closes-Bug: #1876094 Change-Id: Ie654c84137914226bdc3e31e16219345c2efaac9 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1876094 Title: Dnsmasq 2.81 broke neutron's DHCP service Status in neutron: Fix Released Bug description: With dnsmasq 2.81 DHCP for instances connected to network with both IPv4 and IPv6 dhcp-stateful networks will not work as it should. Dnsmasq is processing "host" file's entries from the bottom to the top and as neutron always places first IPv4 and then IPv6 addresses for same MAC, DHCP for IPv4 will not work now. Details are in Harald's email: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q2/014038.html Basically it's not Neutron's fault but regression in dnsmasq, but we can workaround it by changing how we generate host file. If it will be one line per mac address, like: fa:16:3e:b2:5f:a2,host-10-0-0-72.openstacklocal,[fd05:321f:2d56:1::b5] fa:16:3e:08:f4:1f,host-10-0-0-2.openstacklocal,10.0.0.2,[fd05:321f:2d56:1::2] fa:16:3e:9d:76:87,host-10-0-0-31.openstacklocal,10.0.0.31,[fd05:321f:2d56:1::8] fa:16:3e:9f:f9:a5,host-10-0-0-60.openstacklocal,10.0.0.60,[fd05:321f:2d56:1::30a] fa:16:3e:8c:47:e5,host-10-0-0-1.openstacklocal,10.0.0.1 then it should works fine in both dnsmasq 2.81 and older versions. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1876094/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
