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

[Niall O'Reilly]

On 19 Sep 2013, at 15:32, Christian Marg wrote:

> 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...
> 
> Maybe a workaround would be using "group" statements to group the hosts that belong to a subnet, and define routers etc. in that group.

	I'm afraid you're letting imagined complexity drive
	your design, and suffering consequences which can be
	avoided with a simpler approach.

	Parameter values are "collected" from all the scopes 
	(host, group, pool, class, subnet, shared-network: 
	I'm not sure I've put them in the right order) 
	involved, giving priority, in case of conflict only, 
	to the more specific scope.  

	The scopes are cascaded, not mutually exclusive, so
	provided you place each parameter where it naturally
	belongs, it all "just works".  So, you specify 
	"option routers" only for the subnet, not per host.  
	The active subnet scope is determined by the relay
	address received by the server, not by placement of
	the "host" specification within the "subnet" one.

	When you do place a "host" declaration within a 
	"subnet" declaration, the "host" scope inherits from 
	the (lexically/textually) enclosing "subnet", 
	over-riding the actually active "subnet". This leads 
	to a problem if the host is occasionally away from 
	the network where its fixed-address belongs, or if
	you need a different set of routers for some class
	or group.

	While I've been typing this, Sten Carlsen has sent
	his reply.  I think we're saying the same thing in
	different ways.  I hope this will be helpful rather
	than confusing.

	Best regards,
	Niall O'Reilly