<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 6/2/2022 11:30 PM, Gregory Sloop
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:15810207371.20220602213019@sloop.net">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <style type="text/css" title="rt_noDelete">blockquote.rt {
    margin: 0 0 15px;
    border-left: 4px solid #81c784;
    padding: 0 0 0 12px;
    display: block;
    }p { margin: 0 0 0 0 }.email-signature {font-family:"Arial"; font-size: 8pt; font-style: italic; font-weight: normal; text-decoration: none; }</style>
      <p class="norm">Are you seeing balance messages every hour as the
        two re-balance the available lease pool?</p>
    </blockquote>
    No, I don't think so.  It has only been a couple of hours since I
    have had both online, however.<br>
    <blockquote type="cite"
      cite="mid:15810207371.20220602213019@sloop.net">
      <p class="norm"> </p>
      <p>You say they are both handling leases properly, but how do you
        know this? (That a machine gets a lease from somewhere is not
        good evidence.)</p>
    </blockquote>
    <p>    Do you mean because some other machine / device could be
      issuing leases?  No.  In that case,</p>
    <p>    1. Killing both servers would not take down any DHCP
      clients.  If both servers are shut down, DHCP clients start
      failing in about an hour, until they are all dead.</p>
    <p>    2. DHCP responses on the LAN stop completely the moment both
      servers are taken down.</p>
    <p>    3. No other machine would know anything about the list of
      dynamically assigned fixed IP addresses in dhcpd.static.  None of
      the addresses of any of the clients ever change.</p>
    <p>    4. Whenever one server is shut down, the other responds with
      tons of responses in  the log.<br>
    </p>
    <blockquote type="cite"
      cite="mid:15810207371.20220602213019@sloop.net">
      <p>A packet capture in front of the secondary might be helpful to
        see what traffic is passing - both to the peer and to clients.</p>
    </blockquote>
        While not impossible, that is a bit easier said than done.  The
    links between the servers are 10G.  I can look into it.<br>
    <blockquote type="cite"
      cite="mid:15810207371.20220602213019@sloop.net">
      <p> </p>
      <p>(I hate making captures, at least as much as the next person,
        but dang if they don't, nearly always, show something that was
        different than I assumed. So, I've just gotten a lot less averse
        to getting captures. Yeah, they'll probably take me extra time
        to setup and get and paw through, [all when I could be fixin'
        stuff!] but they can save hours or days of fruitless searching
        for a fix, when I don't even really *know* what's wrong yet.
        Don't know about anyone else, but fixing problems gets a whole
        lot easier when I actually know what's wrong, or at least have a
        good idea what's going on. :)</p>
    </blockquote>
    <p>    Agreed, although when an interface is chunking away at over
      10,000 packets per second...</p>
    <p>    If something doesn't break loose, I will see about loading
      Wireshark.<br>
    </p>
  </body>
</html>