sending options from wrong subnet in shared-network

[Brian J. Murrell]

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.

> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20131210/2b0dfa06/attachment.bin>