Here is the description of the behavior for --dhcp-authoritative from the dnsmasq page. [1]
>Should be set when dnsmasq is definitely the only DHCP server on a network. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum). As far as I understand it, the original intent of the patch that caused the issue was to fix that refusal to answer lease renewals after a restart. So it wasn't added to get NAKs, it was added to make it respond to renewals before they timeout. 1. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html On Mon, May 25, 2015 at 7:44 PM, Doug Wiegley <doug...@parksidesoftware.com> wrote: > Option 4, turn off authoritative if we don’t want NAK’s? > > doug > > On May 25, 2015, at 7:35 PM, Kevin Benton <blak...@gmail.com> 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. > > > I'm looking for feedback on how we want to go forward with this in a > back-port friendly manner. > > Cheers, > Kevin Benton > > > 1. > https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z > 2. https://bugs.launchpad.net/neutron/+bug/1457900 > 3. https://review.openstack.org/#/c/185332/ > 4. https://review.openstack.org/#/c/185486/ > > -- > 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 > > > > __________________________________________________________________________ > 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
