Option 82 is missing from Secondry lease file incase of failover
Thomas Markwalder
tmark at isc.org
Wed Jul 11 19:57:08 UTC 2018
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),
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" <ck-lists at cksoft.de>
>> *To: *"Users of ISC DHCP" <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: 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/
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> 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
>
>
>
> _______________________________________________
> 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/3b1a6e0b/attachment-0001.html>
More information about the dhcp-users
mailing list