vendor-encapsulated-options and Scope

[Jeffrey Hutzelman]

--On Thursday, December 11, 2008 01:29:48 PM -0500 Reissom Beshir 
<Reissom_Beshir at Mitel.com> wrote:

> I believe you can define one class and use subclass statements in the
> subnet scope. So your config would be as follows.

That makes the matching cleaner, but doesn't actually help with the 
problem.  Placing a host, class, or subclass declaration inside a subnet or 
shared-network does _not_ restrict it to matching only clients booting from 
that subnet or shared-network; hosts, classes, and subclasses match 
regardless of where they appear in the configuration file.  However, 
placing one of these statements inside another scope _does_ cause them to 
inherit options from the enclosing scope.  Furthermore, because of the way 
the DHCP server resolves conflicting options, any options inherited in this 
way will override options specified for the subnet and/or shared-network 
the client is actually booting on.

Put another way: If you put a host, class, or subclass inside a subnet or 
shared-network, then options from that subnet or shared-network will be 
applied, even when the client is booting on some other network.

Put another way: Don't put host, class, or subclass definitions inside a 
subnet or shared-network.  It won't do what you want.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Carnegie Mellon University - Pittsburgh, PA