Option 82 is missing from Secondry lease file incase of failover

Wed Jul 11 20:02:43 UTC 2018

Thomas, 

Thank you very much! I appreciate the confirmation. 

> From: "Thomas Markwalder" <tmark at isc.org>
> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> Sent: Wednesday, July 11, 2018 3:57:08 PM
> Subject: Re: Option 82 is missing from Secondry lease file incase of failover

> Hello:

> It is intentional from what I can see. The function,
> dhcp_failover_send_bind_update(), accounts for them as a "todo" (Note
> the triple-Xs at line 4770):

> :
> 4739 status = (dhcp_failover_put_message
> 4740 (link, link -> outer,
> 4741 FTM_BNDUPD, lease->last_xid,
> 4742 dhcp_failover_make_option (FTO_ASSIGNED_IP_ADDRESS, FMA,
> 4743 lease -> ip_addr.len,
> 4744 lease -> ip_addr.iabuf),
> 4745 dhcp_failover_make_option (FTO_BINDING_STATUS, FMA,
> 4746 lease -> desired_binding_state),
> 4747 lease -> uid_len
> 4748 ? dhcp_failover_make_option (FTO_CLIENT_IDENTIFIER, FMA,
> 4749 lease -> uid_len,
> 4750 lease -> uid)
> 4751 : &skip_failover_option,
> 4752 lease -> hardware_addr.hlen
> 4753 ? dhcp_failover_make_option (FTO_CHADDR, FMA,
> 4754 lease -> hardware_addr.hlen,
> 4755 lease -> hardware_addr.hbuf)
> 4756 : &skip_failover_option,
> 4757 dhcp_failover_make_option (FTO_LEASE_EXPIRY, FMA,
> 4758 lease -> ends),
> 4759 dhcp_failover_make_option (FTO_POTENTIAL_EXPIRY, FMA,
> 4760 lease -> tstp),
> 4761 dhcp_failover_make_option (FTO_STOS, FMA,
> 4762 lease -> starts),
> 4763 (lease->cltt != 0) ?
> 4764 dhcp_failover_make_option(FTO_CLTT, FMA, lease->cltt) :
> 4765 &skip_failover_option, /* No CLTT */
> 4766 flags ? dhcp_failover_make_option(FTO_IP_FLAGS, FMA,
> 4767 flags) :
> 4768 &skip_failover_option, /* No IP_FLAGS */
> 4769 &skip_failover_option, /* XXX DDNS */
> 4770 &skip_failover_option, /* XXX request options */
> 4771 &skip_failover_option, /* XXX reply options */
> 4772 (failover_option_t *)0));
> :

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

> Table 7.1.1, in the draft for DHCPv4 Failover ( [
> 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 ] ), 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.

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

> Hope this helps.

> Thomas Markwalder
> ISC Software Engineering

> On 07/11/2018 01:59 PM, Thomas Markwalder wrote:

>> Hello:

>> I will double check this and get back to you.

>> Regards,

>> Thomas Markwalder
>> ISC Software Engineering

>> On 07/11/2018 01:52 PM, perl-list wrote:

>>> Folks,

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

>>>> From: "Christian Kratzer" [ mailto:ck-lists at cksoft.de | <ck-lists at cksoft.de> ]
>>>> To: "Users of ISC DHCP" [ mailto:dhcp-users at lists.isc.org |
>>>> <dhcp-users at lists.isc.org> ]
>>>> Sent: Monday, July 2, 2018 11:32:20 AM
>>>> Subject: Re: Option 82 is missing from Secondry lease file incase of failover

>>>> Hi,

>>>> On Mon, 2 Jul 2018, perl-list wrote:

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

>>>> yes I believe I cam to the same conclusion when evaluating isc dhcp failover for
>>>> a certain use case a couple of years ago.

>>>> Agent options are not replicated between failover peers.

>>>> I added agent options to the omapi lease lookups back then.

>>>> Something similar would have to be done to the lease replication for failover
>>>> but I have not looked into it.

>>>> Time would propably be better spent in transitioning to KEA which also has a
>>>> superior failover mode that also works for ipv6.

>>>> Greetings
>>>> Christian

>>>> --
>>>> Christian Kratzer CK Software GmbH
>>>> Email: [ mailto:ck at cksoft.de | ck at cksoft.de ] Wildberger Weg 24/2
>>>> Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
>>>> Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
>>>> Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
>>>> Web: [ http://www.cksoft.de/ | http://www.cksoft.de/ ]
>>>> _______________________________________________
>>>> dhcp-users mailing list
>>>> [ mailto:dhcp-users at lists.isc.org | dhcp-users at lists.isc.org ]
>>>> [ https://lists.isc.org/mailman/listinfo/dhcp-users |
>>>> https://lists.isc.org/mailman/listinfo/dhcp-users ]
>>> _______________________________________________
>>> dhcp-users mailing list [ mailto:dhcp-users at lists.isc.org |
>>> dhcp-users at lists.isc.org ] [ https://lists.isc.org/mailman/listinfo/dhcp-users
>>> | https://lists.isc.org/mailman/listinfo/dhcp-users ]

>> _______________________________________________
>> dhcp-users mailing list [ mailto:dhcp-users at lists.isc.org |
>> dhcp-users at lists.isc.org ] [ https://lists.isc.org/mailman/listinfo/dhcp-users
>> | https://lists.isc.org/mailman/listinfo/dhcp-users ]

> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20180711/06a9d9be/attachment.html>