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 <sorla...@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 <ihrac...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev