discrepancy/differences in dhcpd.leases (active leases) on failover pair

Oscar Ricardo Silva oscars at mail.utexas.edu
Fri May 8 16:39:29 UTC 2009


We've noticed some discrepancies/differences in active leases on a 
failover pair and were wondering if it's really an issue or just a side 
effect of something else.  I should mention that we have changed the 
split statement to favor one of the servers over the others.  Here's 
dhcpd.conf for both servers:


Primary:

option domain-name-servers 128.83.185.41, 128.83.185.40 ;
default-lease-time 86400;
max-lease-time 86400;
one-lease-per-client true;
ddns-update-style ad-hoc;
ddns-updates off;
authoritative;

failover peer "pub-dhcp" {
          primary;
          address 172.16.200.34;
          port 520;
          peer address 172.16.201.34;
          peer port 520;
          max-response-delay 60;
          max-unacked-updates 10;
          mclt 120;
          split 255;
          load balance max seconds 5;
        }

include "/dhcpd/om.conf";
include "/dhcpd/public.dhcpd.conf";




Secondary:

option domain-name-servers 128.83.185.41, 128.83.185.40 ;
default-lease-time 86400;
max-lease-time 86400;
one-lease-per-client true;
ddns-update-style ad-hoc;
ddns-updates off;
authoritative;

failover peer "pub-dhcp" {
          secondary;
          address 172.16.201.34;
          port 520;
          peer address 172.16.200.34;
          peer port 520;
          max-response-delay 60;
          max-unacked-updates 10;
          load balance max seconds 5;
        }

include "/dhcpd/om.conf";
include "/dhcpd/public.dhcpd.conf";




In looking at the primary's dhcpd.leases I found the following:


lease 128.62.100.104 {
   starts 5 2009/05/08 14:01:45;
   ends 5 2009/05/08 15:01:45;
   tstp 5 2009/05/08 15:31:45;
   tsfp 5 2009/05/08 15:31:45;
   atsfp 5 2009/05/08 15:31:45;
   cltt 5 2009/05/08 14:01:45;
   binding state active;
   next binding state expired;
   hardware ethernet 00:1f:5a:4b:35:5b;
   option agent.circuit-id 0:0:0:0;
   option agent.remote-id 0:1d:e5:8f:7f:40;
   client-hostname "Oscar";
}

lease 128.62.100.118 {
   starts 5 2009/05/08 13:45:43;
   ends 5 2009/05/08 14:45:43;
   tstp 5 2009/05/08 15:15:43;
   tsfp 5 2009/05/08 15:15:43;
   cltt 5 2009/05/08 13:45:43;
   binding state expired;
   next binding state free;
   hardware ethernet 00:23:13:53:9b:84;
   option agent.circuit-id 0:0:0:0:0:0:0:0;
   option agent.remote-id 0:19:a9:56:fd:e0:0:0:0:0:0:0;
   client-hostname "macbook-2";
}



while the secondary has:

lease 128.62.100.104 {
   starts 5 2009/05/08 14:01:45;
   ends 5 2009/05/08 14:25:34;
   tstp 5 2009/05/08 14:25:34;
   tsfp 5 2009/05/08 14:25:34;
   atsfp 5 2009/05/08 14:25:34;
   cltt 5 2009/05/08 14:01:45;
   binding state free;
   hardware ethernet 00:1f:5a:4b:35:5b;
}

lease 128.62.100.118 {
   starts 5 2009/05/08 13:45:43;
   ends 5 2009/05/08 14:45:43;
   tstp 5 2009/05/08 14:45:43;
   tsfp 5 2009/05/08 15:15:43;
   atsfp 5 2009/05/08 15:15:43;
   cltt 5 2009/05/08 13:45:43;
   binding state free;
   hardware ethernet 00:23:13:53:9b:84;
}




Here are the associated logs for these machines and IP addresses.  The 
secondary's logs show that the request was load balanced to the peer.


128.62.100.118

Primary:
May  8 08:44:42 NOCA-PUB-DHCP dhcpd: DHCPREQUEST for 192.168.1.2 from 
00:23:13:53:9b:84 via 172.17.32.35: wrong network.
May  8 08:44:42 NOCA-PUB-DHCP dhcpd: DHCPNAK on 192.168.1.2 to 
00:23:13:53:9b:84 via 172.17.32.35
May  8 08:44:43 NOCA-PUB-DHCP dhcpd: DHCPDISCOVER from 00:23:13:53:9b:84 
via 172.17.32.35
May  8 08:44:44 NOCA-PUB-DHCP dhcpd: DHCPOFFER on 128.62.100.118 to 
00:23:13:53:9b:84 (macbook-2) via 172.17.32.35
May  8 08:44:44 NOCA-PUB-DHCP dhcpd: DHCPREQUEST for 128.62.100.118 
(172.16.200.34) from 00:23:13:53:9b:84 (macbook-2) via 172.17.32.35
May  8 08:44:44 NOCA-PUB-DHCP dhcpd: DHCPACK on 128.62.100.118 to 
00:23:13:53:9b:84 (macbook-2) via 172.17.32.35
May  8 08:45:00 NOCA-PUB-DHCP dhcpd: DHCPINFORM from 128.62.100.118 via 
172.17.32.35
May  8 08:45:00 NOCA-PUB-DHCP dhcpd: DHCPACK to 128.62.100.118 
(00:23:13:53:9b:84) via eth0
May  8 08:45:43 NOCA-PUB-DHCP dhcpd: DHCPREQUEST for 128.62.100.118 from 
00:23:13:53:9b:84 (macbook-2) via 172.17.32.35
May  8 08:45:43 NOCA-PUB-DHCP dhcpd: DHCPACK on 128.62.100.118 to 
00:23:13:53:9b:84 (macbook-2) via 172.17.32.35

Secondary:
May  8 08:44:42 NOCB-PUB-DHCP dhcpd: DHCPREQUEST for 192.168.1.2 from 
00:23:13:53:9b:84 via 172.17.32.35: wrong network.
May  8 08:44:42 NOCB-PUB-DHCP dhcpd: DHCPNAK on 192.168.1.2 to 
00:23:13:53:9b:84 via 172.17.32.35
May  8 08:44:43 NOCB-PUB-DHCP dhcpd: DHCPDISCOVER from 00:23:13:53:9b:84 
via 172.17.32.35: load balance to peer pub-dhcp



128.62.100.104

Primary:
May  8 09:00:35 NOCA-PUB-DHCP dhcpd: DHCPREQUEST for 10.0.1.6 from 
00:1f:5a:4b:35:5b via 172.17.32.44: wrong network.
May  8 09:00:35 NOCA-PUB-DHCP dhcpd: DHCPNAK on 10.0.1.6 to 
00:1f:5a:4b:35:5b via 172.17.32.44
May  8 09:00:35 NOCA-PUB-DHCP dhcpd: DHCPDISCOVER from 00:1f:5a:4b:35:5b 
via 172.17.32.44
May  8 09:00:36 NOCA-PUB-DHCP dhcpd: DHCPOFFER on 128.62.100.104 to 
00:1f:5a:4b:35:5b (Oscar) via 172.17.32.44
May  8 09:00:37 NOCA-PUB-DHCP dhcpd: DHCPREQUEST for 128.62.100.104 
(172.16.200.34) from 00:1f:5a:4b:35:5b (Oscar) via 172.17.32.44
May  8 09:00:37 NOCA-PUB-DHCP dhcpd: DHCPACK on 128.62.100.104 to 
00:1f:5a:4b:35:5b (Oscar) via 172.17.32.44
May  8 09:01:45 NOCA-PUB-DHCP dhcpd: DHCPREQUEST for 128.62.100.104 from 
00:1f:5a:4b:35:5b (Oscar) via 172.17.32.44
May  8 09:01:45 NOCA-PUB-DHCP dhcpd: DHCPACK on 128.62.100.104 to 
00:1f:5a:4b:35:5b (Oscar) via 172.17.32.44

Secondary:
May  8 09:00:35 NOCB-PUB-DHCP dhcpd: DHCPREQUEST for 10.0.1.6 from 
00:1f:5a:4b:35:5b via 172.17.32.44: wrong network.
May  8 09:00:35 NOCB-PUB-DHCP dhcpd: DHCPNAK on 10.0.1.6 to 
00:1f:5a:4b:35:5b via 172.17.32.44
May  8 09:00:35 NOCB-PUB-DHCP dhcpd: DHCPDISCOVER from 00:1f:5a:4b:35:5b 
via 172.17.32.44: load balance to peer pub-dhcp



Don't the the peers update each other and consequently update their 
dhcpd.leases so that they have a consistent state?  For a the range of 
times, I found hundreds of differences in the number of active leases 
each server in the peer relationship reported.



Oscar



More information about the dhcp-users mailing list