[openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers

Ihar Hrachyshka ihrachys at redhat.com
Tue May 26 13:57:27 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/26/2015 04:35 AM, Kevin Benton wrote:
> Hi,
> 
> A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has
> caused DHCPNAK messages when multiple agents are scheduled to a
> network [2].
> 
> This was back-ported to Icehouse and Juno so we need a fix that is 
> compatible with both of them.
> 
> I have two fixes for this so far and a third alternative if we
> don't like those.
> 
> The first is hacky, but it's only a few-line change.[3] It adds an 
> iptables rule that just stops the DHCPNAKs from making it to the
> client. This is clean to back-port but it doesn't protect clients
> that have filtering disabled (e.g. bare metal).
> 
> The second persists the DHCP leases to a database.[4] The downside
> to this was always that being rescheduled to another agent would
> mean no entries in the lease file. This approach adds a work-around
> to generate an initial fake lease file based on all of the ports in
> the network.
> 
> A third approach that I don't have a patch pushed for yet is very 
> similar to the second. When dnsmasq is in the leasefile-ro mode, it
> will call the script passed to --dhcp-script to get a list of
> leases to start with. This script would be built with the same
> logic as the second one. The only difference between the second
> approach is that dnsmasq wouldn't persist leases to a database.
> 

Actually, that approach was initially taken for bug 1345947, but then
the patch was abandoned to be replaced with a simpler
- --dhcp-authoritative approach that ended up with unexpected NAKs for
multi agent setup.

See: https://review.openstack.org/#/c/108272/12

Maybe we actually want to restore the work and merge it after
conflicts are resolved and --dhcp-authoritative option is killed; the
patch was almost merged when --dhcp-authoritative suggestion emerged,
so most of nitpicking work should be complete now (though at the same
time, I totally trust our community to find another pile of nits to
work on for the next few weeks!)

===

Speaking of regression testing... Are full stack tests already
powerful enough for us to invoke multiple DHCP agents and test the
scenario?

Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVZHvHAAoJEC5aWaUY1u57vukIAJLPpQ9O236NYtOaRTzkL7g8
Io1DmF6jyhJYFqfzoFcrFVbNmM0EsNtvMgZIhI8oYINkkoBYMJPoS2a8FvVUpZHw
u/fmdvdbZgJwy4BCAEF0t+R1t1XLo6eTcPp8f3jABzExWyrLoKEbHJ0aWb5xwJ3u
V74HXxo/PVifrNfxsQPn57ZxqgBvl4GSQAFQKE4FX/H81HWRWRuB5a9aC+hkYC9w
7FqXpf+IFCaS7tYdTSqJUa2/bKs268RQGoVqAYEtmVV5pA3OiMsy459rdLcHqqxS
67lryFh1DTMwI77LjDEanXzWIdMhb3t0YZw7ewpBBLl6P/Lh7xobIOGX2GeOyJ0=
=xivW
-----END PGP SIGNATURE-----



More information about the OpenStack-dev mailing list