Good old "peer holds all free leases" appearing in a (formerly) very stable setup

[Glenn Satchell]

On Thu, February 20, 2014 8:37 pm, Nicolas Ecarnot wrote:
> Le 20/02/2014 01:33, Glenn Satchell a écrit :
>> On Thu, February 20, 2014 12:22 am, Nicolas Ecarnot wrote:
>>> Le 19/02/2014 02:58, Glenn Satchell a écrit :
>>>> On Wed, February 19, 2014 8:10 am, Peter Rathlev wrote:
>>>>> On Tue, 2014-02-18 at 13:37 +0100, Nicolas Ecarnot wrote:
>>>>>> - isc dhcp 3.0.5-18.el5
>>>>>
>>>>> I moved this to the top, since it's IMHO the most important thing.
>>>>> This
>>>>> is an _ancient_ release. Upgrading could solve many strange problems.
>>>>
>>>> Agree that it's ancient, but unfortunately this is the version that
>>>> shipped with every release of RHEL and CentOS 5.x
>>>>
>>>> It was addressed in dhcpd v4 with the 4.1 extended support version
>>>> that
>>>> picks up all the bug fixes in later dhcpd v4 releases.
>>>>
>>>> regards,
>>>> -glenn
>>>>
>>>
>>> Thanks to all who replied. We are aware of our archeologic datacenter
>>> and on the way to upgrade it soon.
>>> I'll test the embedding of the pool in the subnet declaration to see
>>> whether it improves the situation (and let you know).
>>>
>>> have a nice day.
>>>
>>> --
>>> Nicolas Ecarnot
>>
>> Pool statements are ok in the shared subnet, they will work fine as they
>> are. Thinking back to an ancient 3.0.something.RC there was a bug and
>> the
>> workaround was to move pools out of the subnet into the shared subnet.
>> Long since fixed, but 5 years ago it was probably something recent
>> enough
>> to be relevant.
>
> Hi,
>
> Today, I tried to place the pools declaration *inside* the subnet
> declaration and tried the same tests.
> No success...
> It fail with the same error as usual.
>
> During these tests, I check the host is *actually* sending the correct
> classID (tcpdump is witnessing it).
>
>> Are you able to post the class definition statements? Seems to me that
>> some clients are not matching either of your classes and there is no
>> default pool so in this case "no free leases" means "I couldn't find a
>> matching pool".
>
> The relevant part of the class declaration is :
>
> class "c-prtest" {
>    match if substring (option user-class,1,6) = "\0prtest";
> }
>
> and there are 18 such definitions working since years. I hope 18 is not
> a number high enough to hit a design limit.
>
> I don't know if there is a way I could increase the debug level and
> maybe help you help me by providing additional logs?

Hi Nicolas

Years ago I ran dhcpd 3.0.5 at a big site with about 100 subnets with
multiple pools in each, so I don't think 18 is a limit.

I can see one thing in that match line that doesn't look right. The
substring is producing a string of length 6, but you are comparing this to
a string of 7 characters. This will never be equal.

In the dhcp-eval man page it is defined as

    substring (data-expr, offset, length)

I'm guessing that string on the right should just be "prtest".

You can get dhcpd to log variables into dhcpd.leases, eg:

add this in some relevant scope, say the subnet or pool

   set myuserclass = option user-class;

Then it should add a line to dhcpd.leases.

If you're still getting no free leases, then try adding a third pool with

    deny members of "c-prtest";
    deny members of "theotherclass";

and see if that catches the test client. Then see what value is getting
stored in the lease value.

regards,
-glenn