<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>