Open Stack

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 <dougwig at 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 <blak111 at 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-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/20150525/8d33f97d/attachment.html>