Help with class declarations, bad lease options

Simon Hobson dhcp1 at
Thu Sep 13 19:11:59 UTC 2007

Chris De Young wrote:

>I've run into a weird (to me) problem that I hope someone can help shed some
>light on.  I suspect I don't fully understand how class declarations work.
>I have a declaration like this in my configuration file:
>shared-network wireless-4 {
>     allow unknown-clients;
>     option domain-name "";
>     subnet netmask {
>         option routers;
>         option subnet-mask;
>         range;
>         class "4 Cisco AP c1130" {
>                 match if option vendor-class-identifier = "Cisco AP c1130";
>                 option vendor-class-identifier "Cisco AP c1130";
>                 vendor-option-space Cisco_LWAPP_AP;
>                 option mobility-group f1:04:ac:10:fd:76;
>             }
>         class "4 Cisco AP c1240" {
>                 match if option vendor-class-identifier = "Cisco AP c1240";
>                 option vendor-class-identifier "Cisco AP c1240";
>                 vendor-option-space Cisco_LWAPP_AP;
>                 option mobility-group f1:04:ac:10:fd:76;
>             }
>     }
>The problem I'm running into is that for every address pool declared 
>later than
>this in my configuration file (almost all of which are wireless segments and
>have similar class declarations), clients get lease offers with addresses from
>the appropriate pool, but a default route of - the 
>value from this
>first pool.  (They may be getting the subnet mask option form this pool rather
>than the correct one too - I haven't verified that for sure, since 
>most of them
>are the same.)
>This is the only place in the configuration file where this specific 
>class name
>("4 Cisco AP c1130", in this case) is used, it does not appear in any "allow
>members" statements or the like elsewhere in the configuration.
>I'm sure something's broken in my configuration; can anyone point me toward
>what, or let me know what I'm not understanding about how this is working?

Read the current thread "Global Scope (fwd)" - I think you have 
essentially the same problem.

Your client has a vendor client identifier of (for example) "Cisco AP 
c1130" so it matches class "4 Cisco AP c1130". Because this class is 
defined within a subnet then members of that class inherit options 
from that subnet. The fact that your client is actually in a 
different subnet doesn't matter - because like host statements, I 
think class definitions are global in scope. Well almost global - 
they are global in how they behave, but can inherit options from 
where they are defined.

The only safe way to deal with this is to define classes in the 
global scope. This does probably mean that you will have to rethink 
some of your strategies for defining client & subnet specific options.

More information about the dhcp-users mailing list