Classes and lease limit problems

[Jeffrey Hutzelman]

--On Sunday, January 06, 2008 03:18:41 PM +0100 Claus Holm Christensen 
<iscdhcp at claushc.dk> wrote:

> class "iplimit-standard" {
>         lease limit 1;
>         spawn with concat("HSI:",
>             binary-to-ascii(16, 8, "", suffix(option agent.remote-id,
> 6)), "-",
>             binary-to-ascii(10, 8, "", suffix(option agent.circuit-id, 4))
>         );
> }
> class "iplimit-VOIP" {
>         lease limit 3;
>         spawn with concat("VOIP:",
>             binary-to-ascii(16, 8, "", suffix(option agent.remote-id,
> 6)), "-",
>             binary-to-ascii(10, 8, "", suffix(option agent.circuit-id, 4))
>         );
> }
>
> shared-network Vlan132_provATA {
>         subnet 10.100.34.0 netmask 255.255.255.0 {
>                 option routers 10.100.34.1;
>                 max-lease-time 1209600;
>                 default-lease-time 604800;
>                 option tftp-server-name "10.100.X.X";
>                 option bootfile-name "atadefault.cfg";
>                 next-server 172.16.X.X;
>                 pool {
>                         range 10.100.34.4 10.100.34.254;
>                         allow members of "iplimit-VOIP";
>                 }
>         }
> }
> ...
> lease 10.100.34.239 {
>   starts 6 2008/01/05 21:04:34;
>   ends 6 2008/01/12 21:04:34;
>   binding state active;
>   next binding state free;
>   billing subclass "iplimit-standard" "HSI:0ff715640-00039";
>   hardware ethernet XX:XX:XX:XX:c1:95;
>   option agent.circuit-id 0:0:0:27;
>   option agent.remote-id 0:f:f7:15:64:0;
> }
>
> A lease for an address of 10.100.34.239 that ended up in the
> "iplimit-standard" subclass... How is that possible?

Requests are assigned to classes based solely on the request, not on what 
address might be assigned, and a request can fall into more than one class. 
In your example, every request falls into some subclass of iplimit-standard 
and some subclass of iplimit-VOIP.  When the server determines the billing 
class for a lease (temporarily for a DISCOVER; ultimately on a REQUEST), it 
chooses the first matching class for which the lease limit is not met.

So, suppose a client boots on VLAN 132.  It matches both iplimit-standard 
and iplimit-VOIP.  Since the lease limit on iplimit-standard is not yet 
full, that becomes the billing class for this client.  Since the client is 
also a member of iplimit-VOIP, it is allowed to get an address on the 
10.100.34 subnet, even though iplimit-VOIP is not the billing class.  This 
explains the lease you see for a client on 10.100.34 whose billing class is 
iplimit-standard.


What I can't explain is why your customer can't get an additional address. 
The "no billing available" message means that there is no room in the lease 
limits for any of the classes matching that client.  That suggests that 
either your customer is already using too many addresses (possibly 
including abandoned leases?) or the server is for some reason failing to 
consider both classes on the next request.

In order to get the effect you're after, you need to find some way of 
causing each class to match only those clients to which you want that limit 
to apply.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Carnegie Mellon University - Pittsburgh, PA