<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <tt>Hello:<br>
      <br>
      It is intentional from what I can see. The function,
      dhcp_failover_send_bind_update(), accounts for them as a "todo"
      (Note<br>
      the triple-Xs at line 4770):<br>
      <br>
          :<br>
      4739         status = (dhcp_failover_put_message<br>
      4740                   (link, link -> outer,<br>
      4741                    FTM_BNDUPD, lease->last_xid,<br>
      4742                    dhcp_failover_make_option
      (FTO_ASSIGNED_IP_ADDRESS, FMA,<br>
      4743                                               lease ->
      ip_addr.len,<br>
      4744                                               lease ->
      ip_addr.iabuf),<br>
      4745                    dhcp_failover_make_option
      (FTO_BINDING_STATUS, FMA,<br>
      4746                                               lease ->
      desired_binding_state),<br>
      4747                    lease -> uid_len<br>
      4748                    ? dhcp_failover_make_option
      (FTO_CLIENT_IDENTIFIER, FMA,<br>
      4749                                                 lease ->
      uid_len,<br>
      4750                                                 lease ->
      uid)<br>
      4751                    : &skip_failover_option,<br>
      4752                    lease -> hardware_addr.hlen<br>
      4753                    ? dhcp_failover_make_option (FTO_CHADDR,
      FMA,<br>
      4754                                                 lease ->
      hardware_addr.hlen,<br>
      4755                                                 lease ->
      hardware_addr.hbuf)<br>
      4756                    : &skip_failover_option,<br>
      4757                    dhcp_failover_make_option
      (FTO_LEASE_EXPIRY, FMA,<br>
      4758                                               lease ->
      ends),<br>
      4759                    dhcp_failover_make_option
      (FTO_POTENTIAL_EXPIRY, FMA,<br>
      4760                                               lease ->
      tstp),<br>
      4761                    dhcp_failover_make_option (FTO_STOS, FMA,<br>
      4762                                               lease ->
      starts),<br>
      4763                    (lease->cltt != 0) ?<br>
      4764                         dhcp_failover_make_option(FTO_CLTT,
      FMA, lease->cltt) :<br>
      4765                         &skip_failover_option, /* No CLTT
      */<br>
      4766                    flags ?
      dhcp_failover_make_option(FTO_IP_FLAGS, FMA,<br>
      4767                                                      flags) :<br>
      4768                            &skip_failover_option, /* No
      IP_FLAGS */<br>
      4769                    &skip_failover_option,       /* XXX
      DDNS */<br>
      4770                    &skip_failover_option,       /* XXX
      request options */<br>
      4771                    &skip_failover_option,       /* XXX
      reply options */<br>
      4772                    (failover_option_t *)0));<br>
          :<br>
      <br>
      The variable, skip_failover_option, is an empty option and serves
      as a place holder. This section of code has been this way since
      originally authored by Ted Lemon back in 2000 (Yes, there were
      computers then.  I have some polaroids to prove it.).<br>
      <br>
      Table 7.1.1, in the draft for DHCPv4 Failover
      (<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-dhc-failover-12#section-7.1">https://tools.ietf.org/html/draft-ietf-dhc-failover-12#section-7.1</a>),
      lists as "SHOULD" send client-request-options, which is later
      defines on page 55.  That definition could be interpreted as
      including agent options.  So while the FO message protocol can
      accommodate sending them, and suggests a server "should" send the
      options it deems "interesting", our server has never been expanded
      to do so.  One can make the same observation about DDNS and
      client-reply-options. Our server does not exchange those either. 
      I can only infer that demand for these never reached a level
      sufficient for it to get implemented. Additionally, the draft
      proposal expired before ever reaching the status of RFC.  Whether
      something is or is not official has also, always played a part in
      what gets implemented.<br>
      <br>
      As I'm sure you're aware ISC is small, non-profit  with finite
      resources and as such have always had to pick and choose, based
      largely on demand, what gets done and what does not.  We would
      certainly, welcome a patch should someone submit one for
      consideration.<br>
      <br>
      Hope this helps.<br>
      <br>
      Thomas Markwalder<br>
      ISC Software Engineering<br>
    </tt><br>
    <br>
    <div class="moz-cite-prefix">On 07/11/2018 01:59 PM, Thomas
      Markwalder wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:fe9456fb-928c-d71b-3d4b-bba62c52fc54@isc.org">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <tt>Hello:<br>
        <br>
        I will double check this and get back to you.<br>
        <br>
        Regards,<br>
        <br>
        Thomas Markwalder<br>
        ISC Software Engineering<br>
      </tt><br>
      <div class="moz-cite-prefix">On 07/11/2018 01:52 PM, perl-list
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:1148461855.228479.1531331534237.JavaMail.zimbra@network1.net">
        <div style="font-family: Andale Mono; font-size: 10pt; color:
          #000000">
          <div style="font-family: Andale Mono; font-size: 10pt; color:
            #000000">Folks,</div>
          <div style="font-family: Andale Mono; font-size: 10pt; color:
            #000000"><br data-mce-bogus="1">
          </div>
          <div style="font-family: Andale Mono; font-size: 10pt; color:
            #000000">If any ISC employee is still monitoring this list,
            could we get an official confirmation that option 82 data
            (ie: option agent.circuit-id and option agent.remote-id) is
            NOT shared during the failover synchronization between
            failover peers and that this is by design (ie: not a bug)?<br>
            <br>
            <hr id="zwchr" data-marker="__DIVIDER__">
            <div data-marker="__HEADERS__">
              <blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
                </b>"Christian Kratzer" <a
                  class="moz-txt-link-rfc2396E"
                  href="mailto:ck-lists@cksoft.de"
                  moz-do-not-send="true"><ck-lists@cksoft.de></a><br>
                <b>To: </b>"Users of ISC DHCP" <a
                  class="moz-txt-link-rfc2396E"
                  href="mailto:dhcp-users@lists.isc.org"
                  moz-do-not-send="true"><dhcp-users@lists.isc.org></a><br>
                <b>Sent: </b>Monday, July 2, 2018 11:32:20 AM<br>
                <b>Subject: </b>Re: Option 82 is missing from Secondry
                lease file incase of failover<br>
              </blockquote>
            </div>
            <div data-marker="__QUOTED_TEXT__">
              <blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">Hi,<br>
                <br>
                On Mon, 2 Jul 2018, perl-list wrote:<br>
                <br>
                > This is still a problem. It isn't that only the
                primary has the option 82 information. Its actually that
                the issuing server (the one that sent the offer) has the
                option 82 information in the dhcpd.leases file. The one
                that did not issue and received the lease via failover
                synchronization DOES NOT have the option 82 stashed in
                the dhcpd.leases file. I have stash-agent-options true;
                in the config file.<br>
                ><br>
                <br>
                yes I believe I cam to the same conclusion when
                evaluating isc dhcp failover for a certain use case a
                couple of years ago.<br>
                <br>
                Agent options are not replicated between failover peers.<br>
                <br>
                I added agent options to the omapi lease lookups back
                then.<br>
                <br>
                Something similar would have to be done to the lease
                replication for failover but I have not looked into it.<br>
                <br>
                Time would propably be better spent in transitioning to
                KEA which also has a superior failover mode that also
                works for ipv6.<br>
                <br>
                Greetings<br>
                Christian<br>
                <br>
                -- <br>
                Christian Kratzer                   CK Software GmbH<br>
                Email:   <a class="moz-txt-link-abbreviated"
                  href="mailto:ck@cksoft.de" moz-do-not-send="true">ck@cksoft.de</a>
                              Wildberger Weg 24/2<br>
                Phone:   +49 7032 893 997 - 0       D-71126 Gaeufelden<br>
                Fax:     +49 7032 893 997 - 9       HRB 245288,
                Amtsgericht Stuttgart<br>
                Mobile:  +49 171 1947 843           Geschaeftsfuehrer:
                Christian Kratzer<br>
                Web:     <a class="moz-txt-link-freetext"
                  href="http://www.cksoft.de/" moz-do-not-send="true">http://www.cksoft.de/</a><br>
                _______________________________________________<br>
                dhcp-users mailing list<br>
                <a class="moz-txt-link-abbreviated"
                  href="mailto:dhcp-users@lists.isc.org"
                  moz-do-not-send="true">dhcp-users@lists.isc.org</a><br>
                <a class="moz-txt-link-freetext"
                  href="https://lists.isc.org/mailman/listinfo/dhcp-users"
                  moz-do-not-send="true">https://lists.isc.org/mailman/listinfo/dhcp-users</a></blockquote>
            </div>
          </div>
          <div><br>
          </div>
        </div>
        <!--'"--><br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org" moz-do-not-send="true">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users" moz-do-not-send="true">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
</pre>
      </blockquote>
      <br>
      <!--'"--><br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>