ddns-dhcid is not synced to failover peer
Thomas Markwalder
tmark at isc.org
Tue Aug 14 14:59:29 UTC 2018
Hello:
First, it is important to know that dhcpd does not synchronize DNS
information between fail over peers. Thus, if you see DDNS information
on a lease in the lease file, it was that server that granted the lease
and udpated DDNS. Next, look at the CLTT times of the two entries. For
dhcp00, it is 11:01:45 on December 12, 2017, while on dhcp01 it is 04:45
on August 8, 2018. Finally, the dhcp00 entry is TXT and dhcp01 is DHCID.
Based on that, I would say that the lease on dhcp00 was updated via
failover update after being granted by dhcp01. You would need to look
at prior entries for this client the in the lease file to see whether it
was expired and then reissued (most likely). Because the servers do not
exchange DNS data, they have no way to know the DNS state of a lease
granted by its peer.
In your case dhcp00 granted (owned) the lease originally and did an
interim-mode update. Most recently it was granted by dhcp01 which did a
standard-mode update.
Regards,
Thomas Markwalder
ISC Software Engineering
On 08/14/2018 08:32 AM, W.J.M. Nelis wrote:
> Hi,
>
> we are for some time now moving from 'ddns-update-style interim' to
> 'ddns-update-style standard'. In the mean time most of the TXT RR in
> DNS have been replaced by DHCID RR. We are facing however a difference
> in the leases files of the two fail-over members which we do not
> understand.
>
> The lease-entry of IP phone it1001 at DHCP-server dhcp00 is:
>
> lease 137.17.159.230 {
> starts 2 2018/08/14 04:55:14;
> ends 2 2018/08/14 17:25:14;
> tstp 6 2017/12/16 05:46:45;
> tsfp 2 2018/08/14 23:40:14;
> atsfp 2 2018/08/14 23:40:14;
> cltt 5 2017/12/15 11:01:45;
> binding state active;
> next binding state expired;
> hardware ethernet 64:16:7f:03:b2:08;
> set ddns-rev-name = "230.159.17.137.in-addr.arpa.";
> set ddns-txt = "0001e0b227339ca36be2eb578af5a9f3c8";
> set ddns-fwd-name = "it1001.nlr.nl.";
> set network-location = "nlrlnx113;ge-0/0/45;224";
> set vendor-string = "Polycom-VVX601";
> set nlr-site = "asd";
> set vendor-class-identifier = "Polycom-VVX601";
> option agent.circuit-id "ge-0/0/45.0:224";
> option agent.remote-id "nlrlnx113";
> client-hostname "Polycom_64167f03b208";
> }
>
> The corresponding entry in de leases-file of server dhcp01 is:
>
> lease 137.17.159.230 {
> starts 2 2018/08/14 04:55:14;
> ends 2 2018/08/14 17:25:14;
> tstp 2 2018/08/14 23:40:14;
> tsfp 2 2018/08/14 23:40:14;
> atsfp 2 2018/08/14 23:40:14;
> cltt 2 2018/08/14 04:55:14;
> binding state active;
> next binding state expired;
> hardware ethernet 64:16:7f:03:b2:08;
> set ddns-rev-name = "230.159.17.137.in-addr.arpa.";
> set ddns-fwd-name = "it1001.nlr.nl.";
> set vendor-class-identifier = "Polycom-VVX601";
> set nlr-site = "asd";
> set vendor-string = "Polycom-VVX601";
> set network-location = "nlrlnx113;ge-0/0/45;224";
> set ddns-dhcid =
> "\000\000\001UjIl`j\016\213\333t\330\214\350\005\204Wu\001\333#\222\3622@\234t\321\372\343+z\031";
> option agent.circuit-id "ge-0/0/45.0:224";
> option agent.remote-id "nlrlnx113";
> client-hostname "Polycom_64167f03b208";
> }
>
> The logfile at server dhcp00 does not contain any entries for this IP
> phone. The log file at server dhcp01 contains the following lines:
>
> Aug 14 06:55:14 soda134u dhcpd: DHCPREQUEST for 137.17.159.230 from
> 64:16:7f:03:b2:08 (Polycom_64167f03b208) via bond0
> Aug 14 06:55:14 soda134u dhcpd: DHCPACK on 137.17.159.230 to
> 64:16:7f:03:b2:08 (Polycom_64167f03b208) via bond0
> Aug 14 06:55:14 soda134u dhcpd: Added new forward map from
> it1001.nlr.nl. to 137.17.159.230
> Aug 14 06:55:14 soda134u dhcpd: Added reverse map from
> 230.159.17.137.in-addr.arpa. to it1001.nlr.nl.
>
> We are using ISC DHCP Server 4.4.1 at both servers.
>
> Is this difference in some way 'normal'? Is it possibly a remnant of
> the old days, as the IP phone might have not been requesting a new IP
> address since the introduction of 'ddns-update-style standard'? And
> most importantly: can this difference be undone, without the need to
> force all devices with a long uptime to request a new IP address?
>
> Wim Nelis.
>
>
>
> _______________________________________________
> 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/20180814/652a2f42/attachment.html>
More information about the dhcp-users
mailing list