<div dir="ltr">The patch Kevin points out increased the lease to 24 hours (which I agree is as arbitrary as 2 minutes, 8 minutes, or 1 century) because it introduced use of DHCPRELEASE message in the agent, which is supported by dnsmasq (to the best of my knowledge) and is functionally similar to FORCERENEW.<div><br></div><div>This should have provided resiliency against changes of IP address from the Neutron API, as the agent would send a DHCPRELEASE message as the notification was received. When we reviewed the patch we verified that a number of client supported this message (to my shame I must admit I did not consider windows clients however).</div><div><br></div><div>It seems like the problem perhaps is that DHCPRELEASE is actually not working as expected, or not working all?</div><div><br></div><div>Salvatore</div><div><div><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote">On 28 January 2015 at 14:55, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
On 01/28/2015 09:50 AM, Kevin Benton wrote:<br>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>Approximately a year and a half ago, the default DHCP lease
time in Neutron was increased from 120 seconds to 86400
seconds.[1] This was done with the goal of reducing DHCP
traffic with very little discussion (based on what I can see
in the review and bug report). While it it does indeed reduce
DHCP traffic, I don't think any bug reports were filed showing
that a 120 second lease time resulted in too much traffic or
that a jump all of the way to 86400 seconds was required
instead of a value in the same order of magnitude.</div>
</div>
</blockquote>
<br></span>
I guess that would be a good case for FORCERENEW DHCP extension [1]
though after digging thru dnsmasq code a bit, I doubt it supports
the extension (though e.g. systemd dhcp client/server from networkd
module do). Le sigh.<br>
<br>
[1]: <a href="https://tools.ietf.org/html/rfc3203" target="_blank">https://tools.ietf.org/html/rfc3203</a><br>
<br>
<blockquote type="cite"><span class="">
<div dir="ltr">
<div><br>
</div>
<div>Why does this matter? </div>
<div><br>
</div>
<div>Neutron ports can be updated with a new IP address from the
same subnet or another subnet on the same network. The port
update will result in anti-spoofing iptables rule changes that
immediately stop the old IP address from working on the host.
This means the host is unreachable for 0-12 hours based on the
current default lease time without manual intervention[2]
(assuming half-lease length DHCP renewal attempts).</div>
<div><br>
</div>
<div>Why is this on the mailing list?</div>
<div><br>
</div>
<div>In an attempt to make the VMs usable in a much shorter
timeframe following a Neutron port address change, I submitted
a patch to reduce the default DHCP lease time to 8 minutes.[3]
However, this was upsetting to several people,[4] so it was
suggested I bring this discussion to the mailing list. The
following are the high-level concerns followed by my
responses:</div>
<div>
<ul>
<li>8 minutes is arbitrary</li>
<ul>
<li>Yes, but it's no more arbitrary than 1440 minutes. I
picked it as an interval because it is still 4 times
larger than the last short value, but it still allows
VMs to regain connectivity in <5 minutes in the event
their IP is changed. If someone has a good suggestion
for another interval based on known dnsmasq QPS limits
or some other quantitative reason, please chime in here.</li></ul></ul></div></div></span></blockquote></div></blockquote><div><br></div><div>I think there little to no point in arguing about an optimal default lease time. Simply because there isn't. If you want to move that to 8 minutes, that's fine for me. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><span class=""><div dir="ltr"><div><ul><ul>
</ul>
<li>other datacenters use long lease times</li>
<ul>
<li>This is true, but it's not really a valid comparison.
In most regular datacenters, updating a static DHCP
lease has no effect on the data plane so it doesn't
matter that the client doesn't react for hours/days
(even with DHCP snooping enabled). However, in Neutron's
case, the security groups are immediately updated so all
traffic using the old address is blocked.</li></ul></ul></div></div></span></blockquote></div></blockquote><div>Kevin's comment here is totally reasonable, but implies that the devised mechanisms based on DHCPRELEASE is not working!</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><span class=""><div dir="ltr"><div><ul><ul>
</ul>
<li>dhcp traffic is scary because it's broadcast</li>
<ul>
<li>ARP traffic is also broadcast and many clients will
expire entries every 5-10 minutes and re-ARP.
L2population may be used to prevent ARP propagation, so
the comparison between DHCP and ARP isn't always
relevant here.</li></ul></ul></div></div></span></blockquote></div></blockquote><div><br></div><div>I think this is a bit of a moot point. What's the impact of DHCP traffic, even the DHCPDISCOVER broadcast on the overall traffic on a network? It's not like a DHCP packet is a train of several hundreds ethernet frames, isn't it?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><span class=""><div dir="ltr"><div><ul><ul>
</ul>
</ul>
</div>
<div><br>
</div>
<div>Please reply back with your opinions/anecdotes/data related
to short DHCP lease times.</div>
<div><br>
</div>
<div>Cheers</div>
<div><br>
</div>
<div>1. <a href="https://github.com/openstack/neutron/commit/d9832282cf656b162c51afdefb830dacab72defe" target="_blank">https://github.com/openstack/neutron/commit/d9832282cf656b162c51afdefb830dacab72defe</a><br clear="all">
<div>2. Manual intervention could be an instance reboot, a
dhcp client invocation via the console, or a delayed
invocation right before the update. (all significantly more
difficult to script than a simple update of a port's IP via
the API).</div>
<div>3. <a href="https://review.openstack.org/#/c/150595/" target="_blank">https://review.openstack.org/#/c/150595/</a></div>
<div>4. <a href="http://i.imgur.com/xtvatkP.jpg" target="_blank">http://i.imgur.com/xtvatkP.jpg</a></div>
<div><br>
</div>
-- <br>
<div>
<div>Kevin Benton</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</span><span class=""><pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</span></blockquote>
<br>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>