Wrong gateway when using class in a subnet

[Adam Moffett]

>> The problem is, an AP on the second subnet will receive the gateway 
>> from the first (10.99.112.1).
>> My guess is DHCP is giving the first 'option router' that matches the 
>> class.
>
> You've hit (I think) a known inheritance "gotcha" - it also applies to 
> host declarations which is why standard advice is to put host 
> statements in the global scope.
>
> Even though you have declared it within a subnet, the class statement 
> is global - hence anything that matches it may match it whatever 
> subnet they are in. If the client is in a different subnet, then they 
> will be given (by rules of inheritance) options from the subnet where 
> the class is defined.
>
> I don't think we've come across a situation where this inheritance is 
> desired ! It's simple to avoid, just don't put your class (or host) 
> declarations within a subnet.

I'm guilty of the same error.  So here's a situation:  I have multiple 
routers out there relaying DHCP requests to one dhcpd server.  I want 
actual end user hardware to get IP's from one subnet so they have 
internet access, but I want our own equipment (switches, modems, 
bridges, APs) to get IP's from a private subnet.

Right now I'll have something like this:

shared-network "somearea" {
   class "OurStuff" {
     match if substring(hardware,1,3) = 00:04:f2;
   }
   class "EndUserStuff" {
      match if not substring(hardware,1,3) = 00:04:f2;
      #the real match rules are more complex, but this is the general idea
   }
   subnet 174.47.200.80 netmask 255.255.255.240 {
     pool {
       allow members of "EndUserStuff";
       range 174.47.200.82 174.47.200.94;
     }
   subnet 10.10.10.0 netmask 255.255.255.0 {
     pool {
       allow members of "OurStuff";
       range 10.10.10.2 10.10.10.254;
     }
   }
}

So this is all well and good, except I've defined different classes in 
different shared-networks that have identical "match if" statements.  It 
all /seemed/ to have been working until yesterday when I made a few 
adjustments and started getting unexpected gateway addresses on some 
clients just like the OP described.  The match statements had previously 
been defined so it was impossible for a client to match two classes, the 
change yesterday could have made some clients match two classes....but 
they were in different shared-networks so I mistakenly believed it would 
not matter.

If I'm understanding you correctly, I might as well just define a global 
"OurStuff" class and a global "EndUserStuff" class, because classes are 
global in scope regardless of where you define them? So doing what I've 
been doing just duplicates effort and leads to error.  Is that the jist 
of it?

Is there a chart somewhere showing which declarations are inherited by 
what?  That would be a super handy thing to have.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20120601/c9d0eb58/attachment.html>