Open Stack

Hi Salvatore,

The problem isn't that dnsmasq doesn't have an entry for the client. The
issue is that the client is sending to a server address that is not
dnsmasq. This is the logic that is causing the issue.[1]


1. https://github.com/kevinbenton/dnsmasq/blob/master/src/rfc2131.c#L1103

On Tue, May 26, 2015 at 10:12 AM, Salvatore Orlando <sorlando at nicira.com>
wrote:

> From the bug Kevin reported it seems multiple dhcp agents per network have
> been completely broken by the fix for bug #1345947, so a revert of patch
> [1] (and stable backports) should probably be the first thing to do - if
> nothing else because the original bug has not nearly the same level of
> severity of the one it introduced.
> Before doing this however, I am wondering why the various instances of
> dnsmasq end up returning NAKs. I expect all instances to have the same
> hosts file, so they should be able to respond to DHCPDISCOVER/DHCPREQUEST
> correctly. Is the dnsmasq log telling us exactly why the authoritative
> setting is preventing us from doing so? (this is more of a curiosity in my
> side)
>
> [1] https://review.openstack.org/#/c/152080/
>
>
>
> On 26 May 2015 at 06:57, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>
>> -----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!)
>>
>
> That was my thought as well.
> However, we should check whether that patch is ok to backport. For
> instance I see what it appears to be adding a script:
>
> [2]
> https://review.openstack.org/#/c/108272/12/bin/neutron-dhcp-agent-dnsmasq-lease-init
>
>
>>
>> ===
>>
>> 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-----
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150526/f0cf746d/attachment.html>