ddns-dhcid is not synced to failover peer

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

ddns-dhcid is not synced to failover peer

W.J.M. Nelis
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: ddns-dhcid is not synced to failover peer

Thomas Markwalder
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users