Clients Matching Multiple Classes (Was: Re: host declarations based on agent.remote-id)

[Richard Laager]

I previously posted (back in May) about trying to do "DHCP statics" on a
per-customer basis using their remote-id.

This was a reply:

On Tue, 2008-05-20 at 17:23 -0500, Austin Gabel wrote:
> I do something similar to this.  To set the static this way you just
> create a pool with a range of one address, and only allow the option
> 82 info that you want.  For your setup you could use:
> 
> 
> class "customer1" { match if binary-to-ascii(16, 8, ":",
> substring(option agent.remote-id, 2, 6)) = "00:00:00:00:00:00" }
> pool {deny dynamic bootp clients; allow members of "customer1"; range
> 192.168.1.100; }

We struggled with this back after we saw this message. Then we dropped
it for a while. I've finally gotten back to testing this some more.

We have this working to a certain extent, but have run into issues
relating to clients possibly matching multiple clases.

The configuration before we started contained these class definitions:

class "customer1 {
    match if option agent.remote-id = 1:1:0:0:0:0:0:0:40:1:DB:39;
    lease limit 3;
}

class "dsl" {
  allow duplicates;
  spawn with pick(option agent.remote-id, remote-id);
  if (exists agent.remote-id) {
    set remote-id = option agent.remote-id;
  }
  lease limit 2;
}

First off, I'm not sure from where we inherited the configuration for
the "dsl" class. I don't understand the agent.remote-id vs remote-id
stuff at all. Any pointers on that would be helpful.

Ignoring my ignorance on the first point, it appears that customer1
class is a strict subset of the dsl class. Therefore, do clients
matching the customer1 class criteria end up in two classes? (From our
testing explained below, it seems they do.) If so, which lease limit is
used? Is it determined by class order in the config file or what?

It's entirely possible our existing config is broken in this sense.


Back to the remote-id matching...

Our first change was to add another class, like this:

class "test" {
  match if substring(option agent.remote-id, 10, 11) = 01:EA;
}

Then, in our subnet section, we have two pools:
  subnet 1.2.3.0 netmask 255.255.255.0 {
    option routers 1.2.3.1;

    pool {
      allow members of "dsl";
      range 1.2.3.20 1.2.3.254;
    }

     pool {
       allow members of "test";
       range 1.2.3.14;
    }
  }

We then did a release/renew from a box on the test connection. It
previously had an IP in the first pool (NOT the .14). It got that
address again. A new box we added to the test connection got .14. To me,
this suggests that the test connection was ending up in both the "dsl"
and "test" classes. Adding a 'deny members of "test";' to the first pool
seemed to confirm that, by preventing the client from getting an address
from that pool.

Is this possible? Can a client match multiple classes at once?

In theory, we could exclude every individual customer with a one-address
pool from the bigger pools. This wouldn't be so bad in terms of having a
script building the dhcpd.conf file, but I'm concerned about the
performance implications of having every pool have a hundred or so deny
lines.

Any recommendations on what we should do in our case? We want most users
to get assigned to the (true) pools and then certain individual
connections to be assigned to their own one-address pools.

Thanks,
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20080911/814d2221/attachment.bin>