Classes and lease limit problems

[Claus Holm Christensen]

Jeffrey Hutzelman wrote:
> Requests are assigned to classes based solely on the request, not on

All requests come in through relay-agents, and the source IP of the
relay agent determines which subnet to search for leases in. Further,
each VLAN have different IP adresses. That should limit the possible
number of leases to only this subnet, right?


> 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.

Well, that's funny. Just to make sure that I understand this correctly,
then once a client matches multiple classes, then the statements in
those classes will be mixed, and when one class doesn't apply any more,
then it's statements are still considered?


> 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.

That's my fault, sorry. With your explanation it's entirely normal, and
it's because he has a number of other addresses as well. I was just
concerned about the specific problem of the IP being in the wrong class
and didn't consider the other addresses to be important.


> 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.

An easy fix would be for each class to deny members of all the others,
but I doubt that will work (for the same reason).

Then I need to match on the IP address of the relay agent. That's the
source IP of the UDP packet and that should be available with the
statement "packet(4,4)". I need to check if that IP is in the 10.100/15
range, which I can do by converting the address to a string of binary
digits, and match the first 15 chars... Does that strike anybody as odd?

A different solution would be to look for the VLAN tag in the
circuit-id, but a large number of my Cisco switches doesn't forward that
bit of information :-(


-- 
Claus Holm Christensen