pre-creating reserved leases

[Foggi, Nicola]

> Then this must be the primary.  Reserved leases act a little
> different.  A primary should record it as free, the secondary should
> record it as backup, when they process the bndupd or bndack from the
> peer with the reserved flag set.

so i think this may be part of the problem here.  I manually created a reserved lease in both the primary and secondary, set the state to "free" on the primary and "backup" on the secondary, and the secondary correctly found the lease:

Mar  4 22:21:34 dhcp-lew-13s dhcpd: trying next lease matching hw addr: 10.0.82.9
Mar  4 22:21:34 dhcp-lew-13s dhcpd: Found lease for hardware address: 10.0.82.9.
Mar  4 22:21:34 dhcp-lew-13s dhcpd: Returning lease: 10.0.82.9.
Mar  4 22:21:34 dhcp-lew-13s dhcpd: DHCPDISCOVER from 00:0e:7f:e9:6c:c3 via 10.0.82.1
Mar  4 22:21:35 dhcp-lew-13s dhcpd: DHCPOFFER on 10.0.82.9 to 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1

however, i then had the printer do a DHCPRELEASE which caused the binding state on both primary and secondary to go to free, and when it did a discover again i got:

Mar  4 22:24:41 dhcp-lew-13s dhcpd: trying next lease matching hw addr: 10.0.82.9
Mar  4 22:24:41 dhcp-lew-13s dhcpd: not mine to allocate: 10.0.82.9
Mar  4 22:24:41 dhcp-lew-13s dhcpd: DHCPDISCOVER from 00:0e:7f:e9:6c:c3 via 10.0.82.1
Mar  4 22:24:42 dhcp-lew-13s dhcpd: DHCPOFFER on 10.0.82.180 to 00:0e:7f:e9:6c:c3 (NPIE96CC3) via 10.0.82.1

so if the secondary see's it as a state free, it won't allocate, but if it's backup it will, but a DHCPRELEASE appears to put it to free on both.  When the DHCPDISCOVER comes in, the secondary decides to DHCPOFFER instead of "load balance" to primary.

So is the best thing to look for a reserved flag in find_lease and allocate? look at the lease_mine_to_allocate and change it under CASE_FREE to say if PRIMARY or SECONDARY & RESERVED FLAG SET, or will that totally hork the failover stuff? or look at the DHCPRELEASE and have it set the secondary to a backup state on reserved leases?

I wonder if I'm the only one running into this? :)

Nicola
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3429 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090304/e456b77d/attachment.bin>