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