exclude addresses

Brian Raaen braaen at zcorum.com
Wed Jan 9 18:14:52 UTC 2008


you can try creating a class that has that mac address in a subclass.  Then 
you can block that mac address in any pool you want.  I have attached the 
relevant part of the dhcpd.conf man page.
 

-- 
Brian Raaen
Network Engineer
braaen at zcorum.com
Tel 678-507-5000x5574




CLIENT CLASSING
       Clients  can  be  separated into classes, and treated differently 
depending on what class they are in.   This separation can be done either 
with a conditional
       statement, or with a match statement within the class declaration.   It 
is possible to specify a limit on the total number  of  clients  within  a  
particular
       class or subclass that may hold leases at one time, and it is possible 
to specify automatic subclassing based on the contents of the client packet.

       To add clients to classes based on conditional evaluation, you can 
specify a matching expression in the class statement:

       class "ras-clients" {
         match if substring (option dhcp-client-identifier, 1, 3) = "RAS";
       }

       Note  that  whether you use matching expressions or add statements (or 
both) to classify clients, you must always write a class declaration for any 
class that
       you use.   If there will be no match statement and no in-scope 
statements for a class, the declaration should look like this:

       class "ras-clients" {
       }

SUBCLASSES
       In addition to classes, it is possible to declare subclasses.   A 
subclass is a class with the same name as a regular class,  but  with  a  
specific  submatch
       expression  which  is  hashed  for quick matching.  This is essentially 
a speed hack - the main difference between five classes with match 
expressions and one
       class with five subclasses is that it will be quicker to find the 
subclasses.   Subclasses work as follows:

       class "allocation-class-1" {
         match pick-first-value (option dhcp-client-identifier, hardware);
       }

       class "allocation-class-2" {
         match pick-first-value (option dhcp-client-identifier, hardware);
       }

       subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
       subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
       subclass "allocation-class-1" 1:0:0:c4:aa:29:44;

       subnet 10.0.0.0 netmask 255.255.255.0 {
         pool {
           allow members of "allocation-class-1";
           range 10.0.0.11 10.0.0.50;
         }
         pool {
           allow members of "allocation-class-2";
           range 10.0.0.51 10.0.0.100;
         }
       }

       The data following the class name in the subclass declaration is a 
constant value to use in matching the match expression for the class.  When 
class  matching
       is done, the server will evaluate the match expression and then look 
the result up in the hash table.   If it finds a match, the client is 
considered a member
       of both the class and the subclass.

       Subclasses can be declared with or without scope.   In the above 
example, the sole purpose of the subclass is to allow some  clients  access  
to  one  address
       pool,  while  other clients are given access to the other pool, so 
these subclasses are declared without scopes.   If part of the purpose of the 
subclass were
       to define different parameter values for some clients, you might want 
to declare some subclasses with scopes.

       In the above example, if you had a single client that needed some 
configuration parameters, while most didn't, you might write the following 
subclass declara-
       tion for that client:

       subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {
         option root-path "samsara:/var/diskless/alphapc";
         filename "/tftpboot/netbsd.alphapc-diskless";
       }

       In  this example, we've used subclassing as a way to control address 
allocation on a per-client basis.  However, it's also possible to use 
subclassing in ways
       that are not specific to clients - for example, to use the value of the 
vendor-class-identifier option to determine what values to send in the 
vendor-encapsu-
       lated-options option.  An example of this is shown under the VENDOR 
ENCAPSULATED OPTIONS head in the dhcp-options(5) manual page.


On Wednesday 09 January 2008 12:52, Ron Croonenberg wrote:
> Hello,
> 
> Is it possible to 'refuse' a client by mac address ?
> 
> thanks.
> 
>


More information about the dhcp-users mailing list