spawning class in ha setup?

Glenn Satchell Glenn.Satchell at uniq.com.au
Thu Jan 7 03:17:52 UTC 2010


>Date: Wed, 06 Jan 2010 16:19:23 +0100
>From: Nils-Henner Krueger <nhk at snhc-krueger.de>
>To: Users of ISC DHCP <dhcp-users at lists.isc.org>
>Subject: Re: spawning class in ha setup?
>
>Nils-Henner Krueger wrote at 2009-12-16:
>> I seem to observe a strange behaviour when trying to use a ha setup and
>> a spawning class together.
>> 
>> I'm evaluating a ha setup, using dhcpd version 4.1.0p1.
>> 
>> Primary config is
>> 
>> failover peer "cluster" {
>>   primary;
>>   address 192.168.2.2;
>>   port 519;
>>   peer address 192.168.2.3;
>>   peer port 520;
>>   max-response-delay 60;
>>   max-unacked-updates 10;
>>   mclt 3600;
>>   split 128;
>>   load balance max seconds 3;
>> }
>> 
>> Secondary config is
>> 
>> failover peer "cluster" {
>>   secondary;
>>   address 192.168.2.3;
>>   port 520;
>>   peer address 192.168.2.2;
>>   peer port 519;
>>   max-response-delay 60;
>>   max-unacked-updates 10;
>>   load balance max seconds 3;
>> }
>> 
>> Beside this I configured a limit on the allowed leases per client based
>> on agent.circuit-id like this:
>> 
>> class "customer" {
>>   spawn with option agent.circuit-id;
>>   lease limit 1;
>> }
>> 
>> I'm trying to lease and release IPs from a bunch of dummy clients in an
>> endless loop, using birds eye load generator. While testing a single
>> dhcp server that works fine. But as soon as I change to ha setup, only
>> the first run works and after that all clients are denied like this:
>> 
>> Dec 16 19:30:45 dhcp0 dhcpd: [ID 702911 local6.info] DHCPDISCOVER from
>> 00:ff:ff:61:d1:b3 via 10.30.136.1
>> Dec 16 19:30:45 dhcp0 dhcpd: [ID 702911 local6.info] DHCPOFFER on
>> 10.30.139.229 to 00:ff:ff:61:d1:b3 () via 10.30.136.1
>> Dec 16 19:30:45 dhcp0 dhcpd: [ID 702911 local6.info] DHCPREQUEST for
>> 10.30.139.229 (192.168.1.10) from 00:ff:ff:61:d1:b3 () via 10.30.136.1
>> Dec 16 19:30:45 dhcp0 dhcpd: [ID 702911 local6.info] DHCPACK on
>> 10.30.139.229 to 00:ff:ff:61:d1:b3 () via 10.30.136.1
>> [...]
>> Dec 16 19:31:31 dhcp0 dhcpd: [ID 702911 local6.info] DHCPRELEASE of
>> 10.30.139.229 from 00:ff:ff:61:d1:b3 () via 10.30.136.1 (found)
>> [...]
>> Dec 16 19:32:01 dhcp0 dhcpd: [ID 702911 local6.info] DHCPDISCOVER from
>> 00:ff:ff:61:d1:b3 via 10.30.136.1: no available billing: lease limit
>> reached in all matching classes
>> 
>> What's going wrong? Is a spawning class incompatible with ha setup? Do I
>> have to do something special to bring these to features together? Is
>> this a known bug?  :-)
>
>Setting the lease limit to at least "2" solved the problem. Although I
>still don't understand why it behaves this way.

Hi

Hmm, it seems that perhaps the failover protocol isn't communicating
with the other system as fast as you're releasing and renewing? Does it
make a difference if you increase the time between renew and release?
>From the log above it looks like about 45 seconds.

Setting the lease limit to 2 allows it to allocate a lease, even when
the existing one is still is use (from the server's point of view).

There may be some debugging statements that you can enable in the
source to print out more information. Have a look in includes/site.h -
some of the more interesting ones you could try are:

#define DEBUG_LEASE_STATE_TRANSITIONS
#define DEBUG_FAILOVER_MESSAGES
#define DEBUG_FIND_LEASE

Personally I've never used any of these defines, and I would only tend
to use them in a test environment. Otherwise you could get massive logs
very quickly.

One final thing to try would be the latest version, dhcp-4.1.1rc1,
which just might behave differently. I have been runing the beta
releases for some months with no problems, so stability shouldn't be a
problem.

regards,
-glenn




More information about the dhcp-users mailing list