Disentangling scopes (was: Format of array of ip-addresses)

[Niall O'Reilly]

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