Multiple class-matches

[Lars Jacobsen]

"David W. Hankins" <David_Hankins at isc.org> wrote:

> On Wed, Aug 27, 2008 at 03:48:53PM +0200,
> Staffan.Ungsgard at teliasonera.com wrote:
> > It seems that if a request matches more than one class,
> capabilities from
> > either class may be honoured.
> > In the following example a lease limit of 4 is applied to a lease
> that
> > matches the classes MainClass and AnothetClass1 - eventhough only
> MainClass
> > is "allowed" in the pool definition.
> 
> Lease limits make a class a "billing class". A client can be matched
> by several classes that have lease limits, but only one will be
> billed
> for that client.


So Steffan, you have to make sure a client only matches one single class
- and get billed to that class, if you want classes to be the selecting
parameter in your Allow/Deny statement. Otherwise strange things can
happend.

> Note that a client need not be billed to the class in an "allow"
> statement for it to be matched.
> 
> > Is this by design - i.e. is this something that could be considered
> "good
> > practise" to augment leases ?
> 
> Yes, it is by design that a client may match multiple classes, if
> they
> are set up that way.


I haven´t found a simple way to force /prioritice one class from another
yet, so it seems you have to go over your match statements again.

> --
> Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
> Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
> --
> David W. Hankins "If you don't do it right the first time,
> Software Engineer you'll just have to do it again."
> Internet Systems Consortium, Inc. -- Jack T. Hankins


Regards

Lars Jacobsen

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