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.jer...@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 <blak...@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 < > 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://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 > > > > > __________________________________________________________________________ > 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