pre-creating reserved leases
Foggi, Nicola
NFOGGI at depaul.edu
Wed Mar 4 06:20:15 UTC 2009
so i was able to reliably reproduce this tonight, and here's what i found with DEBUG_FIND_LEASE turned on:
the "primary" of the failover pair found the correct lease and offered it:
Mar 4 00:01:04 dhcp-sac-1s dhcpd: trying next lease matching hw addr: 10.0.82.9
Mar 4 00:01:04 dhcp-sac-1s dhcpd: Found lease for hardware address: 10.0.82.9.
Mar 4 00:01:04 dhcp-sac-1s dhcpd: Returning lease: 10.0.82.9.
Mar 4 00:01:04 dhcp-sac-1s dhcpd: DHCPDISCOVER from 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1
Mar 4 00:01:05 dhcp-sac-1s dhcpd: DHCPOFFER on 10.0.82.9 to 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1
Mar 4 00:01:09 dhcp-sac-1s dhcpd: trying next lease matching hw addr: 10.0.82.9
Mar 4 00:01:09 dhcp-sac-1s dhcpd: Found lease for hardware address: 10.0.82.9.
Mar 4 00:01:09 dhcp-sac-1s dhcpd: DHCPREQUEST for 10.0.82.6 (10.0.5.25) from 00:0e:7f:e9:6c:c3 via 10.0.82.1: lease owned by peer
however, notice that last line where the client requests 82.6, it got that address from the "secondary" server as seen below:
Mar 4 00:01:04 dhcp-lew-13s dhcpd: trying next lease matching hw addr: 10.0.82.9
Mar 4 00:01:04 dhcp-lew-13s dhcpd: not mine to allocate: 10.0.82.9
Mar 4 00:01:04 dhcp-lew-13s dhcpd: DHCPDISCOVER from 00:0e:7f:e9:6c:c3 via 10.0.82.1
Mar 4 00:01:05 dhcp-lew-13s dhcpd: DHCPOFFER on 10.0.82.6 to 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1
Mar 4 00:01:09 dhcp-lew-13s dhcpd: trying next lease matching hw addr: 10.0.82.9
Mar 4 00:01:09 dhcp-lew-13s dhcpd: not mine to allocate: 10.0.82.9
Mar 4 00:01:09 dhcp-lew-13s dhcpd: DHCPREQUEST for 10.0.82.6 (10.0.5.25) from 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1
Mar 4 00:01:09 dhcp-lew-13s dhcpd: DHCPACK on 10.0.82.6 to 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1
so looking at the find_lease function brings me to lines 3196 - 3213:
while (hw_lease) {
#if defined (DEBUG_FIND_LEASE)
log_info ("trying next lease matching hw addr: %s",
piaddr (hw_lease -> ip_addr));
#endif
#if defined (FAILOVER_PROTOCOL)
/* When failover is active, it's possible that there could
be two "free" leases for the same uid, but only one of
them that's available for this failover peer to allocate. */
if (hw_lease -> binding_state != FTS_ACTIVE &&
!lease_mine_to_reallocate (hw_lease)) {
#if defined (DEBUG_FIND_LEASE)
log_info ("not mine to allocate: %s",
piaddr (hw_lease -> ip_addr));
#endif
goto n_hw;
}
#endif
(i'm assuming the problem also exists on lines 3128 - 3146 for a uid_lease but didn't test that) but not sure what the correct if statement should be :)
I'm getting more in depth with the source code than i would of ever imagined... but hey, if we can get this bug nailed, then i think i can move forward with a full deployment!!!
Nicola
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3721 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090304/5a16ab63/attachment.bin>
More information about the dhcp-users
mailing list