<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 01/28/2015 09:50 AM, Kevin Benton wrote:<br>
<blockquote
cite="mid:CAO_F6JNm2cp8mcA5Q942hxH-ksE4ZBMxhbnj4pDj61WTnyb+eA@mail.gmail.com"
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>
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 class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc3203">https://tools.ietf.org/html/rfc3203</a><br>
<br>
<blockquote
cite="mid:CAO_F6JNm2cp8mcA5Q942hxH-ksE4ZBMxhbnj4pDj61WTnyb+eA@mail.gmail.com"
type="cite">
<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>
<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>
<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><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 moz-do-not-send="true"
href="https://github.com/openstack/neutron/commit/d9832282cf656b162c51afdefb830dacab72defe">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 moz-do-not-send="true"
href="https://review.openstack.org/#/c/150595/">https://review.openstack.org/#/c/150595/</a></div>
<div>4. <a moz-do-not-send="true"
href="http://i.imgur.com/xtvatkP.jpg">http://i.imgur.com/xtvatkP.jpg</a></div>
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div>Kevin Benton</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>