|
|
|
|
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.
From: "neeraj jain" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
Sent: Thursday, May 12, 2011 5:55:52 AM
Subject: Re: Option 82 is missing from Secondry lease file incase of failover
hi,
I am using the DHCP server in fail-over mode and my relay agent insert the agent.circuit-id information in the DHCP packet.
This option 82 information is written into the Primary lease file after DHCP ACK. Ideally this option 82 lease information should sync between primary and secondary lease file.
But after synchronization of the lease file I don't find the agent.circuit-id is written in the secondary file. Because of the OMAPI lease query fail from the secondary server.
Thanks,
Neeraj Jain
--- On Thu, 12/5/11, Cathy Almond <[hidden email]> wrote:
From: Cathy Almond <[hidden email]>
Subject: Re: Option 82 is missing from Secondry lease file incase of failover
To: "Users of ISC
DHCP" <[hidden email]>
Date: Thursday, 12 May, 2011, 1:01 PM
On 11/05/11 10:30, neeraj jain wrote: > > Hi all, > > I am facing the below problem and knowing that this is the defect with the DHCP server. I just want to fix this problem. > > Can somebody help me to fix this problem or provide some pointer. > > Thanks in advance, > Neeraj Jain > > > --- On Thu, 5/5/11, sthaug@... < sthaug@...> wrote: > > From: sthaug@... < sthaug@...> > Subject: Re:
Option 82 is missing from Secondry lease file incase of failover > To: neerajjain_iet@...> Cc: dhcp-users@...> Date: Thursday, 5 May, 2011, 3:18 PM > >> Can somebody suggest that Why secondary is not having the option 82 information > after lease file synchronization. > > Known missing feature. See for instance > > https://lists.isc.org/pipermail/dhcp-users/2010-May/011361.html> > Steinar Haug, Nethelp consulting, sthaug@...> What
specific operational problem is this causing you? Cathy _______________________________________________ dhcp-users mailing list dhcp-users@...https://lists.isc.org/mailman/listinfo/dhcp-users
|
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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: [hidden email] 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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: [hidden email] 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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" [hidden email]
To: "Users of ISC DHCP"
[hidden email]
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: [hidden email] 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
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" [hidden email]
To: "Users of ISC DHCP" [hidden email]
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: [hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
|
Thomas,
Thank you very much! I appreciate the confirmation.
From: "Thomas Markwalder" <[hidden email]>
To: "Users of ISC DHCP" <[hidden email]>
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),
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" [hidden email]
To: "Users of ISC DHCP" [hidden email]
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: [hidden email]
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
|
|
Locked
