vendor-encapsulated-options and Scope
jhutz at cmu.edu
Thu Dec 11 18:45:01 UTC 2008
--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
More information about the dhcp-users