Content-Type: text/plain; charset="utf-8" Message-ID: Content-Transfer-Encoding: binary References: X-RT-Interface: Web MIME-Version: 1.0 Content-Disposition: inline X-RT-Original-Encoding: utf-8 In-Reply-To: X-Mailer: MIME-tools 5.508 (Entity 5.508) RT-Send-CC: Content-Length: 2523 Original submitter responses to questions various: > Our initial thoughts are that the primary doesn't really have any > good way to know that there has been the switch, or to know quite > what to do with the fact that it happened - and that dhcpd has > probably operated this way since forever with failover partnerships. I haven't checked but I believe the people we had reproduce this had issues with either the primary or secondary in this case. I suspect you are correct that this has been around for a while. I didn't dig into the code really deeply but don't believe there is any way for either the primary or secondary to figure out that something has happened directly. There would need to be some information in the lease file to allow the server to compare what it had previously and what it has now. > We wonder what would happen if you fault the databases on the > secondary failover peer servers. I think removing the lease file on the peer that pool was moved to would work as it should cause a full update. However there would be a performance hit. This probably isn't too bad if the peer is in only one FA but might be unpleasant if the peer is in multiple peering relationships and now needs to do a full update for all of them. > Do you think this behaviour violates the DHCP Failover Specification > in some way? Faulting the DBs? no Having inconsistent DBs between peers? It might not violate the letter of it but I'd certainly believe it violates the spirit of it. > What thoughts do you have on how dhcpd should adapt to this > kind of pool/peering swapping? Things we've thought about: 1) Basically do a full update on the pool on a rebalance request by adding code to add all of the possible leases (in our case we mostly care about backup and free - active are kept in our DB and so are properly available) to the update queue 2) Trigger a full update when a pool is moved, this would probably require some sort of flag in the or maybe lease files. In our case the trigger would need to be removed from our DB automatically in your case you might be able to have the admin change the config file to add and then remove the flag. 3) tag the leases with the FA to which they belong, if it changes trigger an appropriate update 4) tag extra pool <-> FA information into the lease file 5) delete the lease file (I'm trying to have someone get some idea of the performance penalty in doing this.) I'm trying to balance the performance hit against the possible code complications