<div dir="ltr"><div>Hi Salvatore,</div><div><br></div><div>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]</div><div><br></div><div><br></div>1. <a href="https://github.com/kevinbenton/dnsmasq/blob/master/src/rfc2131.c#L1103">https://github.com/kevinbenton/dnsmasq/blob/master/src/rfc2131.c#L1103</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 10:12 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div>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)</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/152080/" target="_blank">https://review.openstack.org/#/c/152080/</a></div><div><br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 26 May 2015 at 06:57, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<span><br>
On 05/26/2015 04:35 AM, Kevin Benton wrote:<br>
> Hi,<br>
><br>
> A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has<br>
> caused DHCPNAK messages when multiple agents are scheduled to a<br>
> network [2].<br>
><br>
> This was back-ported to Icehouse and Juno so we need a fix that is<br>
> compatible with both of them.<br>
><br>
> I have two fixes for this so far and a third alternative if we<br>
> don't like those.<br>
><br>
> The first is hacky, but it's only a few-line change.[3] It adds an<br>
> iptables rule that just stops the DHCPNAKs from making it to the<br>
> client. This is clean to back-port but it doesn't protect clients<br>
> that have filtering disabled (e.g. bare metal).<br>
><br>
> The second persists the DHCP leases to a database.[4] The downside<br>
> to this was always that being rescheduled to another agent would<br>
> mean no entries in the lease file. This approach adds a work-around<br>
> to generate an initial fake lease file based on all of the ports in<br>
> the network.<br>
><br>
> A third approach that I don't have a patch pushed for yet is very<br>
> similar to the second. When dnsmasq is in the leasefile-ro mode, it<br>
> will call the script passed to --dhcp-script to get a list of<br>
> leases to start with. This script would be built with the same<br>
> logic as the second one. The only difference between the second<br>
> approach is that dnsmasq wouldn't persist leases to a database.<br>
><br>
<br>
</span>Actually, that approach was initially taken for bug 1345947, but then<br>
the patch was abandoned to be replaced with a simpler<br>
- --dhcp-authoritative approach that ended up with unexpected NAKs for<br>
multi agent setup.<br>
<br>
See: <a href="https://review.openstack.org/#/c/108272/12" target="_blank">https://review.openstack.org/#/c/108272/12</a><br>
<br>
Maybe we actually want to restore the work and merge it after<br>
conflicts are resolved and --dhcp-authoritative option is killed; the<br>
patch was almost merged when --dhcp-authoritative suggestion emerged,<br>
so most of nitpicking work should be complete now (though at the same<br>
time, I totally trust our community to find another pile of nits to<br>
work on for the next few weeks!)<br></blockquote><div><br></div></div></div><div>That was my thought as well.</div><div>However, we should check whether that patch is ok to backport. For instance I see what it appears to be adding a script:</div><div><br></div><div>[2] <a href="https://review.openstack.org/#/c/108272/12/bin/neutron-dhcp-agent-dnsmasq-lease-init" target="_blank">https://review.openstack.org/#/c/108272/12/bin/neutron-dhcp-agent-dnsmasq-lease-init</a></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
===<br>
<br>
Speaking of regression testing... Are full stack tests already<br>
powerful enough for us to invoke multiple DHCP agents and test the<br>
scenario?<br>
<br>
Ihar<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQEcBAEBCAAGBQJVZHvHAAoJEC5aWaUY1u57vukIAJLPpQ9O236NYtOaRTzkL7g8<br>
Io1DmF6jyhJYFqfzoFcrFVbNmM0EsNtvMgZIhI8oYINkkoBYMJPoS2a8FvVUpZHw<br>
u/fmdvdbZgJwy4BCAEF0t+R1t1XLo6eTcPp8f3jABzExWyrLoKEbHJ0aWb5xwJ3u<br>
V74HXxo/PVifrNfxsQPn57ZxqgBvl4GSQAFQKE4FX/H81HWRWRuB5a9aC+hkYC9w<br>
7FqXpf+IFCaS7tYdTSqJUa2/bKs268RQGoVqAYEtmVV5pA3OiMsy459rdLcHqqxS<br>
67lryFh1DTMwI77LjDEanXzWIdMhb3t0YZw7ewpBBLl6P/Lh7xobIOGX2GeOyJ0=<br>
=xivW<br>
-----END PGP SIGNATURE-----<br>
<div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></span></div><br></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>