Client tied to pool via (sub)class in one subnet, same client has host declaration in other subnet...

[Sten Carlsen]

On 19/09/13 16:32, Christian Marg wrote:
> Hello,
>
> On 19.09.2013 11:34, Sten Carlsen wrote:
>> You have put the host declaration inside the subnet declaration.
>> When you do that, it has the side effect that it will get its router and
>> some other settings from that subnet.
>
> We actually rely on that - we have about 70 different subnets with
> about 4500 host declarations. I don't like the idea to define "option
> routers" etc. per host...
>
> man dhcpd.conf says:
> ====8<====8<====8<====8<====
> When a client is to be booted, its boot parameters are determined by
> consulting that client's host declaration (if any), and then consulting
> any class declarations matching the client, followed by the pool, sub-
> net and shared-network declarations for the IP address assigned to the
> client.
> ====8<====8<====8<====8<====
>
> So the problem is not the placement of the host declarations but the
> fact that the class declaration ties the host to a pool, which in turn
> is called more "specific" than a subnet declaration...
The MAN page is unfortunately not always as clear and precise as one
might wish it to be.
>
> Maybe a workaround would be using "group" statements to group the
> hosts that belong to a subnet, and define routers etc. in that group.
>
> It seems that group-specific statements would count as "host-specific"
> in the above line from the manpage...
>
>> The general advice is to have all
>> host declarations outside all subnet declarations as they are global in
>> scope no matter where they are placed, inheritance is from where they
>> are placed.
>
> So a host declared globally will inherit the subnet parameters because
> it's IP adress belongs to the subnet? I think we went for host
> declarations inside of subnet declarations because it's a little more
> intuitive.
Well, yes. Host declarations ARE global no matter where you place them
in the text, EXCEPT that they will inherit routers etc. from the place
you declare them. In other cases we have seen that hosts inherit
parameters from the subnet where the host declaration was actually
placed, not from where it got the address from, even if one might expect
differently.

I still suggest to declare the hosts outside any subnet or other block,
they will take routers from where they belong. This is the reason for
the warning you should see in the output from dhcpd.
>
>> It could also look like the class and subclass declarations inherit form
>> the subnets they are placed in. I suggest to move them to outside all
>> subnets, they are global anyway.
>
> I already moved the class and subclass declaration out of the subnet -
> no change in behaviour. Of course the pool was still in the subnet,
> but where else would it be.
The pool must be in the subnet, correct.

You may want to try to deny members of the class from the subnet
192.168.65.0? If you do not deny them, they are allowed though the only
address seems to be the fixed address in the host declaration.

>From the looks of it, I believe there is a match on both the host and
the class declarations, in the subnet where the host belongs, there are
no ranges, so no available address, except that it also has a fixed
address statement.

My guess is that it first matches the host declaration, then later in
the file it matches the class statement, overriding the host statement
and finally gets the fixed address because there is no range in that
subnet, bringing the router etc from the subnet where the class is declared.

I will agree this is not very intuitive but we have seen a few
"interesting cases" based on things like this. I don't know the code
well enough to know whether this is exactly what happens.

My advice is still to remove both host declarations and class
declarations out of any subnet declaration and use allow / deny to
control whether members of any specific class may have an address in any
pool / range / subnet.

Removing them should remove wrong inheritance problems and allow / deny
should make sure they only get addresses where you want them to have one.
>
> kind regards,
>
> Christian Marg
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20130919/131634ee/attachment.html>