Disentangling scopes (was: Format of array of ip-addresses)
Niall O'Reilly
niall.oreilly at ucd.ie
Tue Nov 18 12:40:50 UTC 2014
At Mon, 17 Nov 2014 21:02:08 +0000,
Verne Arase wrote:
>
> Actually, I was hoping that the subclass’s definition would live
> within the scope of the subnet block.
I have difficulty in seeing how that would work as you suggest. In
my copy of Droms and Lemon (p. 273), I read that the advantage of
the "subclass" mechanism, when compared with the logically
equivalent approach of a long chain of "if" rules in the "class"
specification, comes from its implementation using a hash table
keyed on the client property declared in the "match" clause of the
"class" specification.
I'm guessing, as I haven't analyzed the code, that this means that
only one occurrence of a "subclass" specification for a particular
key can remain after parsing of the configuration file. Whether
this is the first, last, or some other instance depends on details
of the parsing code.
So, if you have
subclass “LWAPP” “Cisco AP c3600” { ... }
in multiple subnets, I expect that only one will have effect, due to
the common hash-key value "Cisco AP c3600". If so, you should find
that just one pair of controllers is seeing demand, since you're
specifying the controllers in the configuration statements of the
subclass scope.
It seems to me that a single, global "subclass" specification
would have the same effect.
> This is in keeping with our telecommunications guys who want to
> distribute APs between several pairs of controlling servers.
Unless I'm making a wrong assumption about your addressing plan, I
expect that this goal is achievable simply by configuring
option LWAPP.controller ... ;
with an appropriate address list in each subnet definition, and
using the following single, global "subclass" specification.
subclass “LWAPP” “Cisco AP c3600”;
IHTH
Niall O'Reilly
More information about the dhcp-users
mailing list