Wrong gateway when using class in a subnet

[Randall C Grimshaw]

________________________________
From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of Adam Moffett [adamlists at plexicomm.net]
Sent: Friday, June 01, 2012 3:24 PM
To: Users of ISC DHCP
Subject: Re: Wrong gateway when using class in a subnet


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.

------ sorry my exchange client doesn't indent previous text ------

You are correct. Define the classes outside of the subnets.
you could have a class for yourstuff - dont be afraid to use subclasses.
(this suggestion assumes you have a better handle on yourstuff definitions)
in the pools for clientstuff have an acl for deny yourstuff
in the pools for your gear have an acl for allow yourstuff.
(with the exception of pools you actually drive systems between such as a quarantine this is sufficient)

If you have a really good handle on yourstuff you could also have defined hosts (again outside of the subnet definitions) that are as a group enclosed in a group statement - giving you a macaddress based group membership to acl against - and even fixed-address assignments [complete with DNS support - limited only by your management system - no warranties expressed or implied - offer void in california - see a participating dealer near you.]

Randall Grimshaw who apologizes for his Friday afternoon sense of humor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20120601/75551c35/attachment-0001.html>