
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">Thanks,</div><div class="">doug</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 25, 2015, at 7:54 PM, Kevin Benton <<a href="mailto:blak111@gmail.com" class="">blak111@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Here is the description of the behavior for --dhcp-authoritative from the dnsmasq page. [1]<br class=""><div class=""><br class=""></div><div class="">>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).</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">1. <a href="http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html" target="_blank" class="">http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html</a></div><div class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, May 25, 2015 at 7:44 PM, Doug Wiegley <span dir="ltr" class=""><<a href="mailto:dougwig@parksidesoftware.com" target="_blank" class="">dougwig@parksidesoftware.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Option 4, turn off authoritative if we don’t want NAK’s?<div class=""><br class=""></div><div class="">doug</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">On May 25, 2015, at 7:35 PM, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank" class="">blak111@gmail.com</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class=""><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class="">A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused DHCPNAK messages when multiple agents are scheduled to a network [2].</div><div class=""><div class=""><br class=""></div><div class="">This was back-ported to Icehouse and Juno so we need a fix that is compatible with both of them.</div><div class=""><br class=""></div><div class="">I have two fixes for this so far and a third alternative if we don't like those.</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I'm looking for feedback on how we want to go forward with this in a back-port friendly manner.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Kevin Benton</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">1. <a href="https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z" target="_blank" class="">https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z</a></div><div class="">2. <a href="https://bugs.launchpad.net/neutron/+bug/1457900" target="_blank" class="">https://bugs.launchpad.net/neutron/+bug/1457900</a></div><div class="">3. <a href="https://review.openstack.org/#/c/185332/" target="_blank" class="">https://review.openstack.org/#/c/185332/</a></div><div class="">4. <a href="https://review.openstack.org/#/c/185486/" target="_blank" class="">https://review.openstack.org/#/c/185486/</a></div><div class=""><br class=""></div>-- <br class=""><div class=""><div class="">Kevin Benton</div></div>

</div></div></div></div>

__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></div><br class="">__________________________________________________________________________<br class="">

OpenStack Development Mailing List (not for usage questions)<br class="">

Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">

<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">

<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class=""><div class="">Kevin Benton</div></div>

</div></div>

__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></body></html>