pre-creating reserved leases

[Foggi, Nicola]

would something like this be appropriate? (it appears to work, but not sure if it's appropriate) this would handle if the secondary received the DHCPRELEASE and instead of changing the lease to FREE it would set it to BACKUP.

now i wonder what happens if the lease expires... or is it better to just allow the secondary to lease out a reserved lease, or is that frowned upon?  technically the lease would be free on both servers, so maybe that's a better option?

*** server/failover.c.orig      2009-03-05 21:03:22.000000000 -0600
--- server/failover.c   2009-03-05 21:28:12.000000000 -0600
***************
*** 5808,5813 ****
--- 5808,5822 ----
                        return FTS_RESET;
                }
              case FTS_ACTIVE:
+               /* If secondary received DHCPRELEASE on a RESERVED_LEASE set to BACKUP  
+                  to allow reallocation */
+               if ((state -> i_am == secondary) && 
+                      (lease->flags & RESERVED_LEASE)) {
+                       if (binding_state == FTS_RELEASED) {
+                               new_state = FTS_BACKUP;
+                               goto out;
+                       }
+               }
                /* The secondary can't change the state of an active
                   lease. */
                if (state -> i_am == primary) {


-----Original Message-----
From: dhcp-users-bounces at lists.isc.org on behalf of Foggi, Nicola
Sent: Wed 3/4/2009 10:52 PM
To: Users of ISC DHCP
Subject: RE: pre-creating reserved leases
 

> 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: 4213 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090305/0d84db0c/attachment.bin>