sending options from wrong subnet in shared-network
Sten Carlsen
stenc at s-carlsen.dk
Tue Dec 10 21:58:20 UTC 2013
On 10/12/13 22.20, Brian J. Murrell wrote:
> On Wed, 2013-12-11 at 00:45 +1100, Glenn Satchell wrote:
>> Ah, I think I see it now that we have the full config. If these clients
>> boot using PXE (and the early packet trace looked like they might) then
>> they will be members of the at least the first pxeclients class as they
>> match the match statement. Because the class is defined inside the subnet,
>> it inherits values from that subnet. This is the same logic that arises
>> from moving the host definitions into the subnet scope.
> Right. But I guess logically, should a host match a class declaration
> whose scope is inside a subnet declaration that it cannot get an IP
> address from? I would have thought that the inability to get an IP
> address from a subnet would scope that subnet and anything inside it
> right out play.
Remember host declarations and class declarations are always global
regardless of where they are written. Scope only has influence on
inheritance.
>
>> Apart from the next-server setting, these two classes look the same.
> Yes. This did occur to me at one time also. But I really didn't want
> to send the next-server (and filename) option(s) to non-PXE booting
> clients.
>
>> So
>> define the class once, outside the shared-network, and in each subnet or
>> host or group add a next-server statement pointing to the specific tftp
>> server. That option shouldn't make any difference in non-PXE boots.
> I guess that depends on what the non-PXE boot is and is doing. There's
> no reason that a non-PXE boot might not use a next-server option if it
> were given.
>
> Ultimately what it seems like here is that one cannot have different
> classes matching depending on which subnet the node will get it's
> address from, even if one scopes the class into the subnets. I'm really
> not sure if that's intended behavior or not. It does seem like a
> violation of the scoping rules, but I'm far from an expert on those
> within the dhcpd configuration.
>
> Cheers,
> b.
>
>
>
> _______________________________________________
> 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/20131210/7fedefdc/attachment.html>
More information about the dhcp-users
mailing list