Open Stack

Hi,


HA on DHCP is done by setting dhcp_agents_per_network >= 2, so production
deploiements should set dhcp_agents_per_network >= 2.

Regards,

Cédric/ZZelle

On Tue, May 26, 2015 at 12:24 PM, <Neil.Jerram at metaswitch.com> wrote:

> How about retaining --dhcp-authoritative when dhcp_agents_per_network =
> 1?  I would guess that that is the 90% case.  I suppose that would require
> passing new information from the Neutron server to the DHCP agents; but
> maybe that's feasible, and it feels like the right thing to do.
>
> Also, what are the use cases for dhcp_agents_per_network >= 2 ?
>
> Regards,
>      Neil
>
>
>  
> *From: *Doug Wiegley
> *Sent: *Tuesday, 26 May 2015 04:14
> *To: *OpenStack Development Mailing List (not for usage questions)
> *Reply To: *OpenStack Development Mailing List (not for usage questions)
> *Subject: *Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative'
> option broke multiple DHCP servers
>
> After a brief IRC conversation with Kevin, he pointed out that we already
> don't allow any other ports on the subnet to send DHCP replies, so NAKs are
> completely unnecessary. I'd be fine just filtering them out for now.
>
> Thanks,
> doug
>
> On May 25, 2015, at 7:54 PM, Kevin Benton <blak111 at gmail.com> wrote:
>
> 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://OpenStack-dev-request@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-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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150526/9dd98458/attachment.html>